Google A2A-protocol in 2026: adoptie, hype en realiteit

A2A is niet dood. Het is gewoon niet universeel.

Inhoud

Het Agent2Agent-protocol van Google, meestal afgekort als A2A, beleefde 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 gebouwd, hadden een standaard manier nodig om met elkaar te communiceren. Het protocol beloofte agent-discovery, taakdelegatie, berichtuitwisseling, streaming-updates en het delen van artefacten. De reactie was echter aanzienlijk minder helder dan de aankondiging zelf.

Sommige ontwikkelaars zagen A2A als de ontbrekende agent-naar-agent-laag voor het 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 productiebehoefte had. De sceptische kijk 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-agentsystemen 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 slechts interne functies of tool-wrappers. Dat onderscheid tussen tool-integratie en agent-delegatie is wat het protocol eigenlijk is ontworpen om aan te pakken, en het begrijpen daarvan is de sleutel om A2A te evalueren zonder de hype in beide richtingen.

Wat is het A2A-protocol van Google?

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

A2A gaat niet vooral over het verbinden van een agent met een database, bestandssysteem, agenda, API of zoekindex. Dat is dichter bij 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-flow kan betrekking hebben op:

Het ontdekken 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 waarbij invoer vereist is
Het ontvangen van finale artefacten
Het bijhouden van voltooiing, mislukking of annulering

Het belangrijke woord in die lijst is “taak”. A2A is niet slechts een function call met een andere wrapper — het is een taaklevenscyclusprotocol voor agentsamenwerking, ontworpen om de volledige cirkel te behandelen van discovery en delegatie tot uitvoering, statusupdates en het teruggeven van artefacten. Voor een diepgaande technische walkthrough van elk concept — Agent Cards, taaklevenscyclus, berichten, delen en artefacten — zie Wat is het A2A-protocol? Agent Cards en taken uitgelegd.

Waarom A2A makkelijk te belachelijk maken was

A2A kwam binnen op een markt die al onderliep in agent-acroniemen.

In 2025 hadden ontwikkelaars al te maken met:

LLM-API’s
Function calling
Tool calling
Agent-frameworks
MCP-servers
RAG-pipelines
Workflow-engines
Multi-agent orchestration-bibliotheken
Aangepaste JSON-protocollen
Interne pluginsystemen

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

“Hadden we echt nog een standaard nodig?”

Het scepticisme was niet irrationeel, en het kwam uit meerdere richtingen tegelijk. A2A leek te overlappen met MCP. Het kwam van Google, wat sommige ontwikkelaars zorgen deed over langetermijncommitment. Het arriveerde voordat de meeste teams zelfs basisproblemen zoals tool-toegang, prompt-injectie, observability, kostenbeheersing en beveiliging voor single-agent-systemen hadden opgelost.

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

En om eerlijk te zijn, hadden veel AI-agent-demos in 2025 überhaupt 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 slechts een Google-aankondiging is.

In april 2026 meldde de Linux Foundation dat het A2A-project 150 ondersteunende organisaties had gepasseerd, grote cloudplatformintegraties had verkregen en productie-implementaties had bereikt in meerdere sectoren.

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

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

Een beter verdedigbare kritiek is dat A2A levend is, maar dat zijn nuttige bereik smaller is dan de hype suggereert.

A2A vs MCP: De verwarring die niet wilde sterven

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

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

In simpele termen:

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

Dat klinkt helder, maar de echte wereld is aanzienlijk rommeliger. Een MCP-server kan iets tonen dat er zeer agentic uitziet — bijvoorbeeld een MCP-tool genaamd research_company die intern zoeken, retrieval, samenvatting, ranking en rapportage uitvoert. Vanuit het perspectief van de MCP-host is het een tool. Vanuit een architectuurperspectief verbergt het een agent-achtige workflow achter een function call-grens. Deze ambiguïteit is precies waarom sommige ontwikkelaars betoogden dat A2A onnodig was: als een agent kan worden vertegenwoordigd 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:

Agent discovery
Agentcapaciteiten
Taaklevenscyclus
Langlopend werk
Multi-turn taaktoestand
Agent-to-agent messaging
Artefacten
Samenwerking tussen opaque agents
Delegatie over organisatorische grenzen heen

MCP kan veel omwikkelen, maar alles omwikkelen als een tool wordt uiteindelijk een slechte abstractie. Op een gegeven moment heeft een specialistisch systeem zo veel eigen toestand, beleid, levenscyclus en beslissingsautoriteit dat het modelleren ervan als een tool de architectuur verduistert in plaats van vereenvoudigt. Dat is het inflection point waar het behandelen van een peer-agent als een peer-agent — in plaats van als een tool call — begint af te betalen. Voor een gedetailleerde vergelijking van waar de grens in de praktijk valt, zie A2A vs MCP: Hebben AI-agents echt beide protocollen nodig?

Het beste mentale model: MCP onder, A2A boven

De schoonste architectuur is niet “A2A vs MCP”.

De schoonste architectuur is gelaagd:

flowchart TD U["Gebruiker of applicatie"] O["Primaire assistent / orchestrator"] S1["Specialist agent A"] S2["Specialist 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 agentsamenwerkingslaag.
MCP is de tool-integratielaag.

Dat is het patroon dat in 2026 het meest logisch is, en het is de framing waarnaar de meeste serieuze agent-architecten convergeren. A2A zou MCP niet moeten vervangen, en MCP zou niet gedwongen moeten worden om elke agent-grens te vertegenwoordigen — ze lossen verschillende problemen op op verschillende lagen van de stack. De framing van een “protocoloorlog” is voor het grootste deel lui analyse die goed is voor koppen, maar niets doet om engineers te helpen betere systemen te ontwerpen.

Waar A2A echt 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 gedeployd
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 teruggeven in plaats van simpele waarden
Onderdeel zijn van een bredere multi-agent workflow

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

Het kan werk delegeren aan:

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

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

Voor zo’n systeem is A2A niet absurd. Het is een redelijke grens.

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

Dat is het essentiële onderscheid: tool-toegang is een verticale verbinding tussen een agent en zijn resources, 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 observability — wordt behandeld in AI-assistent architectuur: LLM, geheugen, tools, routing, observability.

Waar A2A nog steeds overhypet is

A2A is overhypet wanneer mensen het presenteren 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 onnodig.

Je hebt misschien nodig:

MCP
Goede tool-schemas
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 slechts één agent is
Alle componenten in één codebase leven
Workflows kort en synchron zijn
Agents geen discovery 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 beheren

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

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 het A2A-scepticisme komt voort uit Google zelf.

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

“Bestaat dit over drie jaar nog?”

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

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

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

In 2026 zou A2A minder moeten worden beoordeeld als “het protocol van Google” en meer als een opkomende agent-interoperabiliteitsstandaard die Google heeft helpen starten.

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

Adoptie: Sterk signaal, maar niet het hele verhaal

De gemelde 150+ ondersteunende organisaties is betekenisvol, maar het mag niet worden verward met universele developer-adoptie. “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 slideware naar werkende implementatie, en dat echte engineers het de moeite waard vonden. Sterker nog is platform-adoptie, waarbij clouds, agent-frameworks en enterprise-systemen echte native ondersteuning tonen, waardoor A2A een aannemelijke standaard architectuurkeuze wordt in plaats van iets dat teams zelf moeten aansluiten.

De enige adoptielayer die echt belangrijk is voor de langetermijngezondheid van het ecosysteem is productieretentie. Voor een idee van wat echte adoptiecijfers 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’s bereikt zodra de energie van early adopters afneemt.: teams die het protocol gebruiken voor live workflows na de initiële 90-dagen honeymoon. De update van de Linux Foundation in 2026 claimt productieverbruik in meerdere sectoren, wat betekenisvol bewijs is. Maar de nuttiger vraag is niet “wie ondersteunt A2A?” — het is “wie houdt A2A in productie na het eerste echte operationele incident?”. Langetermijnretentie onder druk is het signaal dat echte infrastructuur scheidt van protocoltheater.

De echte test: Retentie in productie

Developer-hype is goedkoop, en productieretentie is duur. De twee zijn zelden evenredig, wat de vraag naar 90-dagen retentie belangrijker maakt dan launch-week-enthousiasme.

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

Authenticatieproblemen
Autorisatieproblemen
Agent-identiteitsproblemen
Debug-problemen
Randgevoelden in de taaklevenscyclus
Streaming-falen
Versiecompatibiliteit
Leverancierverschillen
Kostenverrassingen
Beveiligingsreviews
Auditvereisten
Menselijke goedkeuringsworkflows

Dit is waar veel agent-frameworks en protocollen falen. Ze zien 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 ondergaat op weg van demo naar deployment.

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

Het slechtste teken zou zijn als developers het alleen gebruiken in demos terwijl productiesystemen terugvallen op aangepaste API’s en queues.

Beveiliging is het grootste onopgeloste probleem

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 several 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 gebruikersintentie behouden?
Kan het bewijzen wat er is gebeurd?
Kan het worden geaudited nadat de taak is voltooid?

Deze vragen zijn niet optioneel in enterprise-omgevingen.

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

Bijvoorbeeld:

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

Dit is waarom serieuze A2A-systemen meer nodig hebben dan protocolcompliance.

Ze hebben nodig:

Sterke agent-identiteit
Gebiedsgebonden autorisatie
Taakgerichte auditlogs
Delegatie-tracking
Menselijke goedkeuring voor risicovolle acties
Artefactprovenance
Rate limits
Beleidshandhaving
Observability over agent-grenzen heen

A2A is geen beveiligingsarchitectuur op zich — het is een communicatieprotocol dat moet worden deployed binnen een, met expliciete beslissingen over identiteit, autorisatie, audit en beleidshandhaving op elke grens die het overschrijdt.

A2A en het idee van een agent-marktplaats

Een van de interessantere langetermijngebruikscases van A2A zijn agent-marktplaatsen.

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 modulair worden:

Een belastingagent
Een juridische agent
Een code review-agent
Een reisplanningsagent
Een beveiligingsanalyse-agent
Een inkoopagent
Een datakwaliteitsagent

Elke agent zou een standaardinterface kunnen tonen voor taakgebaseerde samenwerking.

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

Een open agent-marktplaats heeft meer nodig dan Agent Cards. Het heeft identiteit, reputatie, facturering, compliance, sandboxing, aansprakelijkheid, versioning en geschillenoplossing nodig.

Zonder die dingen wordt een agent-marktplaats een beveiligingsincident dat wacht om te gebeuren.

A2A is een nuttig bouwsteen voor deze toekomst, maar het is éé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 kortetermijngebruikscases zijn geen openbare agent-marktplaatsen.

Het zijn interne enterprise-agentnetwerken.

Grote organisaties hebben al veel grenzen:

Teams
Afdelingen
Systemen
Leveranciers
Datadomeinen
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 behandelt hoe specialistische agents zoals Hermes en OpenClaw in de praktijk passen in dit soort gelaagde architectuur.

In plaats van één grote 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 enkele allround-agent directe toegang geven tot elk systeem in de organisatie, zowel vanuit een beveiligingsperspectief als vanuit een operationeel perspectief. Elke specialistische agent kan onafhankelijk worden bezeten, beheerd, geaudited en beveiligd, wat het totale systeem ook gemakkelijker te doorzien maakt 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 tool-integratie belangrijk is.

Voeg A2A toe wanneer je daadwerkelijk hebt:

Meerdere onafhankelijke agents
Derde-partij agent-grenzen
Langlopende gedelegeerde taken
Agent discovery-vereisten
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 de complexiteit omarmt die het met zich meebrengt. 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 voldoende.

MCP wanneer de agent tools nodig heeft. Gebruik MCP wanneer je agent gestandaardiseerde toegang nodig heeft tot bestanden, databases, API’s, SaaS-systemen, zoekindices, repositories, interne documentatie of observability-systemen. MCP geeft directe 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 beveiligingsgrenzen hebben.

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

Veelgemaakte fouten met A2A

A2A gebruiken omdat het strategisch klinkt. Dit is de klassieke enterprise-architectuurval. A2A zou een echt grensprobleem moeten oplossen dat in de architectuur bestaat, niet één die is verzonnen om de protocolkeuze te rechtvaardigen. Als er geen echte grens is — geen onafhankelijke deployment, geen gescheiden eigendom, geen afzonderlijke 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 als een agent blootstellen. 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 eenvoudige tools, en de agent-abstractie voegt overhead toe zonder helderheid 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 tegenovergestelde 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 ingeklemd te worden achter een function call-grens.

Observability negeren. Multi-agent-systemen zonder traces zijn pijnlijk om te debuggen en onmogelijk om te auditen. Je moet weten welke agent de taak heeft ontvangen, welke berichten zijn uitgewisseld, welke tools zijn aangeroepen, welke artefacten zijn geproduceerd, welke beleid is toegepast en welke agent de finale beslissing heeft genomen. Zonder die zichtbaarheid wordt debuggen archeologie — het reconstrueren van wat er is gebeurd door inferentie in plaats van observatie. De volledige observability-stack voor AI- en LLM-gestuurde systemen, inclusief metrics, gedistribueerde traces en SLO’s die agent-grenzen overschrijden, wordt behandeld in Observability voor LLM-systemen: Metrics, traces, logs en testen in productie.

Is A2A dan overhypet?

Ja, deels. A2A is overhypet wanneer het wordt gepresenteerd als de onvermijdelijke standaard voor alle AI-agentsystemen, wanneer mensen suggereren 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 het protocolgesprek identiteit, autorisatie, observability en productieoperaties negeert. Dit zijn echte voorbeelden van hype die A2A universeeler laten klinken dan het is.

Maar overhypet betekent niet nutteloos. Veel belangrijke technologieën zijn overhypet voordat ze saai infrastructuur worden, en de hype komt vaak lang voordat het ecosysteem rijp genoeg is om het te ondersteunen. De echte vraag is niet of de marketing excessief is — dat is het 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 stakes.

Is A2A dan dood?

Nee.

Het argument “A2A is dood” had meer zin tijdens de vroege sceptische fase, 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 cloud-aandacht en gemelde productie-implementaties.

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

Is A2A dan eindelijk nuttig in 2026?

Ja, maar alleen in de juiste architectuur. A2A is nuttig wanneer je systeem echte agent-grenzen 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:

Discovery
Capaciteiten
Taaklevenscyclus
Berichten
Artefacten
Langlopend werk
Opaque implementatiegrenzen
Cross-vendor interoperabiliteit

Dat is waar A2A zijn plaats verdient, door een gemeenschappelijk contract voor samenwerking te bieden dat anders aangepast protocolwerk zou vereigen op elke grens.

Mijn opiniëerde mening

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

A2A kan belangrijker worden naarmate agentsystemen evolueren van demos naar enterprise-workflows. 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 agent-grenzen vanaf het begin te ontwerpen, en A2A alleen toe te voegen wanneer die grenzen echte deployment-, eigendoms- of interoperabiliteitsbeperkingen worden. Adopteer A2A niet voor de 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 rijpend protocol voor een specifiek probleem: communicatie tussen onafhankelijke AI-agents.

Als je een eenvoudige assistent bouwt, is A2A waarschijnlijk onnodig.

Als je een multi-agent enterprise-systeem, een agent-marktplaats, een vendor-neutrale agentnetwerk of een set onafhankelijk deployde specialistische agents bouwt, verdient A2A serieuze aandacht.

De beste 2026 framing is niet:

A2A vs MCP

Het is:

MCP voor tools.
A2A voor agents.
Beide voor serieuze multi-agent-systemen.

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