Drie talks die bleven hangen van AGNTCon + MCPCon Europe

Op 17 en 18 september was AGNTCon + MCPCon Europe in de RAI in Amsterdam: twee dagen over AI-agents en het Model Context Protocol (MCP). We waren er met z'n vieren: Inico, Martijn, Jorick en Pascal. Voor een bedrijf dat draait om testen en opleveren is het zeer relevant. Als agents code schrijven en zelf tools aanroepen, verandert ook de vraag hoe je weet dat iets werkt. Drie talks zijn ons bijgebleven.

Eén gateway voor elke client

Anushka Bhandari van Booking.com sprak over "From MCP Playground To Org-Wide Infrastructure: Lessons From Building Booking.com's Agent Foundry". Haar uitgangspunt: de meeste MCP-projecten sneuvelen tussen proof of concept en productie, en dat gat is organisatorisch. Wie is eigenaar van de servers? Wie reviewt de bijdragen? En hoe laat je een designer, een productmanager en een agent dezelfde infrastructuur gebruiken zonder tien verschillende logins?

Booking.com bouwde daarvoor de Agent Foundry: een MCP gateway in twee lagen, met meer dan twintig servers voor de hele organisatie, waaronder Grafana, Honeycomb, Atlassian, Slack en GitLab. Mensen en agents gebruiken dezelfde OAuth-flow. Er is een register voor skills, waarin bijdragen door AI worden gereviewd, en profielen bundelen MCP's en skills per workflow.

Op een van de slides zie je het in één plaatje. Een developer kiest zelf z'n client, of dat nu Cursor, Windsurf, Claude Code of Codex is. De gateway regelt de routing en de autorisatie naar de bedrijfssystemen, en de rechten die daar gelden blijven gewoon staan. Collega Martijn vatte het samen als "een MCP gateway die clients en modellen kan koppelen aan company systems".

Foto: Martijn

Wat de aanpak zo sterk maakt, zit volgens Martijn in twee dingen. Het eerste is dat de vraag uit het bedrijf zelf kwam. Mensen kwamen er zelf om, met een "dat wil ik ook gebruiken!" "Het is daarmee niet een tool die is opgelegd, maar een oplossing die zichzelf heeft bewezen en verkocht," zegt Martijn. Of met een knipoog: bedoeld voor developers, gewenst door het hele bedrijf. Het tweede is eigenaarschap. Wie een nieuwe MCP toevoegt, onderhoudt die ook zelf. You build it, you run it.

De software factory

In zijn keynote "State of the Software Factory" op de tweede dag liet Dexter Horthy van HumanLayer zien hoe de loops in de software factory verschuiven. Dat bleef het meest hangen: wat er per stap verandert, en wat er nu kan.

Hij begint in 2022, vlak voor AI. Gebruikers leveren klachten en feature requests aan, iemand bouwt het, en daarna volgt een pull request met checks en een mens die de wijziging test en reviewt. Bouwen kost uren of dagen, en reviewen ook. Daarom plannen teams vooraf. Een uur plannen scheelt rework en maakt de review korter.

Foto: Pascal

Dan komt de agentic software factory. Een agent bouwt, en bouwen gaat van uren of dagen naar minuten of uren. Review kost nog steeds uren of dagen en wordt de bottleneck. Dus komen er agents bij die code reviewen en regressietests draaien, en gaan ook incidenten en gebruikersfeedback de fabriek in. De vraag wordt hoeveel je in de wachtrij kunt stoppen, en hoe snel je kunt reviewen en testen wat eruit komt.

De stap daarna is de lights-off factory, waarin niemand de code nog leest. De moeite gaat dan naar tests, sandboxes, automatische review, monitoring, rollout en feedback van gebruikers. Volgens Horthy werkt dat nog niet, want kwaliteit controleren is veel moeilijker dan kijken of de tests slagen.

Zijn antwoord: doe het licht weer aan. De code review komt terug, en je plant vooraf, met hulp van AI, in vier fasen: product, systeemarchitectuur, programmaontwerp en verticale slices. "30 minutes of planning saves hours of review." Liever veilig twee tot drie keer sneller dan tien tot honderd keer sneller.

Hij werkt het uit in zijn essay "Why Software Factories Fail". Eén zin daaruit: "Tests give you feedback in seconds, but the cost function of bad architecture is measured in weeks, months, maybe even years."

Weten wat je client echt ondersteunt

Paul Carleton en Felix Weinberger van Anthropic spraken over "MCP Conformance Testing V1.0, Testing the 2026-07-28 Spec in SDK's and Online". Conformance tests controleren of SDK's de MCP-specificatie zo implementeren dat ze met elkaar kunnen samenwerken. De spec-revisie van 2026-07-28 is de eerste waarbij die tests verplicht deel uitmaken van het proces voor wijzigingsvoorstellen op de spec. Nieuw is een gehoste versie, waarmee clients en servers hun draaiende implementatie kunnen testen.

Op de slide staat de vraag: "What if one page showed what your client really supports, per spec version?" Je start een run, plakt één config in je client en leest één tabel af, met 48 client-scenario's per spec-versie. De run op die slide was met Claude Code, op 16 september 2026. Wie het zelf wil proberen: mcp-c9e-v1.val.run.

Foto: Pascal

Het doet denken aan vroeger, toen we per browser checkten of alles wel werkte. Met MCP krijgen we dat nu opnieuw, want niet elke client ondersteunt dezelfde onderdelen van de spec. Door de conformance vooraf te checken, voorkom je dat je daar pas in productie achter komt.

Wat we meenemen

Houd rekening met eigenaarschap, zoals Booking.com doet: developers kiezen hun eigen client, en wie een MCP toevoegt, onderhoudt hem ook. Dexter gaf een helder beeld van wat nu al werkt, en van welke loops je kunt automatiseren. En Paul en Felix lieten zien dat je een MCP die je bouwt eenvoudig kunt checken tegen de spec.

Wil je hier zelf mee aan de slag? Bekijk dan onze training.