Google A2A-protocol in 2026: Adoptie, Hype en Realiteit

A2A is niet dood. Het is gewoon niet universeel.

Inhoud

Het Agent2Agent-protocol van Google, vaak afgekort tot A2A, had een vreemd eerste jaar.

Toen Google A2A in april 2025 aankondigde, was de boodschap duidelijk: AI-agents die door verschillende leveranciers, frameworks en teams zijn ontwikkeld, hadden een gestandaardiseerde manier van communiceren nodig. Het protocol beloofde agentontdekking, taakdelegatie, berichtenruil, streaming-updates en het delen van artefacten. De reactie was echter aanzienlijk minder schoon dan de aankondiging zelf.

Sommige ontwikkelaars zagen A2A als de ontbrekende laag voor communicatie tussen agents binnen de opkomende agentic-stack. Anderen zagen het als nog een Google-protocol, nog een acroniem en nog een poging om een markt te definiëren voordat die markt daadwerkelijke productienodig had. De sceptische visie kwam neer op één vraag: “We hebben al MCP. Waarom hebben we A2A nodig?” Dat was een eerlijke vraag in 2025, en het blijft een eerlijke vraag in 2026 — hoewel het antwoord aanzienlijk is verschoven.

Twee AI-agentensystemen verbonden door de A2A-protocolbrug

A2A is niet dood, maar het is ook niet universeel nuttig. De praktische realiteit is dat A2A echt waardevol wordt in een specifieke context: waar agents onafhankelijke systemen zijn met hun eigen eigendom, tools en vertrouwensgrenzen, in plaats van alleen interne functies of tool-wrappers. Dat onderscheid tussen toolintegratie en agentdelegatie is wat het protocol eigenlijk ontworpen is om aan te pakken, en het begrijpen daarvan is de sleutel om A2A te evalueren zonder de hype in welke richting dan ook.

Wat is het A2A-protocol van Google?

A2A staat voor Agent2Agent Protocol, en die naam vangt het doel precies op. Het is een open standaard voor communicatie en interoperabiliteit tussen onafhankelijke AI-agentsystemen — specifiek agents die mogelijk zijn gebouwd met verschillende frameworks, talen of vendor-stacks.

A2A gaat niet primair over het verbinden van een agent met een database, bestandssysteem, agenda, API of zoekindex. Dat is meer het werk van MCP, het Model Context Protocol. A2A gaat over iets anders: één agent communiceert met een andere agent, waarbij het peersysteem wordt behandeld als een actor met eigen capaciteiten in plaats van als een passieve gegevensbron.

Een typische A2A-stroom kan het volgende omvatten:

Ontdekking van een agent via een Agent Card
Het lezen van de vaardigheden en capaciteiten van de agent
Het verzenden van een taak
Het uitwisselen van berichten
Het ontvangen van statusupdates
Het afhandelen van toestanden waarin invoer vereist is
Het ontvangen van definitieve artefacten
Het volgen van voltooiing, fouten of annulering

Het belangrijke woord in die lijst is “taak”. A2A is niet alleen een function call met een andere wrapper — het is een protocol voor de levenscyclus van taken voor agent-samenwerking, ontworpen om de volledige boog af te dekken van ontdekking en delegatie via uitvoering en statusupdates tot het teruggeven van artefacten. Voor een gedetailleerde technische doorloop van elk concept — Agent Cards, taaklevenscyclus, berichten, delen en artefacten — zie Wat is het A2A-protocol? Agent Cards en taken uitgelegd. Voor informatie over hoe streaming, pushmeldingen en human-in-the-loop-pauzes werken in de productie, zie A2A Streaming en Async Taken voor Lange Agentenwerkstromen.

Waarom A2A makkelijk te belachelijk maken was

A2A verscheen op een markt die al verzond in agentacroniemen.

In 2025 hadden ontwikkelaars al te maken met:

LLM-API’s
Function calling
Tool calling
Agentframeworks
MCP-servers
RAG-pipelines
Workflow-engines
Multi-agent-orkestratiebibliotheken
Aangepaste JSON-protocollen
Interne pluginsystemen

Dus toen Google A2A aankondigde, was een veelvoorkomende reactie voorspelbaar:

“Hebben we echt nog een standaard nodig?”

De scepsis was niet irrational, en hij kwam vanuit meerdere richtingen tegelijk. A2A leek te overlappen met MCP. Het kwam van Google, wat sommige ontwikkelaars zorgen maakte over de langetermijncommitment. Het verscheen voordat de meeste teams zelfs basisproblemen hadden opgelost zoals tooltoegang, prompt-injectie, observabiliteit, kostenbeheersing en beveiliging voor single-agent-systemen.

In die omgeving klonk “agent-to-agent interoperabiliteit” ambitieus, maar ook een beetje voortijdig.

En om er eerlijk in te zijn, hadden veel AI-agenten-demos in 2025 helemaal geen A2A nodig.

Ze hadden betere prompts nodig, betere tools, betere permissies, betere retry-logic en betere logs.

De update van 2026: A2A is niet dood

De grote verandering in 2026 is dat A2A niet langer alleen een Google-aankondiging is.

In april 2026 meldde de Linux Foundation dat het A2A-project meer dan 150 ondersteunende organisaties had, integraties met grote cloudplatforms had verworven en productie-implementaties had bereikt in meerdere sectoren.

Dat betekent niet dat elke claim zonder scepsis moet worden geslikt. “Ondersteund door” is niet hetzelfde als “diep gebruikt in productie door de meeste ontwikkelaars”. Protocolecosystemen zien er vaak groter uit in persberichten dan ze voelen in het dagelijkse ingenieurswerk.

Het signaal is echter belangrijk, omdat het moeilijker te negeren is. A2A heeft een belangrijke lijn overschreden: het is niet langer alleen een blogpost van Google. Het heeft een formele specificatie, governance-momentum, openbare voorbeelden, SDK-werk, aandacht van cloudplatforms en een groeiend ecosysteem rond agentinteroperabiliteit. Dat maakt het label “dood” moeilijk te verdedigen op technische of adoptiegronden.

Een verdedigbaarere kritiek is dat A2A levend is, maar dat het nuttige bereik smaller is dan de hype suggereert.

A2A vs MCP: De verwarring die niet wilde sterven

De meeste verwarring over A2A komt voort uit de relatie met MCP.

MCP, gemaakt door Anthropic, standaardiseert hoe AI-applicaties verbinding maken met externe tools en gegevensbronnen. MCP-servers tonen tools, bronnen en prompts. AI-hosts en clients consumeren ze.

In eenvoudige termen:

MCP verbindt agents met tools.
A2A verbindt agents met andere agents.

Dat klinkt schoon, maar de echte wereld is aanzienlijk rommeliger. Een MCP-server kan iets blootleggen dat er zeer agentisch uitziet — bijvoorbeeld een MCP-tool genaamd research_company die intern zoekopdrachten, ophaling, samenvatting, ranking en rapportage uitvoert. Vanuit het perspectief van de MCP-host is het een tool. Vanuit architectuurperspectief verbergt het een agentachtige workflow achter een function call-grens. Deze ambiguïteit is precies waarom sommige ontwikkelaars betoogden dat A2A onnodig was: als een agent kan worden weergegeven als een MCP-tool, waarom dan een apart protocol creëren?

Het antwoord is dat A2A eerste-klasse structuur geeft aan dingen die MCP onhandiger behandelt:

Agentontdekking
Agentcapaciteiten
Taaklevenscyclus
Langlopend werk
Multi-turn taaktoestand
Agent-to-agent berichten
Artefacten
Samenwerking tussen obscure agents
Delegatie over organisatorische grenzen heen

MCP kan veel omvatten, maar alles als een tool omvatten wordt uiteindelijk een slechte abstractie. Op een bepaald moment heeft een specialistisch systeem zoveel eigen toestand, beleid, levenscyclus en besluitvormingsbevoegdheid dat het modelleren als een tool de architectuur verduistert in plaats van te vereenvoudigen. Dat is het inflectiepunt waarbij het behandelen van een peer-agent als een peer-agent — in plaats van als een tool call — begint af te rekenen. Voor een gedetailleerde vergelijking van waar de grens in de praktijk ligt, zie A2A vs MCP: Hebben AI-agents echt beide protocollen nodig?

Het beste mentale model: MCP beneden, A2A boven

De schoonste architectuur is niet “A2A vs MCP”.

De schoonste architectuur is gelaagd:

flowchart TD U["Gebruiker of applicatie"] O["Primaire assistent / orkestrator"] S1["Specialistische agent A"] S2["Specialistische agent B"] T1["Tools, API's, bestanden, databases"] T2["Meer tools en gegevensbronnen"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

In dit model:

A2A is de laag voor agentsamenwerking.
MCP is de laag voor toolintegratie.

Dat is het patroon dat het meest logisch is in 2026, en het is de framing waartoe de meeste serieuze agent-architecten convergeren. A2A moet MCP niet vervangen, en MCP mag niet worden gedwongen om elke agentgrens te vertegenwoordigen — ze lossen verschillende problemen op op verschillende lagen van de stack. De framing van de “protocoloorlog” is grotendeels lui analyse die goede koppen oplevert, maar niets doet om engineers te helpen betere systemen te ontwerpen.

Waar A2A daadwerkelijk nuttig is

A2A wordt nuttig wanneer een agent niet langer slechts een library-call is binnen je applicatie.

Het is nuttig wanneer agents:

Onafhankelijk worden deployed
Eigendom zijn van verschillende teams
Zijn gebouwd met verschillende frameworks
Worden blootgesteld door leveranciers
Draaien met hun eigen tools en permissies
Verantwoordelijk zijn voor langlopende taken
Artefacten retourneren in plaats van simpele waarden
Onderdeel zijn van een bredere multi-agent-werkstroom

Stel je bijvoorbeeld een enterprise-assistent voor die een leveranciersrisicorapport moet voorbereiden.

Het kan werk delegeren naar:

Een inkoopagent
Een juridische review-agent
Een financiële agent
Een compliance-agent
Een marktonderzoekagent
Een rapportageschrijver-agent

Elke agent heeft zijn eigen domein, tools, regels, permissies en auditvereisten.

Voor dat soort systeem is A2A niet absurd. Het is een redelijke grens.

De primaire assistent hoeft niet directe toegang te hebben tot elke inkoopdatabase, juridische beleidswinkel, financiële spreadsheet en compliance-werkstroom. Het moet de verantwoordelijke agent vragen de taak uit te voeren.

Dat is het essentiële onderscheid: tooltoegang is een verticale verbinding tussen een agent en zijn bronnen, terwijl domeindelegatie een horizontale overdracht is tussen autonome agents, elk met zijn eigen grens van autoriteit en verantwoordelijkheid. Het gelaagde model voor hoe deze componenten combineren — LLM, geheugen, tooling, routing en observabiliteit — wordt besproken in AI-Assistent Architectuur: LLM, Geheugen, Tools, Routing, Observabiliteit.

Waar A2A nog steeds overhypet is

A2A is overhypet wanneer het wordt gepresenteerd als verplichte infrastructuur voor elk AI-project.

De meeste projecten hebben het niet nodig.

Als je een lokale coding-assistent bouwt, een chatbot voor je documentatie, een kleine interne automatiseringsagent of een enkele workflow die een handvol tools aanroept, is A2A waarschijnlijk overbodig.

Je hebt misschien nodig:

MCP
Goede toolschemas
Guardrails
Evaluatie
Logging
Kostenbeheersing
Retry-logic
Betere prompts
Betere retrieval

Je hebt waarschijnlijk geen volledig agent-to-agent-protocol nodig.

A2A kan een fout zijn wanneer:

Er maar één agent is
Alle componenten in één codebase leven
Werkstromen kort en synchron zijn
Agents geen ontdekking nodig hebben
Agents geen onafhankelijke taaktoestand nodig hebben
Er geen externe agent-leveranciers zijn
Een API of queue eenvoudiger zou zijn
Het team de extra complexiteit niet kan exploiteren

Een protocol is niet gratis. Het voegt concepten toe, foutmodi, debug-overhead, beveiligingszorgen en operationeel werk.

In veel kleine systemen is het adopteren van A2A architectuurcosplay — het lenen van de vocabulaire van gedistribueerde agentsystemen zonder de daadwerkelijke grensproblemen die het protocol waardevol maken.

A2A en het Google-probleem

Een deel van de A2A-scepsis komt voort uit Google zelf.

Ontwikkelaars hebben een lang geheugen. Wanneer Google een platform, protocol, product of ecosysteem lanceert, vragen veel engineers onmiddellijk:

“Bestaat dit over drie jaar nog?”

Die reactie is niet helemaal eerlijk voor het technische ontwerp van A2A, maar het is een echte adoptiefactor.

Het verhaal van de Linux Foundation-hosting helpt hier. A2A deel worden van een bredere open governance-omgeving maakt het minder afhankelijk van de interne prioriteiten van Google.

Dat garandeert niet succes. Open governance creëert niet magisch ontwikkelaadoptie. Maar het vermindert wel een van de grootste zorgen: dat A2A alleen een door Google gecontroleerde strategische zet is.

In 2026 moet A2A minder worden beoordeeld als “Google’s protocol” en meer als een opkomende standaard voor agentinteroperabiliteit die Google heeft geholpen te starten.

Dat is een gezonder lens, en het is de lens die het makkelijker maakt om de technische verdiensten van A2A te evalueren op hun eigen termen, in plaats van door de filter van Google’s historische relatie met ontwikkelaarecosystemen.

Adoptie: Sterk signaal, maar niet het hele verhaal

De gerapporteerde 150+ ondersteunende organisaties is betekenisvol, maar het mag niet worden verward met universele ontwikkelaadoptie. “Ondersteund door” is een spectrum, geen binair, en het helpt om adoptieclaims met dat in gedachten te lezen.

Aan de zwakste kant staat logo-adoptie: een bedrijf zegt dat het de standaard ondersteunt, wat kan wijzen op echte implementatie, strategische positionering, een prototype of simpelweg geplande ondersteuning die niet is materialiseerd. Iets sterker is SDK-adoptie, waarbij ontwikkelaars daadwerkelijk kunnen bouwen met beschikbare bibliotheken, voorbeelden en documentatie — dit betekent dat het protocol is overgestapt van presentaties naar werkende implementatie, en dat echte engineers het de moeite waard vonden hun tijd te besteden. Nog sterker is platformadoptie, waarbij clouds, agentframeworks en enterprisesystemen echte native ondersteuning blootstellen, waardoor A2A een aannemelijke standaard architectuurkeuze wordt in plaats van iets dat teams zelf moeten samenstellen.

De enige adoptielayer die echt belangrijk is voor de langetermijngezondheid van het ecosysteem is productieretentie. Voor een gevoel van wat echte adoptiecurves eruitzien in de AI-agentruimte — gemeten in GitHub-sterren, OpenRouter-tokens en downloadtrends — toont de OpenClaw vs Hermes Agent populariteitsdata hoe snel momentum bouwt en plateau bereikt zodra de energie van vroege adopteurs afneemt.: teams die vertrouwen op het protocol voor live werkstromen na de initiële 90-dagen huwelijksnacht. De update van de Linux Foundation in 2026 claimt productieve gebruik in meerdere sectoren, wat betekenisvol bewijs is. Maar de nuttigste vraag is niet “wie ondersteunt A2A?” — het is “wie houdt A2A in productie na de eerste echte operationele incident?” Langetermijnretentie onder druk is het signaal dat ware infrastructuur scheidt van protocoltheater.

De echte test: Retentie in productie

Ontwikkelaars hype is goedkoop, en productieretentie is duur. De twee zijn zelden evenredig, wat de reden is waarom de 90-dagen retentievraag belangrijker is dan enthousiasme in de lanceringweek.

A2A zal zichzelf bewijzen als teams het blijven gebruiken nadat ze zijn tegengekomen:

Authenticatieproblemen
Autorisatieproblemen
Agentidentiteitsproblemen
Debugproblemen
Randgevalen in taaklevenscyclus
Streamingfouten
Versiecompatibiliteit
Verschillen tussen leveranciers
Kostenverrassingen
Beveiligingsreviews
Auditvereisten
Menselijke goedkeuringswerkstromen

Hier falen veel agentframeworks en protocollen. Ze zien er elegant uit in diagrammen, maar worden pijnlijk in productie.

A2A heeft een goede reden om te bestaan, maar goede redenen vertalen zich niet automatisch naar productierobustheid. Het protocol moet de operationele realiteit overleven die het onderweg van demo naar deployment aantreft.

Het beste teken voor A2A in 2026 is niet dat mensen blogposts over schrijven. Het beste teken is dat enterprises het beginnen te gebruiken voor echte multi-agentgrenzen.

Het slechtste teken zou zijn als ontwikkelaars het alleen gebruiken in demos terwijl productsystemen terugvallen naar aangepaste API’s en queues.

Beveiliging is het grootste onopgeloste vraagstuk

De moeilijkste problemen van A2A zijn geen syntax- of specificatieproblemen. Het zijn vertrouwensproblemen die ontstaan wanneer je daadwerkelijk autonome agents deployt over organisatorische of systeemgrenzen heen.

Wanneer één agent met een andere agent praat, worden enkele vragen urgent:

Wie is deze agent?
Wie is de eigenaar?
Wat mag het weten?
Wat mag het doen?
Kan het werk verder delegeren?
Kan het tools namens een gebruiker aanroepen?
Kan het de intentie van de gebruiker behouden?
Kan het bewijzen wat er is gebeurd?
Kan het worden geaudited nadat de taak is voltooid?

Deze vragen zijn optioneel niet in enterprise-omgevingen.

A2A maakt agentsamenwerking gemakkelijker. Het creëert ook nieuwe plekken waar vertrouwen kan breken.

Bijvoorbeeld:

Een kwaadaardige agent zou zijn capaciteiten kunnen verkeerd voorstellen.
Een gecompromitteerde agent zou gevoelige context kunnen aanvragen.
Een gedelegeerde taak zou de autoriteit van de gebruiker kunnen overschrijden.
Een agent zou vergiftigde artefacten kunnen teruggeven.
Een keten van agents zou verantwoordelijkheid onduidelijk kunnen maken.
Gevoelige data zou over grenzen kunnen stromen zonder juiste logging.

Daarom hebben serieuze A2A-systemen meer nodig dan alleen protocolvervulling.

Ze hebben nodig:

Sterke agentidentiteit
Gebiedsgewijze autorisatie
Taakniveau auditlogs
Delegatievolging
Menselijke goedkeuring voor risicovolle acties
Artefactprovenance
Rate limits
Beleidshandhaving
Observabiliteit over agentgrenzen heen

A2A is geen beveiligingsarchitectuur op zich — het is een communicatieprotocol dat moet worden deployed binnen één, met expliciete beslissingen over identiteit, autorisatie, audit en beleidshandhaving aan elke grens die het overschrijdt. A2A en MCP Agent Beveiliging: Identiteit, Delegatie en Audit Trails legt die omliggende architectuur gedetailleerd uit.

A2A en het idee van een Agent Marketplace

Een van de interessantere langetermijngebruiksgevallen van A2A zijn agentmarketplaces.

Als agents capaciteiten kunnen adverteren via Agent Cards, dan kunnen andere agents of platforms ze ontdekken, evalueren en taken verzenden.

Dat creëert een mogelijke toekomst waarin agentcapaciteiten modularer worden:

Een belastingagent
Een juridische agent
Een code review-agent
Een reisplanningagent
Een beveiligingsanalyseagent
Een inkoopagent
Een datakwaliteitsagent

Elke zou een standaardinterface kunnen blootleggen voor taakgebaseerde samenwerking.

Dat klinkt spannend, maar het is ook waar hype gevaarlijk wordt.

Een open agentmarketplace heeft meer nodig dan Agent Cards. Het heeft identiteit, reputatie, facturatie, compliance, sandboxing, aansprakelijkheid, versiebeheer en geschillenoplossing nodig.

Zonder die dingen wordt een agentmarketplace een beveiligingsincident dat wacht om te gebeuren.

A2A is een nuttig bouwsteen voor deze toekomst, maar het is slechts één stuk van een veel grotere puzzel die ook identiteitssystemen, reputatiemechanismen, factureringsinfrastructuur, compliancecontroles en geschillenoplossing vereist voordat het een veilige markt wordt om in te opereren.

A2A voor interne enterprise-agents

Het realistischere korte-termijngebruik is geen openbare agentmarketplaces.

Het zijn interne enterprise-agentennetwerken.

Grote organisaties hebben al veel grenzen:

Teams
Afdelingen
Systemen
Leveranciers
Gegevensdomeinen
Compliancezones
Beveiligingsbeleid
Goedkeuringsprocessen

A2A kaart natuurlijk op deze grenzen, omdat het protocol is ontworpen rond dezelfde fundamentele behoefte: gestructureerde communicatie tussen systemen die hun eigen eigendom hebben en geen codebase delen. De bredere AI Systemen cluster dekt hoe specialistische agents zoals Hermes en OpenClaw in de praktijk passen in dit soort gelaagde architectuur.

In plaats van één enorme assistent te bouwen met directe toegang tot alles, kan een enterprise specialistische agents bouwen met beperkte verantwoordelijkheid:

HR-agent
Financiële agent
Supportagent
DevOps-agent
Beveiligingsagent
Kennismanagementagent
Dataplatformagent

Elke agent kan zijn tools en beleid intern bezitten. Andere agents kunnen ermee interageren via A2A.

Dit is een veel beter model dan een single general-purpose agent directe toegang te geven tot elk systeem in de organisatie, zowel vanuit beveiligingsperspectief als vanuit operationeel perspectief. Elke specialistische agent kan onafhankelijk worden bezeten, geëxploiteerd, geaudited en beveiligd, wat het hele systeem ook makkelijker maakt om te redeneren als er iets misgaat.

A2A voor kleine teams en indie hackers

Voor kleine teams die producten bouwen met één of twee agents, is A2A echt minder urgent — en vaak een afleiding van meer directe problemen. Je hebt waarschijnlijk nog geen agent-to-agent-protocol nodig.

Gebruik normale code. Gebruik HTTP-API’s. Gebruik queues. Gebruik MCP waar toolintegratie belangrijk is.

Voeg A2A toe wanneer je daadwerkelijk hebt:

Meerdere onafhankelijke agents
Derde-partij agentgrenzen
Langlopende gedelegeerde taken
Agentontdekkingsvereisten
Artefactuitwisselingsvereisten
Cross-framework interoperabiliteitsbehoeften

De volgorde is belangrijker dan de ambitie. Begin met de eenvoudigste architectuur die de echte drukpunten blootlegt, en laat die drukpunten je vertellen of je A2A echt nodig hebt voordat je committeert aan de complexiteit die het brengt. Voor de meeste kleine bouwers is MCP eerst en A2A later het juiste pad.

Een praktisch besliskader

Gebruik dit kader bij het beslissen of A2A in je systeem thuishoort.

Geen A2A wanneer de workflow lokaal is. Vermijd A2A wanneer alles binnen één applicatie draait en de componenten niet onafhankelijk deploybaar zijn. Een Python-functie, klasse, service, queue of workflow-engine is waarschijnlijk genoeg.

MCP wanneer de agent tools nodig heeft. Gebruik MCP wanneer je agent gestandaardiseerde toegang nodig heeft tot bestanden, databases, API’s, SaaS-systemen, zoekindexes, repositories, interne documentatie of observabiliteitssystemen. MCP biedt onmiddellijke praktische waarde en is het juiste startpunt voor de meeste teams die vandaag agents bouwen.

A2A wanneer de agent peers nodig heeft. Gebruik A2A wanneer je agent moet communiceren met andere onafhankelijke agents — vooral wanneer die agents hun eigen capaciteiten, beleid, toestand, tools, eigenaars, deployment-levenscyclus en beveiligingsgrens hebben.

Beide wanneer de architectuur lagen heeft. Gebruik beide wanneer specialistische agents met elkaar samenwerken en elke specialist ook tools nodig heeft. Het productiemodel is A2A tussen agents en MCP tussen agents en tools. Dat is de meest verstandige versie van de 2026 agent-protocolstack, en de architectuur die het schoonst kaart op hoe productie multi-agentsystemen daadwerkelijk worden gebouwd.

Veelvoorkomende fouten met A2A

A2A gebruiken omdat het strategisch klinkt. Dit is de klassieke enterprise-architectuurval. A2A moet een echt grensprobleem oplossen dat bestaat in de architectuur, niet één die is verzonnen om de protocolkeuze te rechtvaardigen. Als er geen echte grens is — geen onafhankelijke deployment, geen apart eigendom, geen distinct beveiligingsperimeter — is er waarschijnlijk geen behoefte aan A2A.

MCP en A2A behandelen als concurrenten. MCP is niet verouderd omdat A2A bestaat, en A2A is niet onnodig omdat MCP bestaat. Ze adresseren verschillende structurele problemen en werken het beste als complementaire lagen, niet als concurrerende alternatieven.

Elke capaciteit blootleggen als een agent. Een rekenmachine hoeft geen agent te zijn. Een weers-API hoeft geen agent te zijn. Een databasequery hoeft geen agent te zijn. Veel dingen zijn straightforward tools, en de agentabstractie voegt overhead toe zonder duidelijkheid toe te voegen wanneer toegepast op componenten die geen betekenisvolle autonomie, toestand of levenscyclus van eigen hebben.

Een volledige agent verbergen achter één tool. Het omgekeerde fout is ook veelvoorkomend. Als een “tool” zijn eigen taaklevenscyclus, geheugen, beleid, artefacten en delegatiegedrag heeft, zou het misschien als een agent gemodelleerd moeten worden in plaats van te worden ingeperkt achter een function call-grens.

Observabiliteit negeren. Multi-agentsystemen zonder traces zijn pijnlijk om te debuggen en onmogelijk om te auditten. Je moet weten welke agent de taak ontving, welke berichten werden uitgewisseld, welke tools werden aangeroepen, welke artefacten werden geproduceerd, welke beleid werden toegepast en welke agent het definitieve besluit nam. Zonder die zichtbaarheid wordt debugging archeologie — het reconstrueren van wat er is gebeurd door inferentie in plaats van observatie. De volledige observabiliteitsstack voor AI- en LLM-gesysteeminclusief metrics, gedistribueerde traces en SLO’s die agentgrenzen overschrijden, wordt besproken in Observabiliteit voor LLM-systemen: Metrics, Traces, Logs en Testing in Productie.

Is A2A dan overhypet?

Ja, gedeeltelijk. A2A is overhypet wanneer het wordt gepresenteerd als de onvermijdelijke standaard voor alle AI-agentsystemen, wanneer mensen impliceren dat elke ontwikkelaar het onmiddellijk moet adopteren, wanneer agent-demos A2A gebruiken om te coördineren wat drie function calls hadden kunnen zijn, of wanneer de protocolldiscussie identiteit, autorisatie, observabiliteit en productieoperaties negeert. Dit zijn echte voorbeelden van hype die A2A universeeler maakt dan het is.

Maar overhypet betekent niet nutteloos. Veel belangrijke technologieën zijn overhypet voordat ze saai infrastructuur worden, en de hype arriveert vaak lang voordat het ecosysteem rijp genoeg is om het te ondersteunen. De echte vraag is niet of de marketing excessief is — het is dat soms duidelijk. De echte vraag is of de onderliggende abstractie nuttig is, en voor A2A is het antwoord ja wanneer agents daadwerkelijk onafhankelijke actoren worden in een systeem met echte grenzen, echt eigendom en echte inzet.

Is A2A dan dood?

Nee.

Het argument “A2A is dood” had meer zin tijdens de vroege scepsisfase, toen het protocol leek als een door Google geleid antwoord op MCP-momentum.

In 2026 is dat argument zwakker.

A2A heeft een formele specificatie, ecosysteemondersteuning, Linux Foundation-momentum, grote cloudaandacht en gerapporteerde productie-implementaties.

Niets daarvan maakt A2A dominant, verplicht of universeel geliefd door de ontwikkelaargemeenschap — maar het is duidelijk niet dood. Een beter statement is dat A2A levend is en nog steeds zijn productiewaarde bewijst buiten enterprise- en platformecosystemen, waar de meeste bevestigde implementaties momenteel leven.

Is A2A dan eindelijk nuttig in 2026?

Ja, maar alleen in de juiste architectuur. A2A is nuttig wanneer je systeem echte agentgrenzen heeft — niet alleen omdat je code meerdere prompts heeft, of omdat je systeem het woord “agent” gebruikt in variablenamen. Het wordt nuttig wanneer agentsamenwerking daadwerkelijk gestandaardiseerde structuur nodig heeft:

Ontdekking
Capaciteiten
Taaklevenscyclus
Berichten
Artefacten
Langlopend werk
Obscure implementatiegrenzen
Cross-vendor interoperabiliteit

Dat is waar A2A zijn plek verdient, door een gemeenschappelijk contract voor samenwerking te bieden dat anders aangepast protocolwerk zou vereisen aan elke grens.

Mijn meningsuiting

A2A is niet het protocol waarmee de meeste ontwikkelaars moeten beginnen — MCP is dat. MCP lost een meer directe en breder toepasbaar probleem op: het verbinden van agents met nuttige tools en context. A2A lost een latere-stadium probleem op: het verbinden van onafhankelijke agents met elkaar over echte deployment- en eigendomsgrenzen heen. Dat maakt MCP nuttiger vandaag voor het overgrote deel van individuele ontwikkelaars en kleine teams.

A2A kan belangrijker worden naarmate agentsystemen rijpen van demos naar enterprise-werkstromen. Zodra organisaties meerdere specialistische agents hebben die eigendom zijn van verschillende teams, wordt de behoefte aan een gestandaardiseerde agent-to-agent-grens duidelijk en begint de overhead van het protocol zichzelf terug te verdienen.

Mijn praktische aanbeveling is om te beginnen met MCP, schone agentgrenzen vanaf het begin te ontwerpen, en A2A alleen toe te voegen wanneer die grenzen echte deployment-, eigendom- of interoperabiliteitsbeperkingen worden. Adopteer A2A niet voor vibes. Adopteer het wanneer de architectuur het vereist.

Eindoordeel

Het A2A-protocol van Google is niet dood.

Het is ook niet de universele toekomst van elk AI-agentproject.

Het is een nuttig, nog steeds volgend protocol voor een specifiek probleem: communicatie tussen onafhankelijke AI-agents.

Als je een simpele assistent bouwt, is A2A waarschijnlijk overbodig.

Als je een multi-agent enterprise-systeem bouwt, een agentmarketplace, een vendor-neutrale agentennetwerk of een set onafhankelijk deployede specialistische agents, is A2A de serieuze aandacht waard.

De beste 2026 framing is niet:

A2A vs MCP

Het is:

MCP voor tools.
A2A voor agents.
Beide voor serieuze multi-agentsystemen.

Dat is minder dramatisch dan een protocoloorlog-narratief, maar het is ook accurater en nuttiger voor engineers die echte architectuurbeslissingen moeten nemen.