A2A vs. MCP: hebben AI-agents echt beide protocollen nodig?

De architectuur van AI-agents begint zich op te splitsen in twee lagen.

De ene laag gaat over het geven van toegang tot tools, data, API’s, bestanden, databases, zoeksystemen, agenda’s, ticketingsystemen en andere externe mogelijkheden aan een AI-assistent — en daar past MCP in.

De andere laag gaat over het laten ontdekken, communiceren, delegeren en samenwerken van één AI-agent met een ander AI-agent, mogelijk gebouwd door een ander team, framework, leverancier of organisatie — en daar past A2A in.

Het vervelende is dat beide protocollen vaak worden besproken alsof ze hetzelfde probleem oplossen, maar dat is niet zo. Er is overlap aan de randen, en die overlap is waar het meeste verwarring vandaan komt. Maar het mentale model is simpel:

MCP is voornamelijk agent-naar-tool en A2A is voornamelijk agent-naar-agent.

Dat betekent niet dat elk AI-systeem beide nodig heeft. Veel kleine agent-projecten zouden waarschijnlijk moeten beginnen met MCP en A2A negeren totdat ze een echte multi-agent grens hebben. Maar als je grotere agent-systemen bouwt, vooral systemen met apart ingedeelde agents, specialistische agents, leveranciersagents of langlopende gedelegeerde taken, begint A2A zinvol te worden.

Dit artikel legt het verschil, de overlap, de architecturale afwegingen uit, en wanneer je eigenlijk beide nodig hebt.

Wat is MCP?

MCP staat voor Model Context Protocol.

Het is een open protocol voor het verbinden van AI-applicaties en agents met externe tools, bronnen en prompts. In praktische termen stelt MCP een AI-host zoals een desktop-assistent, IDE, codeeragent of chatapplicatie in staat verbinding te maken met één of meer MCP-servers.

Een MCP-server kan mogelijkheden blootleggen zoals:

• Tools: aanroepbare functies die het model kan gebruiken
• Bronnen: leesbare context zoals bestanden, API-data, documenten of databasegegevens
• Prompts: herbruikbare prompt-sjablonen of workflows

De officiële MCP-architectuur is gebaseerd op een host-, client- en servermodel.

De MCP-host is de applicatie waarmee de gebruiker interactie heeft. De MCP-client is het protocolcomponent dat een verbinding onderhoudt met een specifieke MCP-server. De MCP-server stelt mogelijkheden beschikbaar voor de client.

Bijvoorbeeld, een codeerassistent zou kunnen verbinden met:

• Een bestandssysteem MCP-server
• Een GitHub MCP-server
• Een database MCP-server
• Een Sentry MCP-server
• Een Slack MCP-server

Vanuit het perspectief van de gebruiker wordt de assistent nuttiger. Vanuit het perspectief van de systeemarchitectuur heeft de assistent gecontroleerde toegang verkregen tot externe context en acties.

Dat is de belangrijkste waarde van MCP: het standardiseert hoe een AI-applicatie toegang krijgt tot tools en context.

MCP is het beste te begrijpen als tool-integratie

MCP gaat niet alleen over tools, maar tools zijn de makkelijkste manier om het te begrijpen.

Zonder MCP heeft elke AI-applicatie aangepaste integratiecode nodig voor elk extern systeem. Het ene agent-framework heeft zijn eigen plugin-formaat. Een ander heeft zijn eigen toolschema. Een ander heeft een ander API-wrapperpatroon. Elke integratie wordt telkens opnieuw opgebouwd.

MCP probeert dat verspilling te verminderen.

Als een tool-leverancier een MCP-server blootlegt, kunnen veel MCP-compatibele clients deze gebruiken. Als een ontwikkelaar een MCP-server bouwt voor een intern systeem, kunnen meerdere AI-applicaties ermee verbinden. Praktische implementatiegidsen voor MCP-servers in Go en MCP-servers in Python tonen hoe eenvoudig de integratielaag kan zijn zodra het protocol het zware werk doet.

Daarom is MCP zo snel belangrijk geworden. Het lost een saaie maar pijnlijke integratieprobleem op.

En saaie integratieproblemen zijn meestal waar duurzame standaarden vandaan komen — die overleven juist omdat ze repetitief werk verminderen dat iedereen toch moet doen.

Wat is A2A?

A2A staat voor Agent2Agent Protocol.

Het is een open standaard voor communicatie en interoperabiliteit tussen onafhankelijke AI-agentsystemen. Voor een diepere blik op de individuele bouwstenen — Agent Cards, taaklevenscyclus, berichten, onderdelen en artefacten — behandelt Wat is het A2A-protocol? Agent Cards en taken uitgelegd elk concept in volledige detail. De officiële A2A-specificatie beschrijft het protocol als een manier voor agents die zijn gebouwd met verschillende frameworks, talen of leveranciers om te communiceren via een gemeenschappelijk interactiemodel.

De sleutelzin is onafhankelijke agentsystemen.

A2A gaat niet primair over het geven van toegang aan één assistent tot een rekenmachine, database of bestandssysteem. Het gaat over één agent die communiceert met een andere agent die zijn eigen mogelijkheden, staat, beleid, taakmodel en mogelijk zijn eigen tools achter de schermen heeft.

Een A2A-agent kan adverteren wat het kan doen via een Agent Card. Een andere agent of client kan die mogelijkheid ontdekken, een taak verzenden, berichten uitwisselen, artefacten ontvangen en de taaklevenscyclus volgen.

A2A introduceert concepten zoals:

• Agent Cards
• Agents en clients
• Taken
• Berichten
• Onderdelen
• Artefacten
• Taakstatussen
• Streaming en asynchron werk

Samen maken deze concepten dat A2A meer voelt als een agent-samenwerkingsprotocol dan als een eenvoudig tool-aanroepprotocol — het is ontworpen rond het idee dat agents identiteit, staat en voortdurende relaties met andere agents hebben.

A2A is het beste te begrijpen als agent-samenwerking

Stel je voor dat een gebruiker een enterprise-assistent vraagt:

“Stel een marktintroductiebrief voor Japan samen, inclusief juridische overwegingen, prijsrisico’s en een lanceerprojectplan.”

Een eenvoudige assistent zou alles zelf kunnen proberen te doen. Maar een groter agentsysteem zou stukjes van het werk kunnen delegeren:

• Een onderzoeksagent verzamelt marktgegevens
• Een juridische agent controleert regelgevende overwegingen
• Een financiële agent schat prijsrisico’s
• Een projectplanning-agent produceert een leveringsplan
• Een schrijvende agent assembleert de definitieve brief

Als die agents allemaal interne functies zijn binnen één codebase, heb je A2A misschien niet nodig. Je kunt gewoon functies of services direct aanroepen.

Maar als die agents onafhankelijke systemen zijn, mogelijk eigendom van verschillende teams of leveranciers, dan wordt een standaard agent-naar-agent-protocol nuttig.

Dat is het A2A-gebruikscase.

A2A vs MCP: Het simpele verschil

De simpelste vergelijking is deze:

Die tabel is niet perfect, maar hij is nuttig voor het bouwen van een initieel mentaal model. Kortom, MCP beantwoordt de vraag “Hoe krijgt deze AI-applicatie toegang tot externe mogelijkheden?” terwijl A2A beantwoordt “Hoe werkt deze agent samen met een andere agent?”

Het onderscheid is belangrijk omdat tool-integratie en agent-samenwerking verschillende faalmodi hebben. Een slechte tool-aanroep kan de verkeerde data teruggeven of het verkeerde bestand wijzigen, maar een slechte agent-delegatie kan een onduidelijke keten van verantwoordelijkheid creëren, gevoelige context lekken, in een lus tussen agents komen, werk dupliceren of een artefact produceren dat niemand kan controleren. A2A zit een niveau hoger in de architectuur, en zijn faalmodi hebben overeenkomstig hogere gevolgen.

Waarom ontwikkelaars A2A en MCP verwarren

De verwarring is begrijpelijk.

Veel MCP-servers zijn niet slechts domme tools. Sommige MCP-servers kunnen meervoudig werk uitvoeren. Sommige leggen hoogwaardige mogelijkheden bloot die er agent-achtig uitzien. Een MCP-server zou een planningsservice, een retrieval-systeem of zelfs een ander LLM-aangedreven workflow kunnen omvatten.

Op dat punt wordt de lijn vaag.

Als een MCP-tool genaamd onderzoek_onderwerp een complexe onderzoeksworkflow uitvoert, is het dan een tool of een agent?

Het eerlijke antwoord is: architectuurlijk hangt het er van af.

Als de host het behandelt als een aanroepbare capaciteit met een toolschema, fungeert het als een tool.

Als het zijn eigen identiteit, mogelijkheden, taaklevenscyclus, berichten, artefacten en delegatiegedrag heeft, begint het er uit te zien als een agent.

Daarom is “A2A vs MCP” het verkeerde kader wanneer het een religieus debat wordt. Het betere kader is:

• Is deze externe capaciteit het beste te modelleren als een tool?
• Of is het het beste te modelleren als een onafhankelijke agent?

Die beslissing moet de protocolkeuze sturen.

Het geval voor alleen MCP

De meeste AI-projecten zouden alleen met MCP moeten beginnen — dat is een iets menige positie, maar een praktische.

Als je een codeerassistent, interne chatbot, lokale AI-workflow, persoonlijke automatiseringsagent of eenvoudige enterprise-assistent bouwt, is het eerste probleem meestal niet agent-naar-agent-samenwerking. Het eerste probleem is tool-toegang.

Je hebt nodig dat de assistent bestanden leest, databases queryt, documenten zoekt, API’s aanroept, tickets opent, logs samenvat, metrics inspecteert of records bijwerkt.

MCP past daar heel goed bij.

Gebruik alleen MCP wanneer:

• Jouw agent voornamelijk toegang nodig heeft tot tools en data
• Je de host-applicatie controleert
• Je de meeste integraties controleert
• De externe systemen niet echt autonome agents zijn
• De workflow voornamelijk synchron is of kortlopend
• Een normale tool-aanroep voldoende is
• Je geen agent-ontdekking nodig hebt
• Je geen cross-agent taakstaat nodig hebt
• Je geen artefacten van onafhankelijke agents nodig hebt

Voor veel systemen is MCP plus goede applicatiearchitectuur voldoende. Veel teams zullen A2A over-engineeren in systemen die echt slechts tool-gebruikende assistants zijn, en dat is geen protocolprobleem — het is een architectuurdisciplineprobleem dat geen protocol voor je kan oplossen.

Het geval voor alleen A2A

Alleen-A2A-systemen zijn minder gebruikelijk, maar ze kunnen bestaan.

Je zou A2A kunnen gebruiken zonder MCP wanneer het systeem voornamelijk gaat over communicatie tussen agents, en elke agent al zijn eigen tools intern beheert.

Bijvoorbeeld:

• Een marktplein van specialistische agents
• Een leveranciers-naar-leverancier agent-integratie
• Een cross-organisatie workflow
• Een multi-agentsysteem waarbij elke agent zijn eigen private toolchain heeft
• Een delegatienetwerk waarbij clients niet bekend hoeven te zijn met interne tooldetails

In dit model is A2A de publieke grens tussen onafhankelijk beheerde agents. Agent A hoeft niet te weten of Agent B PostgreSQL, Elasticsearch, MCP, LangChain, aangepaste API’s of shellscripts gebruikt achter de schermen. Agent A hoeft alleen te weten wat Agent B kan doen, hoe het een taak te verzenden, en hoe resultaten te ontvangen.

Dat is een schone abstractie.

Gebruik alleen A2A wanneer:

• Je agents blootlegt als onafhankelijke services
• De aanroeper niet bekend hoeft te zijn met de interne tools van de agent
• Agent-mogelijkheidsontdekking belangrijk is
• Delegatie belangrijker is dan directe tool-toegang
• Taken langlopend kunnen zijn
• Resultaten artefacten kunnen bevatten
• Agents kunnen zijn gebouwd door verschillende leveranciers of teams

A2A is het sterkst op systeemgrenzen, waar onafhankelijk eigendom agents taken en artefacten moeten uitwisselen zonder hun interne toolchains bloot te leggen. Het is geen protocol dat je in elke laag van elke agent-runtime hoeft te draaien.

Het geval voor het gebruik van zowel A2A als MCP

De meest interessante architectuur is niet A2A vs MCP. Het is A2A plus MCP.

In dit patroon stelt een agent een A2A-interface beschikbaar voor andere agents, maar gebruikt intern MCP om toegang te krijgen tot tools.

Dat geeft je twee schone lagen:

• A2A buiten: hoe agents met elkaar communiceren
• MCP binnen: hoe elke agent toegang krijgt tot tools, data en services

Dit is waarschijnlijk het meest duurzame mentale model.

Een klantenservice-agent zou een A2A-interface kunnen blootleggen. Andere agents kunnen support-gerelateerde taken daaraan delegeren. Intern gebruikt de support-agent MCP-servers voor Zendesk, Slack, documentzoeken, CRM-opzoeken en interne beleidsherstel.

Een DevOps-agent zou een A2A-interface kunnen blootleggen. Andere agents kunnen hem vragen om een incident te onderzoeken. Intern gebruikt het MCP-servers voor Prometheus, Grafana, GitHub, Kubernetes, logs en cloud-API’s.

Een financiële agent zou een A2A-interface kunnen blootleggen. Andere agents kunnen budgetanalyse aanvragen. Intern gebruikt het MCP-servers voor spreadsheets, boekhoudsystemen, factuurdatabases en voorspellende modellen.

Dit patroon behoudt schone grenzen tussen agents. Andere agents hebben geen directe toegang nodig tot elke tool — ze communiceren met de specialistische agent, die intern beslist welke tools nodig zijn om de taak te voltooien.

Zo werken echte organisaties ook. Je geeft niet iedereen directe toegang tot de productiedatabase. Je vraagt het team of de service die verantwoordelijk is voor dat domein.

Referentiearchitectuur: A2A buiten, MCP binnen

Een praktisch multi-agent-architectuur zou er zo uit kunnen zien:

Gebruiker
  |
  v
Primaire assistent of orchestrator
  |
  |-- A2A --> Onderzoeksagent
  |              |
  |              |-- MCP --> Websearch
  |              |-- MCP --> Documentopslag
  |
  |-- A2A --> Codeeragent
  |              |
  |              |-- MCP --> GitHub
  |              |-- MCP --> Bestandssysteem
  |              |-- MCP --> CI-systeem
  |
  |-- A2A --> DevOps-agent
                 |
                 |-- MCP --> Metrics
                 |-- MCP --> Logs
                 |-- MCP --> Kubernetes

In dit ontwerp behandelt A2A delegatie tussen agents terwijl MCP integratie behandelt tussen elke agent en zijn tools. De orchestrator hoeft niet te weten welke tools beschikbaar zijn voor elke specialist — het hoeft alleen te weten welke agent verantwoordelijk is voor welk type werk, wat tool-overload vermindert en de algehele architectuur modulairer houdt. Voor een diepere behandeling van hoe inferentie, geheugen, routing en tooling samenpassen binnen een productie-assistent, behandelt AI-Assistent Architectuur: LLM, Geheugen, Tools, Routing, Observabiliteit die lagen in detail.

Wanneer A2A overdreven is

A2A is overdreven wanneer de “andere agent” eigenlijk slechts een functie is.

Als je applicatie één LLM-workflow heeft die een paar tools aanroept, voeg dan niet A2A toe alleen omdat het modern klinkt. Een Python-functie, HTTP-endpoint, wachtrij of MCP-tool kan voldoende zijn.

A2A kan te veel zijn wanneer:

• Er slechts één agent is
• Alle componenten in één codebase zitten
• De workflow kort en synchron is
• Je geen ontdekking nodig hebt
• Je geen onafhankelijke taakstaat nodig hebt
• Je geen aparte agent-identiteit nodig hebt
• Je geen third-party agents verwacht
• Je geen leverancier- of framework-interoperabiliteit nodig hebt

Protocollen zijn niet gratis — ze voegen concepten, infrastructuur, debugoppervlak, beveiligingszorgvragen en operationele kosten toe. Een saaie API of een eenvoudige functieaanroep is soms de betere engineeringkeuze, en naar A2A grijpen uit gewoonte in plaats van noodzaak is een eigen vorm van over-engineering. Het kiezen van de eenvoudigere optie is niet anti-A2A; het is pro-architectuur.

Wanneer MCP niet genoeg is

MCP begint ontoereikend te voelen wanneer je het gebruikt om dingen te vertegenwoordigen die duidelijk agents zijn.

Stel bijvoorbeeld dat een MCP-server een tool blootlegt genaamd:

complete_enterprise_procurement_review

Die tool doet het volgende:

• Leest leveranciersdata
• Controleert beleidsregels
• Stelt verduidelijkende vragen
• Delegeert juridische review
• Produceert een risicorapport
• Retourneert meerdere artefacten
• Loopt 20 minuten
• Onderhoudt taakstaat
• Vereist auditgeschiedenis

Op een gegeven moment wordt het noemen van dat een “tool” ongemakkelijk omdat de capaciteit niet langer een eenvoudige aanroepbare functie is — het is een workflow-bezittende specialist met zijn eigen staat, delegatie en auditvereisten. Dat is precies waar A2A een betere fit wordt dan het rekken van de tool-abstractie voorbij zijn natuurlijke grens.

MCP kan krachtige tools blootleggen, maar het lost niet magisch op agent-identiteit, peer-samenwerking, taakeigendom, delegatiesemantiek of multi-agent audittrails.

Als dat je echte problemen zijn, ben je in A2A-territorium.

Beveiliging: Het deel dat iedereen onderschat

Het beveiligingsmodel is waar A2A en MCP beide serieus worden.

MCP geeft agents toegang tot tools en data. Dat betekent dat een AI-systeem bestanden kan lezen, databases kan queryen, API’s kan aanroepen, berichten kan verzenden, tickets kan bijwerken of infrastructuuracties kan triggeren.

A2A stelt agents in staat werk te delegeren aan andere agents. Dat betekent dat één agent context kan doorgeven, acties kan aanvragen en artefacten kan ontvangen van een andere agent.

Beide zijn krachtig. Beide kunnen gevaarlijk zijn.

De belangrijkste beveiligingsvragen zijn anders:

Voor MCP:

• Welke tools kan deze agent gebruiken?
• Welke data kan het lezen?
• Welke acties kan het uitvoeren?
• Goedkeurt de gebruiker de actie?
• Kan tool-metadata het model manipuleren?
• Zijn lokale en externe servers vertrouwd?

Voor A2A:

• Welke agents mogen met elkaar praten?
• Welke identiteit heeft elke agent?
• Kan Agent A autoriteit delegeren aan Agent B?
• Hoeveel context kan worden gedeeld?
• Wie is verantwoordelijk voor het eindresultaat?
• Kan de taakketen worden geaudited?

Daarom is “verbind alles gewoon” een slechte strategie. Hoe meer protocollen je toevoegt, hoe meer je beleid, identiteit, logging, goedkeuringsstromen en least privilege-permissies nodig hebt om het systeem veilig en auditabel te houden.

Een goede productiearchitectuur moet bevatten:

• Agent-identiteit
• Tool-identiteit
• Gebruikersidentiteit
• Gebiedsgebonden permissies
• Goedkeuringspoorten voor risicovolle acties
• Taakniveau auditlogs
• Tool-aanroeplogs
• Delegatielogs
• Artefactprovenance
• Limieten
• Timeout-beleiden
• Uitgaande controles

Als je bouwt met zowel A2A als MCP, is beveiliging geen afterthought. Het is onderdeel van de architectuur.

Observabiliteit: Je hebt traces nodig, niet alleen logs

Multi-agentsystemen zijn moeilijk te debuggen.

Een gebruiker stelt één vraag. De orchestrator roept twee agents aan. Eén agent roept drie tools aan. Een andere agent streamt gedeeltelijke voortgang. Een derde agent faalt en probeert opnieuw. Het eindantwoord ziet er redelijk uit, maar niemand weet welke gegevensbron het beïnvloedde.

Dat is niet acceptabel in productie.

Voor MCP-zware systemen moet je observeren:

• Toolselectie
• Toolargumenten
• Toolresultaten
• Toollatentie
• Toolfouten
• Gebruikersgoedkeuringen
• Context ingespoten in het model

Voor A2A-zware systemen moet je observeren:

• Agent-ontdekking
• Taakcreatie
• Taakstatuswijzigingen
• Agent-naar-agent-berichten
• Geproduceerde artefacten
• Delegatieketens
• Falen en opnieuw proberen
• Eindantwoordprovenance

Hoe meer agentisch het systeem wordt, hoe belangrijker traceerbaarheid wordt — gewone applicatielogs zijn niet genoeg wanneer werk meerdere agents, tool-aanroepen en artefactoverdrachten omvat. Je hebt een taaktrace nodig die het volledige uitvoeringspad volgt zodat elk antwoord kan worden teruggevoerd naar zijn oorsprong. Observabiliteit voor LLM-systemen: Metrics, Traces, Logs en Testing in Productie gaat diep in op de tooling en instrumentatiekant hiervan.

Beslisframework: Heb je A2A, MCP, beide, of geen van beide nodig?

Gebruik dit beslisframework.

Gebruik geen van beide wanneer simpele code voldoende is

Kies normale functies, API’s of wachtrijen wanneer:

• Je alle componenten controleert
• Er geen behoefte is aan LLM-native tool-ontdekking
• Er geen behoefte is aan agent-interoperabiliteit
• Het systeem deterministisch is
• De integratie stabiel en eenvoudig is

Niet elke integratie heeft een AI-protocol nodig.

Gebruik MCP wanneer de agent tools nodig heeft

Kies MCP wanneer:

• De AI-app externe data nodig heeft
• De agent tools nodig heeft aan te roepen
• Je herbruikbare integraties wilt
• Je tool-ontdekking wilt
• Je standaard client-server-integratie wilt
• Je bouwt voor codeeragents, assistants, IDE’s of interne tools

Dit is het standaard startpunt voor de meeste bouwers.

Gebruik A2A wanneer agents peers nodig hebben

Kies A2A wanneer:

• Agents onafhankelijk worden ingedeeld
• Agents elkaar nodig hebben te ontdekken
• Agents zijn gebouwd door verschillende teams of leveranciers
• Taken langlopend zijn
• Delegatie belangrijk is
• Artefacten belangrijk zijn
• Je een agent-grens nodig hebt, niet alleen een tool-grens

Dit is de juiste keuze wanneer de eenheid van architectuur de agent is.

Gebruik beide wanneer specialistische agents tools nodig hebben

Kies beide wanneer:

• Agents met elkaar samenwerken
• Elke agent ook toegang nodig heeft tot tools
• Je schone grens wilt tussen delegatie en uitvoering
• Je specialistische agents wilt met private interne toolchains
• Je schaalbare multi-agent-architectuur wilt

Dit is het meest realistische enterprise-patroon.

Veelvoorkomende anti-patronen

Anti-Patroon 1: Elke tool omzetten in een agent

Niet elke functie verdient een agent-wrapper.

Een valutaconversie-API is waarschijnlijk een tool. Een databasequery is waarschijnlijk een tool. Een bestandlezer is waarschijnlijk een tool.

Het omvatten van elke kleine capaciteit als een A2A-agent creëert onnodige complexiteit.

Anti-Patroon 2: Een hele agent verbergen achter één MCP-tool

De tegengestelde fout komt ook vaak voor.

Als een MCP-tool in het geheim een lange, staatvolgende, multi-agent-workflow uitvoert, kan de MCP-abstractie te dun worden. Je verliest zichtbaarheid in taakstaat, delegatie, artefacten en verantwoordelijkheid.

Op dat punt kan het een A2A-grens verdienen.

Anti-Patroon 3: Elke agent elke tool laten aanroepen

Dit creëert permissiechaos.

Specialistische agents moeten gebieden tools hebben. Een schrijvende agent heeft waarschijnlijk geen toegang tot de productiedatabase nodig. Een onderzoeksagent heeft waarschijnlijk geen toestemming nodig om infrastructuur te implementeren.

Gebruik least privilege.

Anti-Patroon 4: Geen menselijke goedkeuring voor risicovolle acties

Agentic-systemen zouden niet stil high-impact acties moeten uitvoeren.

Menselijke goedkeuring moet vereist zijn voor acties zoals:

• Externe e-mails verzenden
• Productiedata wijzigen
• Infrastructuur implementeren
• Bestanden verwijderen
• Permissies wijzigen
• Services aanschaffen
• Gevoelige data delen

Protocollen maken integratie makkelijker. Ze verwijderen niet verantwoordelijkheid.

Praktische voorbeelden

Voorbeeld 1: Lokale codeerassistent

Een lokale codeerassistent gebruikt MCP om toegang te krijgen tot:

• Bestandssysteem
• Git-repository
• Testrunner
• Pakketbeheerder
• Documentatiezoeken

Het heeft waarschijnlijk geen A2A nodig.

MCP is voldoende.

Voorbeeld 2: Enterprise-supportassistent

Een supportassistent gebruikt MCP om toegang te krijgen tot:

• CRM
• Ticketingsysteem
• Documentatie
• Slack
• Klantendatabase

In het begin is MCP voldoende.

Later voegt het bedrijf specialistische agents toe:

• Factureringsagent
• Juridisch beleidsagent
• Producttroubleshooting-agent
• Escalatieagent

Nu begint A2A zinvol te worden omdat de supportassistent werk moet delegeren aan andere agents.

Gebruik beide.

Voorbeeld 3: Agent-marktplein

Een platform laat third-party agents mogelijkheden adverteren en taken ontvangen van andere agents.

Het platform kent de interne implementatie van elke agent niet.

A2A is een sterke fit.

Individuele agents kunnen intern nog steeds MCP gebruiken, maar de publieke grens is A2A.

Voorbeeld 4: Data-analyseagent

Een data-analyseagent queryt een warehouse, leest dashboards, produceert grafieken en schrijft een rapport.

Als het een enkele agent is die tools gebruikt, is MCP voldoende.

Als het statistische review delegeert aan één agent, zakelijke uitleg aan een ander, en compliance-review aan een ander, wordt A2A nuttig.

Mijn menige mening

MCP is het praktische standaard voor de meeste bouwers, terwijl A2A de architecturale grens is die grotere systemen in groeien zodra ze echte agent-naar-agent-coördinatieneeds hebben.

Als je je eerste nuttige AI-agent bouwt, begin dan met MCP. De AI-systemen cluster behandelt self-hosted assistants, MCP-servers en agent-geheugen als een verbonden set, wat een breder beeld geeft van hoe die stukjes in de praktijk bij elkaar passen. Geef de agent veilige, goed-gebiedde toegang tot tools en data. Leer waar toolbeschrijvingen falen. Leer waar permissies rommelig worden. Leer waar observabiliteit zwak is.

Begin niet met een multi-agent fantasy-architectuur.

Maar zodra je systeem meerdere onafhankelijk bezochte agents heeft, wordt A2A veel interessanter. Het geeft je een schone manier om agent-mogelijkheden, taakdelegatie en cross-agent-samenwerking te vertegenwoordigen.

De fout is het behandelen van A2A en MCP als concurrenten.

Ze worden beter begrepen als verschillende lagen:

• MCP verbindt agents met capaciteiten.
• A2A verbindt agents met andere agents.

Je kunt nuttige systemen bouwen met alleen MCP.

Je kunt agent-netwerken bouwen met alleen A2A.

Maar het meest schaalbare patroon is waarschijnlijk beide: A2A voor agent-samenwerking, MCP voor tool-integratie.

Eindoordeel: Hebben AI-agents echt beide nodig?

Soms — maar niet altijd, en het antwoord hangt bijna volledig af van of je systeem een echte agent-naar-agent-grens heeft of slechts een verzameling van tool-gebruikende functies.

Als je AI-agent slechts tools nodig heeft, gebruik dan MCP.

Als je AI-systeem onafhankelijk ingedeelde agents nodig heeft om samen te werken, gebruik dan A2A.

Als je specialistische agents tools nodig hebben en ook moeten samenwerken met andere agents, gebruik dan beide.

De schoonste architectuur is niet “A2A vs MCP” — het is A2A op de agent-grens en MCP op de tool-grens, met elk protocol dat precies het probleem behandelt waarvoor het is ontworpen. Die scheiding van zorgen is wat multi-agentsystemen begrijpelijk, veilig en gemakkelijker te evolueren houdt over tijd.

Voor een breder beeld van waar A2A staat in 2026 — adoptieniveaus, beveiligingsvereisten, enterprise-gebruikscases en een beslisframework voor wanneer je het moet introduceren — zie Google A2A Protocol in 2026: Adoptie, Hype en Realiteit.

Bronnen

• A2A Protocol Specificatie: https://a2a-protocol.org/latest/specification/
• A2A en MCP vergelijking: https://a2a-protocol.org/latest/topics/a2a-and-mcp/
• MCP introductie: https://modelcontextprotocol.io/docs/getting-started/intro
• MCP architectuur overzicht: https://modelcontextprotocol.io/docs/learn/architecture
• MCP server concepten: https://modelcontextprotocol.io/docs/learn/server-concepts
• Linux Foundation A2A adoptie update: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year