A2A (Agent2Agent-protocol)

Wat is A2A?

A2A, kort voor Agent2Agent, is een open standaard waarmee AI-agents van verschillende teams en verschillende leveranciers kunnen samenwerken. De ene agent kan de andere iets vragen, kan opvolgen hoe het werk vordert, en krijgt een resultaat terug, zonder dat één van de twee moet weten hoe de andere gebouwd is.

Google zette het protocol in 2025 op poten, met steun van meer dan honderd technologiebedrijven, en gaf het bestuur daarna door aan de Linux Foundation. Dat werd in juni 2025 aangekondigd, met onder meer AWS, Cisco, Google Cloud, Microsoft, SAP, Salesforce en ServiceNow als bedrijven achter het project. Je zet je architectuur hier dus niet op de huisstandaard van één leverancier.

Er is één ontwerpprincipe dat je best begrijpt voor je verder leest. Agents werken samen op basis van wat ze zeggen dat ze kunnen en op basis van de informatie die ze uitwisselen, en ze krijgen nooit toegang tot elkaars interne toestand, geheugen of tools. Jouw agent geeft een vraag door en krijgt een resultaat terug. Alles wat er tussenin gebeurde, blijft achter de voordeur van die andere agent. Dat is bewust zo gemaakt, want net daardoor kan je met de agent van een leverancier werken zonder die leverancier in je eigen systemen te laten.

Hoe twee agents elkaar vinden

Elke agent die A2A spreekt, publiceert een Agent Card. Die kaart is een JSON-document dat beschrijft wie de agent is, welke vaardigheden hij heeft, waar zijn endpoint staat, en hoe je moet aanmelden. Je vindt die kaart op een vast gekend adres op het domein van de agent, op dezelfde manier waarop andere webstandaarden een vast pad gebruiken.

Dat klinkt als een detail, maar het is precies het stuk dat de hele zaak op schaal doet werken. De kaart is machineleesbaar en staat altijd op dezelfde plek. Daardoor kan jouw agent zelf uitzoeken wat een andere agent kan. Er moet dus geen ontwikkelaar eerst een pak API-documentatie doorworstelen en met de hand een koppeling schrijven.

De kaart zegt ook welke beveiligingsschema's de agent aanvaardt. Het protocol laat API-sleutels toe, HTTP-authenticatie, OAuth 2.0, OpenID Connect en wederzijdse TLS. Jouw agent leest de kaart, meldt aan zoals de kaart voorschrijft, en de ontvangende agent controleert daarna de gegevens en beperkt waar die klant bij mag.

Wat er tijdens een taak gebeurt

Als jouw agent een bericht stuurt, dan maakt de andere agent een taak aan. Die taak is wat je opvolgt, en ze loopt door een reeks toestanden die in de specificatie vastliggen.

Ze begint als ingediend, wat betekent dat de vraag aanvaard is. Ze gaat naar bezig terwijl de agent eraan werkt. Van daaruit kan ze eindigen als voltooid, mislukt, geannuleerd of geweigerd, en dat zijn allemaal eindtoestanden. Ze kan ook halverwege stoppen en op jou wachten, omdat ze extra input nodig heeft of omdat er eerst aangemeld moet worden. Die laatste groep is belangrijker dan ze eruitziet. Het protocol zegt daarmee hardop dat een taak die lang loopt, mag pauzeren om een mens of een ander systeem iets te vragen, in plaats van te gokken en gewoon door te doen.

De inhoud zelf reist als berichten, en die bevatten één of meerdere onderdelen. Een onderdeel kan tekst zijn, een bestand als ruwe bytes, of gestructureerde data als JSON. Op het einde komt er een artefact uit, en dat bestaat ook weer uit onderdelen. Een gegenereerd document, een afbeelding of een gestructureerd resultaat passen dus allemaal in dezelfde vorm.

Je kan dat alles over drie verschillende transportlagen sturen: JSON-RPC 2.0 voor eenvoudige koppelingen, gRPC als je prestaties wil tussen diensten onderling, en gewone HTTP met JSON voor een opstelling in REST-stijl. Ze bieden alle drie hetzelfde gedrag voor de kernbewerkingen, dus je kiest degene die bij jouw stack past en niet degene die bepaalt wat je kan doen.

Voor werk dat een tijdje duurt, zijn er twee manieren om op de hoogte te blijven. Met server-sent events krijg je een levende verbinding waarop status en resultaten binnenlopen op het moment dat ze er zijn, en dat is wat je wil achter een gebruikersinterface. Push notifications werken net omgekeerd. De agent post naar een webhook die jij geregistreerd hebt, telkens als de taak van toestand verandert. Dat is wat je wil voor een opdracht die een uur loopt terwijl er niemand naar een scherm zit te kijken.

Hoe A2A zich verhoudt tot MCP

Deze twee worden voortdurend in één adem genoemd, en ze lossen iets anders op.

MCP koppelt een model aan tools en data. Zo krijgt een agent de mogelijkheid om je database te bevragen, een bestand te lezen of je API aan te roepen.

A2A koppelt een agent aan een andere agent. Zo geeft de ene agent een stuk werk door aan een tweede agent die zelf redeneert, zelf tools heeft en zijn eigen manier van werken volgt.

Je zou je kunnen afvragen waarom je die tweede agent niet gewoon als tool verpakt en alles via MCP doet. De A2A-documentatie antwoordt daar rechtstreeks op. Een agent behandelen als een simpele tool beperkt je, want een toolaanroep is één vraag met één antwoord. Agents hebben een gesprek over meerdere beurten nodig, waarin ze kunnen plannen, een vervolgvraag stellen, en zelf verder delegeren.

In de praktijk gebruik je allebei. Microsoft ondersteunt bijvoorbeeld beide protocollen in zijn identiteitsplatform voor agents, en Azure API Management kan een gateway zetten voor zowel MCP-servers als A2A-agent-API's. Het zijn twee lagen van dezelfde stapel en geen twee opties waartussen je kiest.

Waar moet je op letten bij A2A

Je hebt dit alleen nodig als er echt twee agents zijn. Als alles wat je bouwt binnen één platform draait, dan is een protocol om over leveranciers heen te praten overhead die je nog niet nodig hebt. Vraag je dus af of er echt een tweede partij aan de andere kant staat.

Agents die je niet kan inkijken, zijn lastiger te debuggen. Net datgene wat A2A veilig maakt, namelijk dat je niet in die andere agent kan kijken, betekent ook dat je bij een fout antwoord niet kan nagaan hoe het tot stand kwam. Log de taak, het bericht en het artefact aan jouw kant, zodat je op zijn minst je eigen helft van het gesprek hebt.

Authenticatie is jouw verantwoordelijkheid en niet die van het protocol. A2A beschrijft welke schema's er bestaan en waar je ze aangeeft. Het beslist niet welke agent jouw agent mag aanroepen en waar die dan bij mag. Dat is een vraag over agentidentiteit en toegangsregels, en die moet je zelf beantwoorden.

Een taak die wacht, kost je ook iets. Toestanden zoals wachten op input of wachten op authenticatie zijn nuttig, maar ze betekenen dat taken lang kunnen blijven hangen. Spreek op voorhand af hoe lang je ze bijhoudt en wie er een herinnering krijgt.