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

Het A2A-protocol, afkorting 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-agentendemo’s volledig overslaan. De meeste demo’s gaan er nog steeds van uit dat er één assistent is, één runtime-omgeving, één tool-loop en één eigenaar — de agent kan zoeken, tools aanroepen, code schrijven, API’s 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 er van uit dat één agent een andere agent moet kunnen vinden, begrijpen wat deze kan, werk naar deze sturen, berichten uitwisselen, bestanden of gestructureerde outputs ontvangen, en een taak moet kunnen volgen tot voltooiing — waardoor het niet zomaar nog een tool-aanroepformaat is, maar een echte poging om AI-agents interoperabel te maken als gelijkwaardige partijen.

De kernconcepten zijn:

• Agent Cards
• Agents en clients
• Taken
• Berichten
• Delen (Parts)
• Artefacten
• Taakstatussen
• Streaming en asynchrone updates

Dit artikel legt deze concepten uit in heldere technische termen, met voldoende detail om te begrijpen waar A2A past in echte multi-agentensystemen.

De korte definitie

A2A is een protocol voor agent-to-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 mogelijkheden beschrijven, werk accepteren, 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 doel is om te standaardiseren hoe agents met elkaar communiceren op hun grenzen.

Een A2A-agent kan intern gebruikmaken van:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• eigen code
• MCP-servers
• private API’s
• vectordatabases
• workflow-engines

De aanroeper hoeft niets van dit alles te weten. Wat de aanroeper wel moet weten, is:

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

Die 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 specialistische agents.

Een bedrijf kan bijvoorbeeld hebben:

• Een supportagent
• Een factureringsagent
• Een juridische review-agent
• Een DevOps-agent
• Een data-analyseagent
• Een onderzoeksagent
• Een documentatieagent
• Een code-reviewagent

Elke agent kan zijn eigen tools, rechten, domeinkennis, prompts, geheugen, retrieval-systeem en audit-regels hebben.

Zonder een gedeeld protocol wordt elke integratie maatwerk — de supportagent heeft op maat gemaakte bekabeling nodig naar de factureringsagent, de factureringsagent heeft zijn eigen verbinding nodig naar de juridische agent, en de onderzoeksagent heeft weer een andere nodig naar de documentatieagent. Dat combinatorische overhead schaalt niet goed naarmate het agentennetwerk groeit.

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

A2A is niet 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-applicatie 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 documentatiezoeksysteem
• 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 onderzoeksagent
• een planeringsagent
• een compliance-agent
• een coderingagent

De twee protocollen kunnen en doen vaak samenwerken. Een schone architectuur is vaak:

A2A buiten de agentengrens.
MCP binnen de agentengrens.

Dat betekent dat andere agents met jouw agent communiceren via A2A, terwijl jouw agent intern MCP gebruikt om toegang te krijgen tot tools — een schone scheiding van zorgen 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 ze echt beide 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 mogelijkheden blootlegt, en een client die deze wil gebruiken.

De client kan zijn:

• een andere agent
• een orchestrator
• een assistentapplicatie
• een workflowsysteem
• een gateway
• een testharnas
• een app voor eindgebruikers

De agent kan zijn:

• een specialistische AI-service
• een domeonassistent
• een workflow-beheeragent
• een externe leveranciersagent
• een interne enterprise-agent

Het belangrijke is dat de agent niet zomaar een functie is. Hij bezit een bepaalde capaciteit en legt deze bloot via een agentinterface.

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 hij kan, hoe ermee gecommuniceerd moet worden, en welke beperkingen van toepassing zijn.

Beschouw een Agent Card als een mix van:

• servicemetadata
• capaciteitsverklaring
• API-discovery-document
• agentprofiel
• 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 hardcoded kennis van elke andere agent nodig zouden moeten hebben.

Een client kan de card inspecteren en beslissen:

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

In praktische systemen worden Agent Cards de basis voor agentregisters, developerportalen en interne agentcatalogi — de machine-leesbare equivalent van een servicedirectory waar clients kunnen opzoeken wat er beschikbaar is voordat ze zich commiten aan een integratie.

Agent Cards zijn capaciteitsgrenzen

Een Agent Card moet niet worden behandeld als marketingtekst — het is een capaciteitsgrens waarop andere systemen op runtime zullen vertrouwen.

Als je agentcard zegt dat je agent financiële analyse kan uitvoeren, kunnen clients beginnen met het afdragen van financiële analytewerk aan hem. Als hij zegt dat de agent bestanden accepteert, kunnen clients bestanden verzenden. Als hij zegt dat de agent streaming ondersteunt, kunnen clients voortgangsverwachtingen verwachten.

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

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

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

Een betere vaardigheid is:

Analyseer SaaS-factuurdata en produceer een maandelijkse uitgavenoverzicht.

Nog beter, sluit verwachte input- en outputmodi in.

Input: CSV- of JSON-factuurrecords.
Output: Markdown-overzicht en gestructureerde JSON-totals.

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

Agent Discovery

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

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

In grotere deploymenten kan discovery betrekking hebben op:

• een register
• een developerportaal
• een interne catalogus
• DNS-gebaseerde discovery
• configuratiemanagement
• omgevingspecifieke routing
• tenant-bewuste gateways

Het belangrijke ontwerpkeuze is of discovery publiek, privé of bevoegd is.

Niet elke agent moet vindbaar zijn door iedereen — een interne payroll-agent mag niet dezelfde Agent Card blootleggen aan elke aanroeper, en een partneragent mag alleen partner-veilige vaardigheden zien. Agent discovery is niet zomaar een handigheidsfunctie; het is onderdeel van je beveiligings- en governance-model, en het scopen van zichtbaarheid is een ontwerpkeuze van de eerste orde.

Taken

Een Taak vertegenwoordigt werk dat wordt uitgevoerd door een agent.

Hier wordt A2A interessanter dan eenvoudige request-response API’s.

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

Maar veel echte agentworkflows zijn niet direct.

Een taak kan betrekking hebben op:

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

A2A modelt dit soort werk als een Taak — geeft het werk een identiteit en een levenscyclus, wat belangrijk is omdat langdurig agentwerk moet worden gevolgd, geïnspecteerd en potentieel geannuleerd of opnieuw geprobeerd.

Taaklevenscyclus

Een taak kan door verschillende staten gaan.

Het exacte statemodel 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 responspayload is — het is een lopende eenheid van werk met zijn eigen staat 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 geaccepteerd?
• Is hij nog aan het werken?
• Heeft hij meer input nodig?
• Is hij succesvol afgerond?
• Is hij mislukt?
• Is hij geannuleerd?
• Zijn er artefacten beschikbaar?

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

Bijvoorbeeld, een onderzoeksagent kan direct een taak teruggeven, en daarna in de achtergrond blijven werken terwijl hij voortgangsgebeurtenissen 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 hij een Taak teruggeven. Dit onderscheid is belangrijk omdat niet alles taaktracking nodig heeft, en het overontwerp van korte interacties naar volledige taakworkflows onnodige overhead toevoegt.

Als een client vraagt:

Samenvat dit ene alinea.

Dan kan een direct antwoord voldoende zijn.

Als een client vraagt:

Onderzoek de top vijf open-source vectordatabases, vergelijk ze, en produceer een migratierecommendatie.

Dan is een taak geschikter.

De praktische regel is eenvoudig: gebruik een direct Bericht voor eenvoudige, directe interacties, en gebruik een Taak voor langdurig, stateful, auditbaar of artefact-producerend werk.

Berichten

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

Een bericht kan één of meerdere delen bevatten.

Een bericht kan vertegenwoordigen:

• een gebruikersverzoek
• 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 dat mogelijk te maken.

Een bericht kan bevatten:

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

Het bericht is de envelop; de delen zijn de daadwerkelijke getypeerde inhoud erin.

Delen (Parts)

Een Part is een stuk inhoud binnen een bericht of artefact.

Dit is hoe A2A multimodale en gestructureerde communicatie ondersteunt.

Een deel kan verschillende contenttypes bevatten, zoals:

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

Een deel kan ook metadata bevatten, zoals:

• mediatype
• bestandsnaam
• aanvullende context

Het mediatype is belangrijk omdat het de ontvangende agent vertelt hoe de inhoud moet worden geïnterpreteerd.

Bijvoorbeeld:

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

Dit is een van de onderschatte aspecten van A2A. Agentcommunicatie moet niet alles reduceren tot platte tekst — als een downstream-agent een spreadsheet, afbeelding, JSON-payload, logbestand of PDF nodig heeft, moet het protocol die inhoud behouden als inhoud in plaats van het te verdraaien tot een alinea. Goede agentsystemen vermijden deze onnodige tekstflessenhals door elk deel zijn natuurlijke mediatype te laten dragen tot aan 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 praktisch nuttig. Wanneer een onderzoeksagent zegt “Ik heb het antwoord gevonden”, is dat een bericht. Wanneer hij 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 simpele 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 verzoek om een bugfix.
• De coderingagent stuurt berichten met verduidelijkingsvragen.
• De coderingagent werkt aan de taak.
• De agent geeft artefacten terug, zoals een patchbestand, testoutput en uitleg.

Deze scheiding is nuttig omdat het vermijdt dat taakcoördinatie wordt gemengd met leveringen, waardoor het veel gemakkelijker wordt 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 documentatieagent.

De gebruiker vraagt:

Maak ontwikkelaarsdocumentatie voor onze nieuwe billing webhook API.

De primaire assistent checkt een agentregister en vindt een documentatieagent.

De documentatieagent heeft een Agent Card die zegt dat hij kan:

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

De primaire assistent stuurt een bericht met:

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

De documentatieagent creëert een Taak.

De taak gaat naar een werkende staat.

De documentatieagent kan berichten sturen zoals:

Ik ben eindpuntbeschrijvingen aan het extraheren.

Dan:

Ik heb verduidelijking nodig over authenticatievoorbeelden.

De primaire assistent levert de ontbrekende input.

De taak gaat door.

Ten slotte geeft de documentatieagent 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 maakt voor serieuze workflows.

Een normale HTTP API-aanroep is vaak te dun voor agentwerk. Agenttaken kunnen onzekerheid, meerdere stappen, tussenresultaten en follow-upvragen omvatten.

Een Taak geeft je een plek om aan te hechten:

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

Dit is nuttig voor:

• onderzoeksworkflows
• codegeneratie
• data-analyse
• compliance-review
• documentproductie
• incidentonderzoek
• meervoudige planingsstappen
• workflows met menselijke goedkeuring

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

Streaming en async werk

A2A ondersteunt het idee dat agentwerk streaming of asynchroom kan zijn.

Streaming is nuttig wanneer de client live updates wilt.

Bijvoorbeeld:

• voortgangsgebeurtenissen
• partiële resultaten
• tussentijdse status
• gegenereerde tekst
• stapupdates

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

Bijvoorbeeld:

• achtergrondonderzoek
• generatie van grote documenten
• multi-agent review
• databewerking
• menselijke goedkeuring
• batchanalyse

In de praktijk moet een robuust A2A-systeem worden ontworpen rond drie modi: direct antwoord voor eenvoudig werk, streaming voor interactief langdurig werk, en async voor duurzame achtergrondwerk die elke enkele verbinding kan overleven.

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-notificaties of server-sent events ondersteunen. Een goede client inspecteert de Agent Card voordat hij een interactiepatroon kiest, waardoor 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 agentsystemen steeds vaker gemengde inputs en outputs verwerken:

• tekst
• afbeeldingen
• audio
• video
• PDF’s
• spreadsheets
• gestructureerde JSON
• logs
• code
• diagrammen

Als elke agentengrens alles omzet naar tekst, kan belangrijke informatie verloren gaan.

Bijvoorbeeld, een visuele troubleshooting-agent zou een afbeelding als afbeelding moeten ontvangen, niet als een zwakke tekstbeschrijving. Een finance-agent zou gestructureerde spreadsheetdata moeten ontvangen, niet een gekopieerd alinea. Een code-reviewagent zou sourcebestanden of diffs moeten ontvangen, niet een vaag samenvatting.

Delen en mediatypes zijn hoe A2A rijkere inhoud behoudt over agentengrenzen 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-agentenketting.

A2A is geen agentframework

A2A vertelt je niet hoe je een agent moet bouwen.

Het definieert niet:

• redeneringsstrategie
• planeringsalgoritme
• geheugensysteem
• vectordatabase
• prompttemplate
• modelleverancier
• toolframework
• orchestratieruntime
• evaluatiemethode

Dat is een feature, geen bug. A2A is een grensprotocol dat verschillende agentimplementaties in staat stelt om te communiceren zonder dat ze dezelfde interne architectuur moeten 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 API’s

A2A vervangt ook niet elke API.

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

Bijvoorbeeld:

• valutaomzetting
• adresvalidatie
• factuuropzochting
• afbeeldingsresizing
• zoekendpoint
• feature flag opzoeking
• 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:

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

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

Waar A2A past in AI-systemarchitectuur

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 --> Onderzoeksagent
  |-- A2A --> Coderingagent
  |-- A2A --> Complianceagent
  |-- A2A --> Documentatieagent

Elke specialistische agent kan intern tools gebruiken:

Onderzoeksagent
  |
  |-- MCP --> websearch
  |-- MCP --> documentopslag
  |-- MCP --> vectordatabase

Dit geeft je aparte lagen:

Gebruikersinterface-laag
Agentcoördinatie-laag
Toolintegratie-laag
Data- en uitvoeringslaag

A2A leeft in de agentcoördinatie-laag, MCP leeft vaak in de toolintegratie-laag, en normale API’s, queues, databases en opslagsystemen leven daar onder — elke laag met zijn eigen abstractie en zijn eigen faalmogelijkheden. Voor een cross-cutting map van hoe LLM-inferentie, geheugen, routing, tooling en observability samenpassen binnen productieassistenten, 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 specialistische agents.

Voorbeeld:

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

Dit patroon is eenvoudig te begrijpen: de orchestrator bezit de algehele workflow, en specialistische agents bezitten domeon-specifiek 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 modelkeuze en orchestratietrade-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-agentenarchitectuur om te gebruiken voordat je complexere topologieën verkent.

Architectuurpatroon: Peer agents

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

Bijvoorbeeld:

Onderzoeksagent --> 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 gedeeld kan worden
• hoe lussen worden voorkomen
• wie het eindoutput bezit
• hoe kosten worden gecontroleerd
• hoe afdracht wordt geaudited

Peer-agentennetwerken 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 graph.

Architectuurpatroon: A2A Gateway

Een meer productie-vriendelijk patroon is een A2A gateway.

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

De gateway kan afhandelen:

• authenticatie
• autorisatie
• routing
• tenantmapping
• logging
• limietregels
• beleidchecks
• protocolversieafhandeling
• observability
• audittrails

Dit is vooral nuttig in enterprise-omgevingen, waar de gateway het controleplan wordt voor agentcommunicatie — het afdwingen van beleid op één plaats in plaats van het opnieuw implementeren over elke agent heen. 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-to-agent communicatie kan gevoelige context over grenzen verplaatsen. Het kan ook werk afdragen aan systemen die hun eigen tools en rechten kunnen hebben.

De kernbeveiligingsvragen zijn:

• Welke agents mogen deze agent ontdekken?
• Welke agents mogen hem taken sturen?
• Welke authenticatie is vereist?
• Welke rechten zijn aan de aanroeper gehecht?
• Kan één agent gebruikersautoriteit afdragen aan een andere?
• Welke data kan in berichten worden opgenomen?
• Welke artefacten kunnen worden teruggegeven?
• Hoe wordt de taak geaudited?
• Kan de ontvangende agent tools of andere agents aanroepen?
• Hoe worden secrets beschermd?

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

Beveiliging mag niet worden toegevoegd nadat het agentennetwerk is gebouwd; het moet het netwerk vanaf het begin vormgeven, omdat het achteraf toevoegen van auth- en permissiegrenzen over een live agententopologie aanzienlijk moeilijker is dan ze vanaf het begin in te ontwerpen.

Observability-overwegingen

A2A-systemen hebben sterke observability nodig.

Wanneer een taak agentengrenzen overschrijdt, wordt debugging aanzienlijk moeilijker omdat geen enkel systeem het volledige beeld houdt. Je moet weten:

• welke agent de taak heeft gemaakt
• welke agent hem heeft geaccepteerd
• welke berichten zijn uitgewisseld
• welke stateveranderingen 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 ketting.

Bijvoorbeeld:

gebruikersverzoek
  -> primaire assistent taak
  -> onderzoeksagent taak
  -> documentzoekt tool call
  -> samenvattingsartefact
  -> eindantwoord

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

Veelgemaakte fouten

Fout 1: Elke tool noemen een agent

Niet elke tool is een agent.

Een rekenmachine is een tool. Een bestandlezer is een tool. Een databasequeryendpoint 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 om werk intelligent te routeren. Een goede card moet zeggen wat de agent daadwerkelijk doet, wat hij accepteert, wat hij teruggeeft, en welke beperkingen van toepassing zijn.

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 een rapportartefact terug.

Als de output JSON is, geef gestructureerde data terug.

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

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

Fout 5: Geen permissiemodel

Agentennetwerken zonder permissiegrenzen zijn riskant.

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

Wanneer moet je A2A gebruiken?

Gebruik A2A wanneer je echte agentengrenzen hebt.

Goede redenen zijn:

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

Zwakke 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 toolintegratieprobleem 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, debuggingoppervlak en beveiligingsvereisten — zijn reëel.

Een minimale mentale model

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

Agent Card: wat de agent kan.
Bericht: wat agents elkaar zeggen.
Deel (Part): getypeerde inhoud 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 voornamelijk over het betrouwbaar, observeerbaar en veilig genoeg maken van die vijf concepten om ze te gebruiken in echte productiesystemen.

Eindgedachten

A2A is niet zomaar nog 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-agentsystemen blijven met goede tooltoegang waar MCP en normale API’s volledig voldoende zijn.

Maar zodra agents afzonderlijk gdeployde peers worden, heb je sterkere grenzen nodig: discovery, taakeigendom, berichten die meer dragen dan tekst, artefacten als eerste-klasse outputs, en beveiliging, state en observability die agentengrenzen overschrijden. Dat is de ruimte die A2A probeert te bezetten, en het is een echt ander probleem dan het tool-integratieprobleem dat MCP oplost.

Voor een praktische kijk op waar A2A in 2026 daadwerkelijk productie-tractie heeft — inclusief adoptietiers, beveiligingszorgpunten, het enterprise-geval 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 duidelijke architectuur — de AI Systems cluster behandelt self-hosted assistenten, 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 meer zomaar een tool — 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 Discovery: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming en Async-operaties: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A en MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/