Wel zinvol
- Je bouwt gereedschap dat andere mensen met hun eigen agent willen gebruiken
- Je hebt taken die logisch bij verschillende systemen horen
- Je wilt niet voor elke combinatie een eigen koppeling schrijven
Wat is A2A?
Vorig jaar leerde iedereen wat MCP was: de manier waarop een AI-agent bij jouw gereedschap kan. Er is er sindsdien een tweede bijgekomen, A2A, en die gaat over iets anders — agents die met elkaar praten in plaats van met een tool.
01/10
Het verschil in één beeld
De een geeft je agent handen, de ander geeft hem collega's.
MCP beschrijft hoe een agent kan ontdekken welk gereedschap er is en hoe hij het aanroept: een agenda uitlezen, een bestand ophalen, een order aanmaken. De agent blijft de baas; het gereedschap voert uit.
A2A beschrijft hoe twee agents met elkaar praten en werk aan elkaar overdragen. De ene agent kan zeggen wat hij kan, de andere kan hem een taak geven en het resultaat terugkrijgen. Er zit geen mens tussen en geen gereedschap; het zijn twee partijen die onderhandelen over wie wat doet.
Ze bijten elkaar dus niet. Een agent gebruikt MCP om iets te dóen en A2A om iets uit te besteden. In de praktijk gebruik je vaak allebei zonder er lang over na te denken.
02/10
Waarom er nu ineens standaarden zijn
Omdat de alternatieven duurder bleken dan samenwerken.
Elke aanbieder had begin 2025 zijn eigen manier om gereedschap aan een model te knopen. Voor wie iets bouwde betekende dat: voor elke combinatie een eigen koppeling, en bij elke wijziging aan een van beide kanten opnieuw beginnen. Dat werd sneller onhoudbaar dan gebruikelijk, omdat het aantal combinaties in een jaar vertienvoudigde.
Wat daarna gebeurde is zeldzaam in deze hoek: de grote aanbieders kozen niet voor een eigen standaard maar sloten zich aan bij dezelfde. Dat is deels eigenbelang — een model dat overal op past is meer waard — en deels de les uit eerdere golven, waarin concurrerende standaarden vooral vertraging opleverden.
Voor jou als bouwer betekent het dat de kans dat je op het verkeerde paard wedt, kleiner is dan bij eerdere hypes. Dat is geen garantie, wel een verschil met de situatie van anderhalf jaar geleden.
03/10
Hoe hard dit is gegaan
- MCP stond in maart 2026 op zevenennegentig miljoen downloads per maand van de ontwikkelaarspakketten — vergelijkbaar met React, maar bereikt in zestien maanden in plaats van drie jaar.
- Alle grote aanbieders ondersteunen het inmiddels rechtstreeks: Anthropic, OpenAI, Google, Microsoft, AWS, en de bekende editors.
- A2A kwam er in april 2025 bij, met tientallen partners en uitdrukkelijk als aanvulling gepositioneerd, niet als concurrent.
- Allebei staan ze nu onder de Agentic AI Foundation, onderdeel van de Linux Foundation, met honderdnegentig aangesloten organisaties.
04/10
Wanneer je hier iets aan hebt
Niet zinvol
- Je hebt één agent die één ding doet
- Je koppelingen zijn met twee vaste partijen en veranderen zelden
- Je bent nog aan het uitzoeken wat je product moet doen
05/10
Wat een standaard je werkelijk bespaart
Niet het schrijven van de koppeling, maar het onderhouden ervan.
Een koppeling schrijven is nooit het probleem geweest. Het probleem is dat je er tien hebt, dat ze allemaal net anders werken, en dat er elk kwartaal eentje verandert. Een gedeelde standaard verplaatst dat onderhoud van jou naar de aanbieder van het gereedschap.
Dat is dezelfde belofte die eerdere standaarden deden, en de reden dat het deze keer sneller gaat, is dat de modelaanbieders zelf meedoen. Zolang zij het ondersteunen, hoeft niemand anders een eigen variant te verzinnen.
Wat het níet oplost: wat een agent mag. Een standaard beschrijft hoe een verzoek eruitziet, niet of het verstandig is om dat verzoek in te willigen. Rechten, logging en grenzen blijven jouw werk.
06/10
Waar je op let als je het inbouwt
Rechten per taak
Een agent hoort niet meer te kunnen dan de taak vraagt. Geef toegang per handeling, niet per systeem.
Vastleggen wat er gebeurde
Wie vroeg wat, wanneer, en wat kwam eruit. Zonder dat spoor is een fout achteraf niet te reconstrueren.
Een noodrem
Eén plek waar je alles uit kunt zetten. Je hebt hem zelden nodig en op dat ene moment is er geen alternatief.
07/10
Wat er misgaat als je te veel openzet
De risico's zijn niet nieuw, alleen sneller bereikbaar.
Een agent die bij je gereedschap kan, kan alles wat dat gereedschap kan. Dat klinkt vanzelfsprekend en het wordt vaak vergeten: een leesrecht op één tabel is iets anders dan een leesrecht op de database waar die tabel in staat.
Daar komt bij dat de instructie aan een agent uit tekst bestaat, en dat die tekst van buiten kan komen. Een agent die een binnengekomen bericht leest en daarin een opdracht tegenkomt, kan die opdracht opvolgen. Dat is niet theoretisch; het is de meest voorkomende manier waarop dit soort koppelingen misgaat.
De praktische maatregel is saai: geef per handeling toegang in plaats van per systeem, laat gevoelige acties door een mens bevestigen, en log wat er langskomt. Dat kost een halve dag en het scheelt het soort incident waar je maanden last van hebt.
08/10
Hoe dit zich verhoudt tot wat je al hebt
Als je een API hebt, heb je het meeste al. Deze standaarden zitten er bovenop: ze beschrijven hoe een agent ontdekt wat er is en hoe hij het aanroept, niet wat er onder ligt. Je bouwt dus geen nieuw systeem maar een nette voordeur voor het systeem dat er al is.
Dat maakt de afweging ook overzichtelijk. Heb je gereedschap waarvan je wilt dat anderen het met hun agent gebruiken, dan is die voordeur een dag werk. Heb je dat niet, dan hoef je hier niets mee — en verandert er voor jou pas iets als je klanten erom gaan vragen.
09/10
Wat wij ervan gebruiken
In een bouwdag is dit zelden het onderwerp. Wat we wél doen, is bij het ontwerpen rekening houden met de mogelijkheid: als de logica van je product netjes in aanroepbare stukken zit, is die voordeur er later in een dag bij te zetten. Zit alles verweven met de schermen, dan is het een verbouwing.
Dat is geen extra werk, het is dezelfde scheiding die je toch al wilt. Het verschil is dat er nu een concrete reden is om hem aan te houden.
10/10
Veelgestelde vragen
Moet ik nu iets doen?
Alleen als je gereedschap aanbiedt dat anderen met een agent willen gebruiken. Voor een gewone app verandert er niets, tot een klant erom vraagt.
Is A2A hetzelfde als agents die elkaar bellen via een API?
In de kern wel, met het verschil dat er afspraken zijn over hoe een agent vertelt wat hij kan en hoe een taak wordt overgedragen. Dat scheelt bij elke nieuwe combinatie een gesprek.
Wat als deze standaarden weer verdwijnen?
Dan houd je de API die eronder zit, want die is van jou. Dat is meteen het argument om de standaard als een laag te bouwen en niet als fundament.
Kan ik dit zelf uitproberen?
Ja, en dat is de snelste manier om te snappen waar het over gaat. De ontwikkelaarspakketten zijn openbaar en een eenvoudige koppeling is een middag werk.
Wie beheert dit?
De Agentic AI Foundation, onderdeel van de Linux Foundation. Dat is relevant omdat het betekent dat geen enkele aanbieder in zijn eentje de spelregels kan veranderen.
Is dit hetzelfde als agentische betalingen?
Nee, dat is een derde spoor. Daar gaan afzonderlijke afspraken over, met getekende mandaten die vastleggen hoeveel een agent mag uitgeven.
