Agentinteroperabiliteit: A2A naast MCP
Waarom dit ertoe doet
Section titled “Waarom dit ertoe doet”Lokaal toolgebruik en samenwerking tussen remote agents zijn verschillende grenzen. Behandel een remote agent als een externe dienst met gedeclareerde capaciteiten, een eigen identiteit en bevoegdheid, expliciete taakstatus en een observeerbaar contract—niet als een functieaanroep die toevallig tekst teruggeeft.
A2A modelleert de interactie rond vier kernobjecten:
- Agent Card: een machineleesbare beschrijving van identiteit, endpoint, skills, ondersteunde interfaces en authenticatievereisten van de remote agent. Zo kan capability discovery vóór delegatie plaatsvinden.
- Task: de stateful eenheid van werk met lifecycle, identifier en optionele context. Een handoff krijgt zo een duurzame plek voor status, annulering en herstel.
- Message: een communicatieronde om een task te starten, verduidelijking te vragen of verdere input te geven. Het is niet de betrouwbare container voor taakuitvoer.
- Artifact: een taakresultaat, zoals tekst, gestructureerde data of een bestand, opgebouwd uit getypeerde onderdelen. Artifacts horen in het omliggende systeem provenance- en validatiemetadata te krijgen.
MCP en A2A samen
Section titled “MCP en A2A samen”Een orchestrerende agent kan MCP gebruiken om lokale context te lezen of een gecontroleerde tool aan te roepen, en daarna A2A gebruiken om werk aan een specialist te delegeren. De specialist kan intern zijn eigen MCP-servers gebruiken. De grens moet duidelijk maken welke agent verantwoordelijk is voor elke actie, welke principal die autoriseerde, welke tools beschikbaar waren en welke artifacts terugkwamen.
Voor end-to-end tracing geef je trace- en spancontext door via de A2A-request, task-updates, MCP-aanroepen en artifact-overdracht. Leg de versie van de Agent Card, task- en context-ID’s, message-ID’s, skill, bevoegdheid, beleidsbesluiten, retries, latentie, statusovergangen en artifact-hashes vast. Redigeer secrets en gevoelige payloads, maar bewaar genoeg gestructureerd bewijs om te reconstrueren wie wat vroeg, waar het draaide en waarom het resultaat is geaccepteerd.
Streaming en push-notificaties zijn nuttig voor langlopende of eventgedreven workflows, maar voegen bezorgings- en beveiligingsrisico’s toe. Authenticeer webhook-requests, valideer de verwachte task-ID en bron, maak notification handling idempotent, bescherm tegen replay en SSRF en herstel gemiste events door taskstatus opnieuw te lezen. Verwar een live stream niet met duurzame bezorging.