Wat is het A2A-protocol? Agent Cards en taken uitgelegd

Het A2A-protocol, kort voor Agent2Agent Protocol, is een open standaard voor communicatie tussen onafhankelijke AI-agentensystemen.

Die zin klinkt simpel, maar hij impliceert iets wat de meeste AI-agentendemos volledig overslaan. De meeste demos gaan er nog steeds van uit dat er één assistent, één runtime, één tool-loop en één eigenaar is: de agent kan zoeken, tools aanroepen, code schrijven, APIs queryen, misschien MCP-servers gebruiken, en een antwoord teruggeven.

A2A is ontworpen voor een andere wereld, een waarin agents door verschillende teams, frameworks, leveranciers, talen of organisaties kunnen zijn gebouwd. Het gaat ervan uit dat één agent een andere agent moet kunnen vinden, begrijpen wat deze kan, werk naar deze sturen, berichten wisselen, bestanden of gestructureerde outputs ontvangen, en een taak moet kunnen volgen tot voltooiing — wat het niet alleen een ander formaat voor tool-aanroepen maakt, maar een echte poging om AI-agents interoperabel te maken als gelijken.

De kernconcepten zijn:

• Agent Cards
• Agents en clients
• Taken
• Berichten
• Onderdelen
• Artefacten
• Taakstatussen
• Streaming en asynchrone updates

Dit artikel legt deze concepten uit in eenvoudige technische termen, met genoeg detail om te begrijpen waar A2A in echte multi-agent-systemen past.

De korte definitie

A2A is een protocol voor agent-tot-agent communicatie.

Het stelt één agent of client in staat om met een andere agent te communiceren via een gemeenschappelijk model. De ontvangende agent kan zijn capaciteiten beschrijven, werk aanvaarden, de levenscyclus van dat werk beheren, om meer input vragen, voortgang streamen en concrete outputs teruggeven.

Het doel is niet om te standaardiseren hoe een agent intern denkt — het is om te standaardiseren hoe agents met elkaar communiceren op hun grenzen.

Een A2A-agent kan intern gebruiken:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• aangepaste code
• MCP-servers
• private APIs
• vector databases
• workflow engines

De aanroeper hoeft niets hiervan te weten. Wat de aanroeper wel moet weten, is:

• Wat kan deze agent?
• Hoe praat ik ermee?
• Welke input accepteert het?
• Welke output kan het produceren?
• Hoe volg ik het werk?
• Hoe ontvang ik het resultaat?

Deze zes vragen definiëren de protocolgrens die A2A probeert te vestigen tussen onafhankelijk opererende agents.

Waarom A2A bestaat

AI-systemen bewegen van enkele assistenten naar netwerken van gespecialiseerde agents.

Een bedrijf kan hebben:

• Een support-agent
• Een facturatie-agent
• Een juridische review-agent
• Een DevOps-agent
• Een data-analyse-agent
• Een research-agent
• Een documentatie-agent
• Een code-review-agent

Elke agent kan zijn eigen tools, permissies, domeinkennis, prompts, geheugen, retrieval-systeem en auditregels hebben.

Zonder een gedeeld protocol wordt elke integratie custom — de support-agent heeft maatwerk-bedrading nodig naar de facturatie-agent, de facturatie-agent heeft zijn eigen verbinding nodig naar de juridische agent, en de research-agent heeft weer een andere nodig naar de documentatie-agent. Dat combinatorische overhead schaal niet goed naarmate het agentennetwerk groeit.

A2A geeft deze agents een gemeenschappelijke manier om te interacteren, waardoor het N×M-integratieproblem wordt gereduceerd tot één gedeeld contract. De belofte is niet magische autonomie; de belofte is interoperabiliteit.

A2A is geen MCP

A2A wordt vaak vergeleken met MCP, maar ze lossen verschillende problemen op.

MCP, of Model Context Protocol, gaat voornamelijk over het verbinden van een AI-app of agent met tools, resources en prompts, terwijl A2A voornamelijk gaat over het verbinden van agents met andere agents.

Een nuttig mentaal model is:

MCP: agent naar tool
A2A: agent naar agent

Bijvoorbeeld, een agent kan MCP gebruiken om toegang te krijgen tot:

• GitHub
• een bestandssysteem
• een database
• Slack
• een documentatiezoek-systeem
• een cloud API

Praktische gidsen voor het bouwen van die MCP-servers zijn beschikbaar voor Go en Python.

Dezelfde agent kan A2A gebruiken om werk af te dragen aan:

• een beveiligingsreview-agent
• een research-agent
• een planning-agent
• een compliance-agent
• een coding-agent

De twee protocollen kunnen en werken vaak samen. Een heldere architectuur is vaak:

A2A buiten de agentgrens.
MCP binnen de agentgrens.

Dat betekent dat andere agents communiceren met jouw agent via A2A, terwijl jouw agent intern MCP gebruikt om toegang te krijgen tot tools — een heldere scheiding van concerns die de externe interface stabiel houdt, ongeacht wat er intern verandert. Voor een gedetailleerde vergelijking van hoe de twee protocollen architectuurverantwoordelijkheid verdelen en wanneer je beide echt nodig hebt, zie A2A vs MCP: Do AI Agents Really Need Both Protocols?

Kernrollen in A2A

A2A gebruikt een eenvoudig rollenmodel gebouwd rond twee partijen: een agent die capaciteiten blootlegt, en een client die ze wil gebruiken.

De client kan zijn:

• een andere agent
• een orchestrator
• een assistent-toepassing
• een workflowsysteem
• een gateway
• een testharnas
• een app voor eindgebruikers

De agent kan zijn:

• een gespecialiseerde AI-service
• een domeinassistent
• een workflow-beheerende agent
• een externe leveranciersagent
• een interne enterprise-agent

Het belangrijke punt is dat de agent niet zomaar een functie is. Hij bezit een bepaalde capaciteit en maakt deze beschikbaar via een agent-interface.

Agent Cards

De Agent Card is een van de belangrijkste concepten in A2A.

Een Agent Card beschrijft een agent — het is het discover-document dat clients vertelt wat de agent is, wat het kan, hoe ermee te communiceren, en welke beperkingen gelden.

Denk aan een Agent Card als een mix van:

• service metadata
• capaciteitsverklaring
• API discover-document
• agent-profiel
• contractoppervlak

Een typische Agent Card kan dingen beschrijven zoals:

• agentnaam
• beschrijving
• service-eindpunt
• ondersteunde protocolfuncties
• ondersteunde input- en outputmodi
• beschikbare vaardigheden
• authenticatievereisten
• leveranciersinformatie
• versie-informatie
• documentatielinks
• optionele metadata

De Agent Card is belangrijk omdat agents niet gecompileerde kennis van elke andere agent nodig hebben.

Een client kan de kaart inspecteren en beslissen:

• Is dit de juiste agent voor het werk?
• Ondersteunt het het contenttype dat ik nodig heb?
• Ondersteunt het streaming?
• Vereist het authenticatie?
• Welke vaardigheden adverteert het?
• Kan het het soort artefact teruggeven dat ik nodig heb?

In praktische systemen worden Agent Cards de basis voor agent-registers, developer portals en interne agent-catalogi — de machine-leesbare tegenhanger van een servicedirectory waar clients kunnen opzoeken wat beschikbaar is voordat ze zich aan een integratie verbinden.

Agent Cards zijn capaciteitsgrenzen

Een Agent Card mag niet worden behandeld als marketingtekst — het is een capaciteitsgrens waar andere systemen op runtime op vertrouwen.

Als je agentkaart zegt dat je agent financiële analyse kan uitvoeren, kunnen clients beginnen met het afdragen van financiële analysetaken aan deze agent. Als het zegt dat de agent bestanden accepteert, kunnen clients bestanden sturen. Als het zegt dat de agent streaming ondersteunt, kunnen clients voortgangsevenementen verwachten.

Slechte Agent Cards creëren slechte systemen omdat routeringsbeslissingen en capaciteitsaannames door het hele agentennetwerk cascaderen. Een nuttige Agent Card moet zijn:

• specifiek
• nauwkeurig
• stabiel
• versiebeheerd
• beveiligingsbewust
• eerlijk over beperkingen

Een vaag vaardigheid als “doet zakelijke taken” is niet nuttig.

Een betere vaardigheid is:

Analys SaaS factuurgegevens en produceer een maandelijkse uitgavenoverzicht.

Nog beter, inclusief verwachte input- en outputmodi.

Input: CSV- of JSON-factuurregistraties.
Output: Markdown-overzicht en gestructureerde JSON-totaalsommen.

Hoe preciezer de Agent Card, hoe makkelijker het is voor andere agents om taken correct te routeren.

Agent Discover

Agent discover is het proces van het vinden van een Agent Card.

In eenvoudige implementaties kan discover statisch zijn. Een client kent al de URL van een specifieke agent.

In grotere implementaties kan discover betrekking hebben op:

• een register
• een developer portal
• een interne catalogus
• DNS-gebaseerde discover
• configuratiebeheer
• omgeving-specifieke routing
• tenant-bewuste gateways

De belangrijke ontwerpkeuze is of discover openbaar, privé of machtigd is.

Niet elke agent moet door iedereen te vinden zijn — een interne payroll-agent mag niet dezelfde Agent Card blootleggen aan elke aanroeper, en een partner-agent mag alleen partner-veilige vaardigheden zien. Agent discover is niet zomaar een handigheidsfunctie; het is onderdeel van je beveiligings- en governance-model, en het scopen van zichtbaarheid is een eerste-klasse ontwerpbeslissing.

Taken

Een Taak vertegenwoordigt werk dat door een agent wordt uitgevoerd.

Hier wordt A2A interessanter dan eenvoudige request-response APIs.

Sommige agent-interacties zijn snel. Een client stuurt een bericht, en de agent geeft een direct antwoord.

Maar veel echte agent-workflows zijn niet instant.

Een taak kan betrekking hebben op:

• het doorzoeken van meerdere bronnen
• het vragen om verduidelijking
• het aanroepen van tools
• het afdragen van werk
• het wachten op goedkeuring
• het genereren van een rapport
• het produceren van bestanden
• het streamen van voortgang
• het afhandelen van retries
• het teruggeven van meerdere artefacten

A2A modeleert dit soort werk als een Taak — waardoor het werk een identiteit en een levenscyclus krijgt, wat belangrijk is omdat langlopend agent-werk moet worden gevolgd, geïnspecteerd en potentieel geannuleerd of opnieuw geprobeerd moet worden.

Taaklevenscyclus

Een taak kan door verschillende statussen bewegen.

Het exacte statusmodel hangt af van de protocolversie en implementatie, maar het basisidee is eenvoudig:

• ingediend
• aan het werken
• input vereist
• voltooid
• mislukt
• geannuleerd
• afgewezen

Het belangrijke punt is dat een taak niet zomaar een response-payload is — het is een lopende eenheid van werk met zijn eigen status die een client op elk moment kan queryen. Een client kan de taakstatus gebruiken om te begrijpen wat er gebeurt:

• Heeft de agent de taak aanvaard?
• Werkt het nog?
• Heeft het meer input nodig?
• Is het succesvol afgerond?
• Is het mislukt?
• Is het geannuleerd?
• Zijn er artefacten beschikbaar?

Dit is vooral nuttig voor workflows die seconden, minuten of langer duren.

Bijvoorbeeld, een research-agent kan onmiddellijk een taak teruggeven, en dan op de achtergrond doorgaan met werken terwijl het voortgangsevenementen streamt of het resultaat later beschikbaar maakt.

Stateless Bericht of Stateful Taak

A2A ondersteunt zowel eenvoudige als complexe interacties.

Voor een eenvoudige interactie kan een agent een direct Bericht teruggeven; voor een complexe interactie kan het een Taak teruggeven. Dit onderscheid is belangrijk omdat niet alles taaktracking nodig heeft, en het overontwerpen van korte interacties naar volledige taakworkflows onnodige overhead toevoegt.

Als een client vraagt:

Samenvat deze ene alinea.

Dan kan een direct antwoord voldoende zijn.

Als een client vraagt:

Onderzoek de vijf beste open source vector databases, vergelijk ze, en produceer een migratieaanbeveling.

Dan is een taak gepaster.

De praktische regel is eenvoudig: gebruik een direct Bericht voor eenvoudige, onmiddellijke interacties, en gebruik een Taak voor langlopende, stateful, auditabele of artefact-producerende werk.

Berichten

Berichten zijn de communicatie-eenheden die tussen client en agent worden uitgewisseld.

Een bericht kan één of meerdere onderdelen bevatten.

Een bericht kan vertegenwoordigen:

• een gebruikerrequest
• een agentantwoord
• een verduidelijkingsvraag
• aanvullende input
• taakgerelateerde communicatie
• voortgangscontext
• gestructureerde instructies

Berichten zijn niet zomaar strings — agentcommunicatie heeft vaak veel meer nodig dan platte tekst, en de berichtstructuur is ontworpen om dit te accommoderen.

Een bericht kan bevatten:

• tekst
• bestanden
• gestructureerde JSON
• afbeeldingen
• referenties
• metadata

Het bericht is de envelop; de onderdelen zijn daadwerkelijke getypeerde content erin.

Onderdelen

Een Onderdeel is een stuk content binnen een bericht of artefact.

Zo ondersteunt A2A multimodale en gestructureerde communicatie.

Een onderdeel kan verschillende contenttypes bevatten, zoals:

• tekst
• bestandgegevens
• gestructureerde data
• binaire content bij referentie
• JSON-achtige data

Een onderdeel kan ook metadata bevatten, zoals:

• mediatype
• bestandsnaam
• aanvullende context

Het mediatype is belangrijk omdat het de ontvangende agent vertelt hoe de content te interpreteren.

Bijvoorbeeld:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Dit is een van de onderschatte aspecten van A2A. Agentcommunicatie mag niet alles reduceren tot platte tekst — als een downstream-agent een spreadsheet, afbeelding, JSON-payload, logbestand of PDF nodig heeft, moet het protocol die content behouden als content in plaats van het te verdraaien in een alinea. Goede agent-systemen vermijden deze onnodige tekstflessenhals door elk onderdeel zijn natuurlijke mediatype te laten dragen tot bij de consument.

Artefacten

Artefacten zijn concrete outputs die door een agent worden geproduceerd tijdens taakverwerking.

Dit is anders dan een algemeen bericht: een bericht is communicatie tussen agents, terwijl een artefact een concreet leverbaar is dat de taak heeft geproduceerd.

Voorbeelden van artefacten zijn:

• een markdown-rapport
• een JSON-analyseresultaat
• een CSV-export
• een gegenereerde afbeelding
• een PDF-document
• een codepatch
• een testresultaatbestand
• een deploymentplan
• een diagram
• een data-extract

Dit onderscheid is in de praktijk nuttig. Wanneer een research-agent zegt “Ik heb het antwoord gevonden”, is dat een bericht. Wanneer het market-analysis.md, sources.json en risk-summary.csv teruggeeft, zijn dat artefacten — concrete outputs die het werk van de taak inspecteerbaar, herbruikbaar en composeerbaar maken. Het artefact van één agent wordt de input van een andere agent zonder verlies van structuur.

Berichten vs Artefacten

Een eenvoudige manier om erover na te denken:

Berichten zijn conversatie.
Artefacten zijn output.

Berichten helpen agents om te coördineren; artefacten zijn wat de taak daadwerkelijk heeft geproduceerd.

Bijvoorbeeld, in een softwareontwikkelingsworkflow:

• De client stuurt een bericht met een verzoek om een bugfix.
• De coding-agent stuurt berichten met verduidelijkingsvragen.
• De coding-agent werkt aan de taak.
• De agent geeft artefacten terug, zoals een patchbestand, testoutput en uitleg.

Deze scheiding is handig omdat het vermijdt dat taakcoördinatie wordt vermengd met leveringen, waardoor het veel makkelijker is om te loggen, te auditen en outputs door te geven aan downstream-consumenten.

Een praktisch voorbeeld

Stel je voor dat een primaire assistent hulp nodig heeft van een documentatie-agent.

De gebruiker vraagt:

Maak ontwikkelaarsdocumentatie voor onze nieuwe billing webhook API.

De primaire assistent checkt een agentregister en vindt een documentatie-agent.

De documentatie-agent heeft een Agent Card die zegt dat het kan:

• API-documentatie schrijven
• OpenAPI-specs accepteren
• Markdown-stijlgidsen accepteren
• Markdown-docs produceren
• voorbeelden produceren in Python en JavaScript
• langlopende taken ondersteunen
• artefacten teruggeven

De primaire assistent stuurt een bericht met:

• een korte instructie
• een OpenAPI-bestand
• een stijlgids
• metadata over het doel publiek

De documentatie-agent creëert een Taak.

De taak komt in een werkstatus.

De documentatie-agent kan berichten sturen zoals:

Ik extraheer eindpuntbeschrijvingen.

Dan:

Ik heb verduidelijking nodig over authenticatievoorbeelden.

De primaire assistent verstrekt de ontbrekende input.

De taak gaat door.

Tot slot geeft de documentatie-agent artefacten terug:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Dat is het A2A-model in actie: niet zomaar “roep deze functie aan”, maar “draag deze taak af aan een andere agent, communiceer indien nodig, en volg het resultaat tot voltooiing.”

Waarom taken belangrijk zijn voor echte systemen

Taken zijn wat A2A geschikt maken voor serieuze workflows.

Een normale HTTP API-aanroep is vaak te dun voor agent-werk. Agent-taken kunnen onzekerheid, meerdere stappen, tussenresultaten en navolgvragen bevatten.

Een Taak geeft je een plek om te hechten:

• status
• geschiedenis
• berichten
• artefacten
• fouten
• metadata
• voortgang
• annulering
• auditinformatie

Dit is nuttig voor:

• researchworkflows
• codegeneratie
• data-analyse
• compliancereview
• documentproductie
• incidentonderzoek
• meervoudig stappenplanning
• workflow met menselijke goedkeuring

Zonder een taakmodel bouwen developers deze logica meestal zelf met custom job IDs, queues, status-eindpunten en webhook-callbacks — A2A probeert de agent-specifieke versie van dat patroon te standaardiseren zodat je het niet voor elke nieuwe agent-integratie opnieuw hoeft uit te vinden.

Streaming en asynchroon werk

A2A ondersteunt het idee dat agent-werk streaming of asynchroon kan zijn.

Streaming is nuttig wanneer de client live updates wil.

Bijvoorbeeld:

• voortgangsevenementen
• partiële resultaten
• tussenstatus
• gegenereerde tekst
• stapupdates

Asynchrone workflows zijn nuttig wanneer de taak lang kan duren of de client geen open verbinding kan vasthouden.

Bijvoorbeeld:

• achtergrondresearch
• grote documentgeneratie
• multi-agent review
• data-verwerking
• menselijke goedkeuring
• batchanalyse

In de praktijk moet een robuust A2A-systeem worden ontworpen rond drie modi: onmiddellijk antwoord voor eenvoudig werk, streaming voor interactief langlopend werk, en asynchroon voor duurzaam achtergrondwerk dat elke enkele verbinding kan overleven. Voor SSE, push-webhooks, herinschrijving, HITL via input_required, foutafhandeling en productiechecklists, zie A2A Streaming and Async Tasks for Long-Running Agent Workflows.

Agent Cards en streamingondersteuning

Een Agent Card kan adverteren of een agent streaming ondersteunt.

Dit is belangrijk omdat clients niet kunnen aannemen dat elke agent streaming ondersteunt — sommige agents kunnen alleen eenvoudige request-response ondersteunen, sommige kunnen taakpolling ondersteunen, en anderen kunnen push-meldingen of server-sent events ondersteunen. Een goede client inspecteert de Agent Card voordat hij een interactiepatroon kiest, wat betekent dat Agent Cards niet zomaar documentatie zijn: ze bepalen direct runtime-gedrag.

A2A en multimodale agents

A2A is ontworpen om meer te ondersteunen dan platte tekst.

Dit is belangrijk omdat echte agent-systemen steeds vaker gemengde inputs en outputs verwerken:

• tekst
• afbeeldingen
• audio
• video
• PDFs
• spreadsheets
• gestructureerde JSON
• logs
• code
• diagrammen

Als elke agentgrens alles converteert naar tekst, kan belangrijke informatie verloren gaan.

Bijvoorbeeld, een visuele troubleshooting-agent moet een afbeelding ontvangen als een afbeelding, niet als een zwakke tekstbeschrijving. Een finance-agent moet gestructureerde spreadsheetdata ontvangen, niet een gekopieerd alinea. Een code-review-agent moet sourcebestanden of diffs ontvangen, niet een vaag overzicht.

Onderdelen en mediatypes zijn hoe A2A rijkere content behoudt over agentgrenzen heen — en dit is een van de plekken waar het protocol belangrijker is dan het op het eerste gezicht lijkt, omdat informatieverlies op de grens compenseert over elke hop in een multi-agent-keten.

A2A is geen agent-framework

A2A vertelt je niet hoe je een agent moet bouwen.

Het definieert niet:

• redeneerstrategie
• planingsalgoritme
• geheugensysteem
• vector database
• promptsjabloon
• modelleverancier
• toolframework
• orchestratie-runtime
• evaluatiemethode

Dat is een feature, geen bug. A2A is een grensprotocol dat verschillende agent-implementaties in staat stelt te communiceren zonder te vereisen dat ze dezelfde interne architectuur delen — net zoals HTTP je niet vertelt hoe je een webapplicatie moet bouwen, het alleen definieert hoe systemen communiceren. A2A moet op dezelfde manier worden begrepen.

A2A is geen vervanging voor APIs

A2A vervangt ook niet elke API.

Als je een deterministische service hebt met een stabiel request-response contract, kan een normale API beter zijn.

Bijvoorbeeld:

• valutaconversie
• adresvalidatie
• factuuropzochten
• afbeeldingsschaal
• zoek-eindpunt
• feature flag opzoeken
• interne CRUD-service

Deze worden niet automatisch agents alleen omdat ze door een AI-systeem worden aangeroepen. A2A heeft zin wanneer het externe systeem echt als een agent gedraagt:

• het bezit een taak
• het kan om meer input vragen
• het kan intern tools gebruiken
• het kan tijd nodig hebben
• het kan artefacten produceren
• het heeft capaciteiten die de moeite waard zijn om te ontdekken
• het kan opereren als een peer in een grotere workflow

Gebruik A2A niet alleen omdat het modern klinkt — gebruik het wanneer de abstractie echt past bij het probleem.

Waar A2A past in AI-systeemarchitectuur

A2A past het beste op de grens tussen onafhankelijk deploybare agents.

Een nuttige architectuur zou er zo uit kunnen zien:

Gebruiker
  |
  v
Primaire assistent
  |
  |-- A2A --> Research agent
  |-- A2A --> Coding agent
  |-- A2A --> Compliance agent
  |-- A2A --> Documentatie agent

Elke specialistagent kan intern tools gebruiken:

Research agent
  |
  |-- MCP --> web search
  |-- MCP --> document store
  |-- MCP --> vector database

Dit geeft je aparte lagen:

Gebruikersinterface laag
Agent-coördinatie laag
Tool-integratie laag
Data- en executielag

A2A leeft in de agent-coördinatielaag, MCP leeft vaak in de tool-integratielaag, en normale APIs, queues, databases en opslagsystemen leven daaronder — elke laag met zijn eigen abstractie en eigen falingsmodi. Voor een cross-cutting map van hoe LLM-inferentie, geheugen, routing, tooling en observability samenpassen binnen productie-assistents, zie AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

Architectuurpatroon: Orchestrator en specialisten

Het meest voorkomende A2A-patroon is waarschijnlijk orchestrator plus specialisten.

In dit patroon ontvangt één primaire agent het gebruikersverzoek en draagt stukken werk af aan specialistagents.

Voorbeeld:

Primaire assistent
  |
  |-- A2A --> Juridische agent
  |-- A2A --> Finance agent
  |-- A2A --> Research agent
  |-- A2A --> Schrijvende agent

Dit patroon is makkelijk te begrijpen: de orchestrator bezit de algehele workflow, en specialistagents bezitten domeinspecifiek werk. Het nadeel is dat de orchestrator een bottleneck kan worden, en hij heeft een solide routingsstrategie nodig om effectief af te dragen — de onderliggende modelselectie en orchestratie-trade-offs worden behandeld in Multi-Model System Design: When One Model Isn’t Enough. Toch is dit voor de meeste teams de beste eerste multi-agent-architectuur om te gebruiken voordat je complexere topologieën exploreert.

Architectuurpatroon: Peer-agents

In een peer-to-peer patroon kunnen agents met elkaar directer communiceren.

Bijvoorbeeld:

Research agent --> Data agent --> Charting agent --> Schrijvende agent

Dit kan krachtig zijn, maar het is moeilijker te controleren.

Je hebt sterke regels nodig voor:

• wie wie kan bellen
• welke context kan worden gedeeld
• hoe lussen worden voorkomen
• wie de finale output bezit
• hoe kosten worden beheerst
• hoe delegatie wordt geaudited

Peer-agentnetwerken klinken elegant, maar ze kunnen snel chaotisch worden — gebruik ze alleen wanneer je sterke governance-regels hebt en duidelijke eigendom over elke edge in de grafiek.

Architectuurpatroon: A2A Gateway

Een productievriendelijker patroon is een A2A-gateway.

In plaats dat elke agent direct een andere agent belt, stroomt verkeer door een gateway.

De gateway kan afhandelen:

• authenticatie
• autorisatie
• routing
• tenant-mapping
• logging
• rate limits
• policychecks
• protocolversie-handling
• observability
• audittrails

Dit is vooral nuttig in enterprise-omgevingen, waar de gateway het controlepaneel wordt voor agentcommunicatie — het afdwingen van policy op één plaats in plaats van het opnieuw implementeren over elke agent. In kleinere systemen kan dit overkill zijn, maar in grotere systemen met meerdere teams en leveranciers wordt het vaak eerder dan verwacht noodzakelijk.

Beveiligingsoverwegingen

A2A-beveiliging verdient serieuze aandacht.

Agent-tot-agent communicatie kan gevoelige context over grenzen verplaatsen. Het kan ook werk afdragen aan systemen die hun eigen tools en permissies kunnen hebben.

De kernbeveiligingsvragen zijn:

• Welke agents mogen deze agent ontdekken?
• Welke agents mogen er taken naartoe sturen?
• Welke authenticatie is vereist?
• Welke permissies zijn gekoppeld aan de aanroeper?
• Kan één agent gebruikersautoriteit delegeren aan een andere?
• Welke data kan worden opgenomen in berichten?
• Welke artefacten kunnen worden teruggegeven?
• Hoe wordt de taak geaudited?
• Kan de ontvangende agent tools of andere agents aanroepen?
• Hoe worden geheimen beschermd?

Agent Cards mogen geen statische geheimen bevatten, en gevoelige Agent Cards moeten worden beschermd achter authenticatie in plaats van openbaar gepubliceerd te worden. Verschillende clients hebben vaak verschillende weergaven van dezelfde agent nodig — een interne aanroeper kan meer vaardigheden zien dan een externe partner, terwijl een publieke client mogelijk alleen een beperkte set veilige capaciteiten ziet.

Beveiliging mag niet worden toegevoegd nadat het agentennetwerk is gebouwd; het moet het netwerk vanaf het begin vormen, omdat het achteraf toevoegen van auth- en permissiegrenzen over een live agententopologie aanzienlijk moeilijker is dan ze vanaf het begin in te ontwerpen. Voor de volledige behandeling — threat model, identiteitslagen, gateway-controlepaneel, delegatiescope en audittrails — zie A2A and MCP Agent Security: Identity, Delegation, and Audit Trails.

Observability-overwegingen

A2A-systemen hebben sterke observability nodig.

Wanneer een taak agentgrenzen overschrijdt, wordt debuggen aanzienlijk moeilijker omdat geen enkel systeem het volledige beeld heeft. Je moet weten:

• welke agent de taak heeft gecreëerd
• welke agent hem heeft aanvaard
• welke berichten zijn uitgewisseld
• welke statusveranderingen hebben plaatsgevonden
• welke artefacten zijn geproduceerd
• welke fouten zijn opgetreden
• hoe lang elke stap duurde
• welke tools intern zijn gebruikt
• of een andere agent is aangeroepen
• wie risicovolle acties heeft goedgekeurd

Een nuttige trace moet het werk volgen over de volledige keten.

Bijvoorbeeld:

gebruikerrequest
  -> primaire assistent taak
  -> research agent taak
  -> document search tool aanroep
  -> samenvattingsarte fact
  -> eindantwoord

Zonder die end-to-end trace worden multi-agent-systemen in productie zeer moeilijk te vertrouwen — je kunt niet met vertrouwen beantwoorden waarom het systeem een bepaalde output heeft geproduceerd, laat staan identificeren waar het fout ging. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production behandelt de instrumentatie- en toolingzijde van dit probleem in detail.

Veelgemaakte fouten

Fout 1: Elke tool een agent noemen

Niet elke tool is een agent.

Een rekenmachine is een tool. Een bestandlezer is een tool. Een databasequery-eindpunt is een tool.

Als het geen taak bezit, om input vraagt, artefacten produceert, of zich gedraagt als een onafhankelijke peer, heeft het waarschijnlijk geen A2A nodig.

Fout 2: Agent Cards te vaag maken

Een Agent Card mag niet zeggen:

Deze agent helpt met zakelijke taken.

Dat is nutteloos voor elke agent die probeert werk intelligent te routeren. Een goede kaart moet zeggen wat de agent daadwerkelijk doet, wat het accepteert, wat het teruggeeft, en welke beperkingen gelden.

Fout 3: Taakstatus negeren

Als je A2A gebruikt maar elke interactie behandelt als request-response, mis je veel van de waarde.

Het taakmodel is een van de primaire redenen om A2A te gebruiken in plaats van een platte API — het overslaan betekent dat je dezelfde levenscyclus-trackinglogica in elke integratie opnieuw bouwt.

Fout 4: Alles als tekst teruggeven

A2A ondersteunt gestructureerde en multimodale content. Gebruik het.

Als de output een rapport is, geef dan een rapportarte fact terug.

Als de output JSON is, geef dan gestructureerde data terug.

Als de output een bestand is, geef dan een bestand terug.

Flatten niet alles naar platte tekst tenzij platte tekst de juiste output is.

Fout 5: Geen permissiemodel

Agentennetwerken zonder permissiegrenzen zijn risicovol.

Elke agent mag niet elke andere agent aanroepen met elke soort data — gebruik authenticatie, autorisatie en audittrails om het principe van minste voorrechten af te dwingen over het agentennetwerk.

Wanneer moet je A2A gebruiken?

Gebruik A2A wanneer je echte agentgrenzen hebt.

Goede redenen zijn:

• agents worden bezit door verschillende teams
• agents worden deployed als aparte services
• agents zijn gebouwd met verschillende frameworks
• agents moeten elkaar ontdekken
• agents moeten taken delegeren
• taken kunnen langlopend zijn
• resultaten kunnen artefacten bevatten
• clients moeten interne tools niet kennen
• agentcapaciteitsmetadata is belangrijk

Slechte redenen zijn:

• het klinkt modern
• je wilt één functie aanroepen
• je hebt een single-agent app
• een normale API zou werken
• MCP lost al je tool-integratieprobleem op

A2A is krachtig wanneer het systeem echt multi-agent is; het is onnodige ceremonie wanneer het systeem dat niet is, en de kosten van die ceremonie — toegevoegde concepten, infrastructuur, debugoppervlak en beveiligingsvereisten — zijn reëel.

Een minimaal mentaal model

Als je maar één ding onthoudt, onthoud dan dit:

Agent Card: wat de agent kan.
Bericht: wat agents elkaar zeggen.
Onderdeel: getypeerde content binnen een bericht of artefact.
Taak: werk dat de agent bezit.
Artefact: output die de taak heeft geproduceerd.

Dat is de kern van A2A — de rest gaat vooral over het maken van die vijf concepten betrouwbaar, observeerbaar en veilig genoeg om te gebruiken in echte productiesystemen.

Eindgedachten

A2A is niet zomaar een AI-acroniem — het is onderdeel van een bredere verschuiving van geïsoleerde assistenten naar interoperabele agentsystemen. Die verschuiving zal niet overal tegelijk plaatsvinden, en veel applicaties zullen single-agent-systemen blijven met goede tool-toegang waar MCP en normale APIs volledig voldoende zijn.

Maar zodra agents apart deployed peers worden, heb je sterkere grenzen nodig: discover, taakeigendom, berichten die meer dragen dan tekst, artefacten als first-class outputs, en beveiliging, state en observability die agentgrenzen overschrijden. Dat is de ruimte die A2A probeert in te nemen, en het is een echt ander probleem dan het tool-integratieprobleem dat MCP oplost.

Voor een praktische kijk op waar A2A in 2026 daadwerkelijk productietractie heeft — inclusief adoptieniveaus, beveiligingszorg, het enterprise-use case en een besliskader — zie Google A2A Protocol in 2026: Adoption, Hype, and Reality.

Mijn mening: begin niet met A2A voor kleine projecten. Begin met een nuttige agent, goede tools en een heldere architectuur — de AI Systems cluster behandelt self-hosted assistents, MCP-servers en agentgeheugen als een verbonden set als je de bredere context wilt. Maar wanneer je “tool” begint te lijken op een andere autonome specialist met zijn eigen taaklevenscyclus, is het waarschijnlijk niet zomaar een tool meer — en dat is wanneer A2A interessant wordt.

Bronnen

• A2A Protocol Specificatie: https://a2a-protocol.org/latest/specification/
• A2A Kernconcepten: https://a2a-protocol.org/latest/topics/key-concepts/
• A2A Levensloop van een Taak: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2A Agent Discover: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming en Asynchrone Operaties: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A en MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/