Van experiment naar productieprotocol
A2A bereikte in maart 2026 versie 1.0 en kreeg daarna de onderhoudsrelease 1.0.1. De 1.0-specificatie is nadrukkelijk als production-ready gepositioneerd: één normatief datamodel, expliciete protocolversies en equivalente bindings voor HTTP+JSON, JSON-RPC en gRPC. Dat maakt het mogelijk om agents op verschillende stacks hetzelfde taakcontract te laten spreken.
De governance ligt bij de Linux Foundation. Volgens de Foundation waren in april 2026 meer dan 150 organisaties bij het ecosysteem betrokken en verschenen integraties in grote cloudplatforms. Dat is een belangrijk volwassenheidssignaal, maar geen kwaliteitsgarantie voor een concrete implementatie. Een protocol kan interoperabiliteit standaardiseren; het kan geen gebrekkige taakdefinitie, te brede rechten of ontbrekend operationeel eigenaarschap oplossen.
Wat A2A wel en niet standaardiseert
A2A beschrijft de grens tussen een client-agent die werk delegeert en een remote agent die een capaciteit aanbiedt. De kernobjecten zijn compact: een Agent Card beschrijft de agent, een Message draagt communicatie, een Task bewaart een stateful werkeenheid en een Artifact bevat het resultaat. Context maakt meerdere taken binnen dezelfde interactie mogelijk.
Het protocol bepaalt niet welk model, agentframework of intern geheugen een agent gebruikt. Het verplicht agents ook niet om hun chain-of-thought, private tools of brondata prijs te geven. Dat is precies de waarde: twee systemen kunnen een controleerbaar werkcontract delen terwijl hun interne implementaties en beveiligingsgrenzen onafhankelijk blijven.
MCP lost een andere integratiegrens op. Een agent kan MCP gebruiken om database-, zoek- of bedrijfstools te ontdekken en A2A gebruiken om een gespecialiseerde agent in een ander systeem werk te laten uitvoeren. In een volwassen architectuur kunnen beide tegelijk voorkomen, met afzonderlijke identity-, policy- en evaluatielagen.
Discovery begint bij een verifieerbaar contract
Een A2A-agent kan een publieke Agent Card aanbieden via /.well-known/agent-card.json. Daarin staan onder meer naam, beschrijving, skills, ondersteunde interfaces, protocolversies en authenticatievereisten. Voor gevoelige of gebruikersspecifieke capaciteiten kan na authenticatie een uitgebreidere card beschikbaar zijn.
Versie 1.0 voegde supportedInterfaces en interfacegebonden protocolversies toe. De client kiest dus bewust een transport en versie in plaats van impliciet aan te nemen dat beide kanten hetzelfde dialect spreken. Agent Card-signatures met JWS en JSON Canonicalization Scheme kunnen helpen de herkomst en integriteit van de card te controleren.
Behandel discovery nooit als blind vertrouwen in metadata. Valideer HTTPS, handtekening, issuer, versies, toegestane domeinen en daadwerkelijke bereikbaarheid. Cache cards met een korte, expliciete levensduur en ontwerp een gecontroleerd pad voor key rotation en capabilitywijzigingen.
Ontwerp de task lifecycle als een gedistribueerd systeem
Een task kan direct eindigen, lang lopen, input van de gebruiker nodig hebben of onderweg artifacts produceren. Streaming en push notifications maken voortgang zichtbaar, maar introduceren ook klassieke distributed-systemsproblemen: dubbele delivery, verbroken verbindingen, verouderde status, race conditions en onduidelijkheid over wie een taak mag annuleren.
Geef iedere opdracht daarom een idempotencystrategie, correlatie-ID, deadline en budget. Leg vast welke statusovergangen geldig zijn, wat een retry betekent en of cancel best-effort of gegarandeerd is. Een reconnect hoort de autoritatieve taskstatus op te halen in plaats van een oude stream blind voort te zetten.
Artifacts verdienen een echt productcontract. Gebruik mediatypes of schema's, leg herkomst en inputversie vast en scheid een voorlopig tussenresultaat van een goedgekeurde output. Losse tekst is soms genoeg voor een mens; voor downstream automatisering is een typed artifact vrijwel altijd sterker.
Security per aanroep, niet per agentnaam
De specificatie verwacht HTTPS en autorisatie op iedere operatie. Een gevonden Agent Card is dus geen bevoegdheid om alle aangeboden skills te gebruiken. Tokens horen caller-, audience- en scopespecifiek te zijn; credentials worden buiten de message- en taskpayload verkregen en horen nooit in een publieke Agent Card.
OAuth 2.0 met PKCE past bij gedelegeerde gebruikersflows; mTLS kan nuttig zijn voor sterke service-identiteit. Welke combinatie klopt hangt af van de trust boundary. Controleer daarnaast tenantcontext, dataminimalisatie, rate limits, payloadgrootte en welke artifacts een externe agent mag terugleveren.
Push endpoints en remote content verdienen extra wantrouwen. Sta alleen gevalideerde callback-URL's toe, voorkom SSRF naar interne netwerken, verifieer notificaties en behandel alle teruggeleverde tekst en bestanden als onbeproefde invoer. Prompt injection wordt niet opgelost door het protocol; autorisatie en outputvalidatie moeten de potentiële schade begrenzen.
- Publiceer geen geheimen of interne endpointdetails in een Agent Card.
- Autoriseer per operatie, skill, task en tenant—niet alleen op het bestaan van een geldig token.
- Valideer artifacts op mediatype, schema, omvang, malware en toegestane bestemming.
- Log beslissingen en tool- of agentcalls zonder persoonsgegevens en secrets onnodig te kopiëren.
- Ontwerp menselijke goedkeuring voor juridisch, financieel, veiligheidskritisch of moeilijk omkeerbaar werk.
Migreren naar v1.0 zonder schijncompatibiliteit
A2A 1.0 bevat bewuste breaking changes ten opzichte van 0.3. Het protobufmodel is normatief geworden, Part-formaten en enums veranderden en interfaces dragen hun eigen protocolversie. Een endpoint dat alleen dezelfde route of JSON-veldnaam behoudt, is daardoor niet automatisch semantisch compatibel.
Inventariseer eerst welke objecten, bindings en foutcodes de bestaande koppeling werkelijk gebruikt. Voeg contracttests toe voor discovery, SendMessage, taskstatus, cancel, streaming, artifacts en authenticatiefouten. Test vervolgens beide kanten tegen officiële SDK's en waar passend de Technology Compatibility Kit. Release met expliciete versieonderhandeling en meet mislukte onderhandelingen apart van applicatiefouten.
Wanneer A2A de verkeerde keuze is
Gebruik A2A niet alleen omdat twee componenten ‘agent’ heten. Draaien ze binnen één codebase, delen ze deployment en is het pad deterministisch, dan zijn een functieaanroep, queue of workflow-engine meestal eenvoudiger te begrijpen, goedkoper te draaien en makkelijker transactioneel te maken.
A2A verdient zijn plaats wanneer de grens echt bestaat: verschillende organisaties, leveranciers, frameworks, deploymentcycli of eigenaarschap—en wanneer capability discovery, lange taken of typed outputs betekenisvolle voordelen geven. De juiste architectuur gebruikt het protocol aan die grens en houdt de rest zo conventioneel mogelijk.
Een sterke eerste productiepilot kiest één smalle skill en één duidelijk artifact. Meet taakvoltooiing, latency, kosten, fouttypes, retries, autorisatieweigeringen en menselijke correcties. Pas wanneer die evidence stabiel is, vergroot je de autonomie of het aantal agents.