Nederlands

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

Dit artikel introduceert A2A en MCP — twee opkomende protocollen die de toekomst van AI-agent systemen vormgeven. Het legt uit hoe ze werken, hoe ze verschillen, en waarom het belangrijk is om deze architectuur te begrijpen voor ontwikkelaars, ontwerpers en AI-productbouwers.

Guamian

Product & Design

4/11/2025

Stop met weken verspillen aan gebruikersauthenticatie

Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.

Aan de slag

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:

Agent	Verantwoordelijkheid
hr-agent.company.com	Maak medewerkerrecord, verstuur documenten
it-agent.company.com	Maak e-mailaccount, bestel laptop
facilities-agent.company.com	Ken bureau toe, print toegangspas

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

Ontdekking: Het leest de /.well-known/agent.json van elke agent om de mogelijkheden en auth te begrijpen.
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.
Streamen van updates: Agenten streamen voortgang terug via Server-Sent Events (bijv. “laptop verzonden”, “bureau toegewezen”).
Artefactverzameling: De uiteindelijke resultaten (bijv. PDF-badge, bevestigings-emails, accountgegevens) worden teruggestuurd als A2A-artefacten.
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.

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

A2A vs MCP — Vergelijking

Categorie	A2A (Agent-naar-agent)	MCP (Model Context Protocol)
Primair doel	Inter-agent taakuitwisseling mogelijk maken	LLM's toegang geven tot externe tools of context
Ontworpen voor	Communicatie tussen autonome agenten	Het verbeteren van capaciteiten van een enkele agent tijdens inferentie
Focus	Multi-agent workflows, coördinatie, delegatie	Dynamisch gebruik van tools, contextverrijking
Uitvoeringsmodel	Agenten sturen/ontvangen taken en artefacten	LLM selecteert en voert tools inline uit tijdens het redeneren
Beveiliging	OAuth 2.0, API-sleutels, declaratieve reikwijdtes	Behandeld op de applicatie-integratielaag
Ontwikkelaarsrol	Bouw agenten die taken en artefacten via eindpunten blootstellen	Definieer gestructureerde tools en context die het model kan gebruiken
Ecosysteempartners	Google, Salesforce, SAP, LangChain, etc.	Anthropic, met opkomende adoptie in tool-gebaseerde LLM-UI's

Hoe ze samenwerken

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

Voorbeeldworkflow

Een gebruiker dient een complex verzoek in een bedrijfsagentinterface in.
De orkestrerende agent gebruikt A2A om subtaken te delegeren aan gespecialiseerde agenten (bijv. analytics, HR, financiën).
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.
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:

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.
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.

Agent vs SaaS & WebsiteApp
MCP-client (Agent) vs MCP-server
Gebruiker vs Agent
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.

Probeer Logto Cloud gratis

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

A2A-protocolmechanisme#

A2A-communicatiemodellen#

Taakbeheer#

Samenwerking en inhoudsonderhandeling#

Praktijkvoorbeeld#

Wat is MCP (Model Context Protocol)?#

MCP-sleutelarchitectuur#

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

MCP-client: “De connector”#

MCP-server: “De toolaanbieder”#

Lokale gegevensbronnen: “Jouw eigen bestanden & diensten”#

Afstandsbedieningen: “API's & Online tools”#

Alles samenbrengen#

A2A vs MCP — Vergelijking#

Hoe ze samenwerken#

Voorbeeldworkflow#

Conclusie#

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

De verandering van interactie tussen mens en computer#

Agentische productparadigma’s en hun impact op SaaS#

Uitdagingen met authenticatie- en autorisatiegrenzen#