A2A vs MCP: Twee complementaire protocollen voor het opkomende agent eco-systeem

De toenemende adoptie van AI-agenten — autonome of semi-autonome software-entiteiten die redeneren en acties uitvoeren namens gebruikers — leidt tot een nieuwe laag in applicatiearchitectuur.

Begin 2025 ontstonden er twee aparte protocollen om dit aan te pakken — A2A (Agent-to-Agent) en MCP (Model Context Protocol). Een eenvoudige manier om hun rollen te begrijpen is:

A2A: Hoe communiceren agenten met elkaar

MCP: Hoe communiceren agenten met tools of een externe context

referentie: https://google.github.io/A2A/#/topics/a2a_and_mcp

Ze pakken de kernuitdaging aan van het bouwen van systemen met meerdere agenten, meerdere LLM's, en meerdere bronnen van context — die allemaal moeten samenwerken.

Een manier om het te kaderen is: “MCP biedt verticale integratie (applicatie-naar-model), terwijl A2A horizontale integratie biedt (agent-naar-agent)

Of je nu een ontwikkelaar bent of niet, iedereen die AI-producten of agentische systemen bouwt, moet de fundamentele architectuur begrijpen — omdat het bepaalt hoe we producten ontwerpen, gebruikersinteracties, ecosystemen, en langetermijngroei.

Dit artikel introduceert beide protocollen op een eenvoudige, gemakkelijk te begrijpen manier en belicht belangrijke leerpunten voor ontwikkelaars en AI-productbouwers.

Wat is A2A (Agent-naar-Agent)?#

A2A (Agent-naar-Agent) is een open protocol ontwikkeld door Google en meer dan 50 industriële partners. Het doel is om interoperabiliteit tussen agenten mogelijk te maken — ongeacht wie ze bouwde, waar ze gehost worden, of welk framework ze gebruiken.

A2A-protocolmechanisme#

A2A gebruikt JSON-RPC 2.0 over HTTP(S) als communicatiemechanisme, met ondersteuning voor Server-Sent Events (SSE) om updates te streamen.

A2A-communicatiemodellen#

A2A definieert een gestructureerd model voor hoe twee agenten met elkaar omgaan. Één agent neemt de rol van “client” agent aan, die een verzoek of taak initieert, en een andere fungeert als de “remote” agent, die het verzoek ontvangt en probeert het uit te voeren. De clientagent kan eerst capaciteiten ontdekken om te bepalen welke agent het meest geschikt is voor een bepaalde taak.

Hier komt de vraag op hoe agenten elkaar ontdekken. Elke agent kan een Agent Card publiceren (een JSON-metadata document, vaak gehost op een standaard URL zoals /.well-known/agent.json) die zijn mogelijkheden, vaardigheden, API-eindpunten en auth-vereisten beschrijft.

Door een Agent Card te lezen, kan een clientagent een geschikte partneragent identificeren voor de beoogde taak — in wezen een directory van wat die agent weet of kan doen. Zodra een doelagent is gekozen, formuleert de clientagent een Taak object om te verzenden.

referentie: https://google.github.io/A2A/#/

Taakbeheer#

Alle interactie in A2A is gericht op het uitvoeren van taken. Een taak is een gestructureerd object (gedefinieerd door het schema van het protocol) dat details van het verzoek omvat en de status bijhoudt.

In A2A speelt elke agent een van de twee rollen:

• Clientagent: initieert een taak
• Remote agent: ontvangt en verwerkt de taak

Taken kunnen elke vorm van werk omvatten: een rapport genereren, gegevens ophalen, een workflow initiëren. Resultaten worden geretourneerd als artefacten, en agenten kunnen gestructureerde berichten sturen tijdens de uitvoering om samen te werken of te verduidelijken.

Samenwerking en inhoudsonderhandeling#

A2A ondersteunt meer dan eenvoudige taakverzoeken — agenten kunnen rijke, meerledige berichten uitwisselen die tekst, JSON, afbeeldingen, video of interactieve inhoud bevatten. Dit maakt formaatonderhandeling mogelijk op basis van wat elke agent kan verwerken of weergeven.

Bijvoorbeeld, een externe agent kan een diagram terugsturen als ruwe gegevens of als afbeelding, of verzoeken om een interactieve formulier te openen. Dit ontwerp ondersteunt flexibele, modaliteitsagnostische communicatie, zonder dat agenten interne tools of geheugen hoeven te delen.

Praktijkvoorbeeld#

Hier is een praktijkvoorbeeld van hoe A2A kan worden gebruikt in een bedrijfsomgevingsscenario:

Een nieuwe medewerker wordt aangenomen bij een groot bedrijf. Meerdere systemen en afdelingen zijn betrokken bij het onboarden:

• HR moet een record maken en een welkomstmail versturen
• IT moet een laptop en bedrijfsaccounts voorzien
• Faciliteiten moeten een bureau en toegangspas voorbereiden

Traditioneel worden deze stappen handmatig afgehandeld of door strakke integraties tussen interne systemen.

In plaats van aangepaste API’s tussen elk systeem, stelt elke afdeling zijn eigen agent bloot met behulp van het A2A-protocol:

Een multi-agent systeem — laten we het OnboardingPro noemen (bijv. onboarding-agent.company.com) — coördineert de gehele onboarding workflow.

1. Ontdekking: Het leest de /.well-known/agent.json van elke agent om de mogelijkheden en auth te begrijpen.
2. Taakdelegatie:
   • Stuurt een createEmployee taak naar de HR-agent.
   • Stuurt setupEmailAccount en orderHardware taken naar de IT-agent.
   • Stuurt assignDesk en generateBadge naar de Faciliteitenagent.
3. Streamen van updates: Agenten streamen voortgang terug via Server-Sent Events (bijv. “laptop verzonden”, “bureau toegewezen”).
4. Artefactverzameling: De uiteindelijke resultaten (bijv. PDF-badge, bevestigings-emails, accountgegevens) worden teruggestuurd als A2A-artefacten.
5. Voltooiing: De OnboardingPro brengt de personeelsmanager op de hoogte wanneer de onboarding is voltooid.

Wat is MCP (Model Context Protocol)?#

MCP (Model Context Protocol), ontwikkeld door Anthropic, richt zich op een ander probleem: hoe externe applicaties gestructureerde context en tools kunnen bieden aan een taalmodel-gebaseerde agent tijdens runtime.

In plaats van inter-agent communicatie mogelijk te maken, richt MCP zich op het contextvenster — het werkgeheugen van een LLM. Het doel is om:

• Dynamisch relevante tools, documenten, API-functies of gebruikersstatus in een model's inferentiesessie te injecteren
• Modellen de mogelijkheid te geven functies aan te roepen of documenten op te halen zonder de prompt of logica te hardcoderen

MCP-sleutelarchitectuur#

Om MCP te begrijpen, moet je eerst begrijpen hoe de algemene architectuur werkt — hoe alle onderdelen samenwerken.

MCP-host: “De AI waarmee je praat”#

Denk aan de MCP-host als de AI-app zelf — zoals Claude Desktop of jouw codeerassistent.

Het is de interface die je gebruikt — de plek waar je typt of spreekt.

Het wil tools en gegevens binnenhalen die het model helpen om betere antwoorden te geven.

MCP-client: “De connector”#

De MCP-client is het softwarestuk dat jouw AI-host (zoals Claude) verbindt met de buitenwereld. Het is als een schakelbord — het beheert veilige, één-op-één verbindingen met verschillende MCP-servers. Wanneer de AI toegang tot iets wil, gaat het via de client.

Het is handig om te denken aan tools als ChatGPT, Claude chat, of Cursor IDE als MCP-hosts — zij bieden de interface waarmee je communiceert. Achter de schermen gebruiken ze een MCP-client om verbinding te maken met verschillende tools en gegevensbronnen via MCP-servers.

referentie: https://modelcontextprotocol.io/introduction

MCP-server: “De toolaanbieder”#

Een MCP-server is een klein, gericht programma dat één specifieke tool of capaciteit blootstelt — zoals:

• Bestanden op je computer doorzoeken
• Gegevens opzoeken in een lokale database
• Een externe API aanroepen (zoals weer, financiën, kalender)

Elke server volgt het MCP-protocol, zodat AI kan begrijpen wat het kan doen en hoe het moet worden aangeroepen.

Lokale gegevensbronnen: “Jouw eigen bestanden & diensten”#

Sommige MCP-servers verbinden met dingen op je eigen machine — zoals:

• Documenten en mappen
• Codeprojecten
• Databases of lokale apps

Dit maakt het mogelijk dat AI dingen kan zoeken, ophalen of berekenen zonder jouw gegevens naar de cloud te uploaden.

Afstandsbedieningen: “API's & Online tools”#

Andere MCP-servers zijn verbonden met het internet — zij communiceren met:

• API's (bijv. Stripe, Notion, GitHub)
• SaaS-tools
• Bedrijfsdatabases in de cloud

Zodat de AI bijvoorbeeld kan zeggen: “Roep de GitHub-server aan en haal de lijst met openstaande PR’s op.”

MCP ondersteunt nu verbinding met externe MCP-servers. Dit betekent dat een MCP client krachtigere mogelijkheden kan verkrijgen. In theorie,

Met de juiste set MCP-servers kunnen gebruikers elke MCP-client omvormen tot een “alles-in-één-app.

referentie: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Alles samenbrengen#

Laten we nu een diagram gebruiken om te zien hoe alles samenwerkt.

1. Je vraagt de AI om iets complex
2. De AI (de host) vraagt de client om hulp
3. De client roept de juiste MCP-server aan — misschien een die bestanden controleert of een API-aanroept
4. De server stuurt gegevens terug of voert een functie uit
5. Het resultaat stroomt terug naar het model om te helpen de taak te voltooien

A2A vs MCP — Vergelijking#

Hoe ze samenwerken#

In plaats van alternatieven te zijn, zijn A2A en MCP complementair. In veel systemen zullen beide samen worden gebruikt.

Voorbeeldworkflow#

1. Een gebruiker dient een complex verzoek in een bedrijfsagentinterface in.
2. De orkestrerende agent gebruikt A2A om subtaken te delegeren aan gespecialiseerde agenten (bijv. analytics, HR, financiën).
3. Eén van die agenten gebruikt MCP intern om een zoekfunctie aan te roepen, een document op te halen, of iets te berekenen met een model.
4. Het resultaat wordt als een artefact via A2A geretourneerd, waardoor end-to-end agent samenwerking mogelijk wordt met modulaire toegang tot tools.

Deze architectuur scheidt inter-agent communicatie (A2A) van intra-agent capaciteit oproep (MCP) — wat het systeem gemakkelijker samenstelbaar, schaalbaar en beveiligbaar maakt.

Conclusie#

A2A gaat over agenten die met andere agenten praten over een netwerk — veilig, asynchroon, en taakgecentreerd.

MCP gaat over het injecteren van gestructureerde capaciteiten in een modelsessie, waardoor LLM's over tool en gegevens redeneerbaar worden binnen context.

Samen gebruikt, ondersteunen ze composeerbare, multi-agent systemen die zowel uitbreidbaar als interoperabel zijn.

Hoe de MCP + A2A basisinfrastructuur de toekomst van agent product marktplaatsen kan vormgeven#

Ten slotte wil ik ingaan op hoe deze kerngedachte basis de toekomst van de AI-marktplaats kan vormgeven — en wat het betekent voor mensen die AI-producten bouwen.

De verandering van interactie tussen mens en computer#

Een duidelijk voorbeeld van deze verschuiving is te zien in ontwikkelaars- en serviceworkflows. Met MCP-servers die nu in IDE's en codeeragenten zijn geïntegreerd, verandert de manier waarop ontwikkelaars met tools omgaan fundamenteel.

Voorheen werd een typische workflow uitgevoerd door naar de juiste service te zoeken, hosting op te zetten, documentatie te lezen, API's handmatig te integreren, code te schrijven in de IDE, en functies te configureren via een low-code dashboard. Het was een gefragmenteerde ervaring, die context switching en technische overhead in elke stap vereist.

Nu kan met MCP-verbonden codeeragenten veel van die complexiteit worden geabstraheerd. Ontwikkelaars kunnen tools op een natuurlijkere manier ontdekken en gebruiken via gespreksprompts. API-integratie wordt onderdeel van de coderingsstroom zelf — vaak zonder dat een aparte UI of handmatige setup nodig is. (Denk maar eens aan hoe complex AWS of Microsoft’s dashboards kunnen zijn). De interactie wordt soepeler — meer gericht op het sturen van gedrag dan op het samenstellen van functies.

In dit model verschuift gebruikers- of ontwikkelaarsinteractie van het configureren van functies naar het orkestreren van gedrag. Dit verandert ook de rol van productontwerp.

In plaats van UI's te gebruiken om technische uitdagingen te “overbruggen” (bv. “dit is te moeilijk om te coderen, laten we een configpaneel maken”), moeten we nu:

• Denken aan de end-to-end ervaring
• Ontwerpen hoe en wanneer AI + gebruikersinteracties elkaar zouden moeten ontmoeten
• Laat de AI de logica afhandelen, en leid gebruikers door intentie en stroom

De uitdaging wordt beslissen wanneer en hoe AI en gebruikersinvoer samenkomen, laat de AI de logica afhandelen, en leid gebruikers door intentie en stroom en hoe de juiste interacties op het juiste moment in te voegen.

Ik gebruikte een ontwikkelaarsdienst en API-product als voorbeeld om te laten zien hoe gebruikersinteractie zou kunnen veranderen — maar hetzelfde geldt voor zakelijke software. Al lange tijd zijn bedrijfstools complex en moeilijk te gebruiken. Natuurlijke taalinteractie heeft de potentie om veel van die workflows te vereenvoudigen.

Agentische productparadigma’s en hun impact op SaaS#

We beginnen een groeiend aantal MCP-servers te zien verschijnen. Stel je voor dat Airbnb een boekings-MCP-server aanbiedt, of Google Maps een kaart-MCP-server blootstelt. Een agent (als een MCP client) zou met veel van deze servers tegelijkertijd kunnen verbinden — waardoor workflows die vroeger aangepaste integraties of strak gebonden apps vereisten, ontgrendeld worden.

Vergeleken met het SaaS-tijdperk, waar integraties vaak handmatig en rigide waren, maakt dit model autonomere workflows en vloeibare verbindingen tussen diensten mogelijk. Hier zijn twee voorbeelden:

1. Ontwerp op basis van documenten

   Je schrijft een PRD in Notion. Een Figma-agent leest het document en creëert automatisch een wireframe dat de kernconcepten weergeeft — geen handmatige overdracht nodig.

2. Concurrentieonderzoek, van begin tot eind

   Je vraagt om een concurrentieanalyse. Een groep agenten doorzoekt het web, meldt zich aan voor relevante diensten namens jou (met veilige auth), verzamelt de resultaten, en levert de artefacten terug — al georganiseerd in je Notion-ruimte.

Uitdagingen met authenticatie- en autorisatiegrenzen#

Met de opkomst van agent naar agent-verbindingen, MCP-client naar MCP-server verbindingen, zijn er veel onderliggende behoeften aan authenticatie en autorisatie omdat agenten namens mensen en gebruikers zullen handelen en referenties moeten worden beveiligd gedurende deze reis.

Tot nu toe zijn er verschillende scenario's specifiek voor de opkomst van agent naar agent en MCP.

1. Agent vs SaaS & WebsiteApp
2. MCP-client (Agent) vs MCP-server
3. Gebruiker vs Agent
4. Agent vs Agent

Een andere interessante use case is multi-identiteitsfederatie waarbij Google vermeldde:

Bijvoorbeeld, Gebruiker U werkt met Agent A die een A-systeemidentifier vereist. Als Agent A vervolgens afhankelijk is van Tool B of Agent B die een B-systeemidentifier vereist, moet de gebruiker mogelijk identiteiten voor zowel A-systeem als B-systeem in één enkel verzoek verstrekken. (Veronderstel dat A-systeem een ondernemings-LDAP-identiteit is en B-systeem een SaaS-provideridentiteit).

Logto is een OIDC en OAuth provider, goed geschikt voor de toekomst van AI-integraties.

Met zijn flexibele infrastructuur breiden we actief zijn mogelijkheden uit en hebben we een reeks tutorials gepubliceerd om ontwikkelaars snel op weg te helpen.

Vragen?

Neem contact met ons op — of duik in en ontdek wat je vandaag de dag met Logto kunt bouwen.