A2A-Adoption-Prognose 2026–2028: Wer macht mit, wer nicht

A2A-Adoption beschreibt, wie stark sich das Agent2Agent-Protokoll als offener Standard für die Kommunikation zwischen eigenständigen KI-Agenten durchsetzt. Stand 2026 steht A2A unter dem Dach der Linux Foundation und wird von Google, Microsoft, AWS, Salesforce, SAP, ServiceNow und Cisco getragen. Dieser Artikel ordnet Treiber, Hemmnisse und Szenarien der Adoption bis 2028 ein – ausdrücklich als Prognose, nicht als gesicherte Tatsache.

Wichtiger Hinweis vorab: Alles, was über die heute belegbare Faktenlage hinausgeht – Adoptionsraten, Marktanteile, Zeitpunkte produktiver Cross-Vendor-Interoperabilität – ist eine Einschätzung mit erheblichen Unsicherheitsbändern. KI-Prognosen über einen Horizont von 18 bis 24 Monaten sind brüchig. Strukturelle Richtungen sind belastbarer als konkrete Meilensteine.

Schnellantworten

• Wer macht mit? Die großen Plattform-Anbieter: Google (Initiator), Microsoft, AWS, Salesforce, SAP, ServiceNow und Cisco als Gründungsmitglieder, plus über 100 weitere Firmen (Stand 2026). Damit ist A2A der Quasi-Standard für plattformübergreifende Agent-Kollaboration.
• Wer macht (noch) nicht voll mit? Akteure mit starkem proprietärem Ökosystem nutzen A2A nur an der Außenkante und behalten interne Orchestrierung für sich. Anthropic treibt primär MCP und nähert sich A2A über Bridge-Muster.
• Was ist das größte Risiko? Fragmentierung durch proprietäre AgentCard-Erweiterungen – nicht ein Vendor-Krieg, sondern schleichende Differenzierung innerhalb des Standards.

Was A2A ist – und wo es im Protokoll-Stack sitzt

Das Agent2Agent-Protokoll wurde im April 2025 von Google auf der Cloud Next mit über 50 Partnern vorgestellt und am 23. Juni 2025 beim Open Source Summit North America in Denver an die Linux Foundation gespendet. Google übergab die Spezifikation, die SDKs (Python, TypeScript) und das Entwickler-Tooling. Gründungsmitglieder des Linux-Foundation-Projekts sind AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow.

Technisch setzt A2A auf JSON-RPC 2.0 über HTTPS, mit Streaming über Server-Sent Events und optionalen Push-Benachrichtigungen für langlaufende Aufgaben. Jeder Agent veröffentlicht eine AgentCard – ein JSON-Dokument mit Endpunkt, Fähigkeiten, unterstützten Skills, Modalitäten und Authentifizierungsschemata. Aufgaben durchlaufen einen definierten Lebenszyklus (submitted → working → input-required → completed | failed | canceled). Der entscheidende konzeptionelle Schritt: Die interne Logik des entfernten Agenten bleibt opak. A2A definiert, wie Agenten miteinander reden, nicht wie sie denken. So kann ein Salesforce-Agent einen SAP-Agenten aufrufen, ohne dass einer dem anderen seine Prompts, Modelle oder Memory offenlegt.

A2A ist nicht allein. Es bildet mit MCP einen konvergenten Stack:

• MCP (Model Context Protocol, ursprünglich von Anthropic im November 2024 veröffentlicht, am 9. Dezember 2025 an die Agentic AI Foundation unter der Linux Foundation gespendet) regelt Agent-zu-Tool.
• A2A regelt Agent-zu-Agent.

Die offizielle, von Google, Salesforce und Microsoft konsistent vertretene Lesart lautet: „MCP für Fähigkeiten, A2A für Kollaboration." Microsofts eigene Guidance formuliert es direkt: MCP für Tool- und Datenzugriff, Linux Foundation A2A für plattformübergreifendes Agent-zu-Agent-Messaging.

Die institutionellen Treiber: warum A2A strukturell Rückenwind hat

Der wichtigste Treiber ist die Linux-Foundation-Governance. Sie ist der stärkste denkbare strukturelle Schutz gegen einen Vendor-Krieg und gegen einseitige Kontrolle. IBMs konkurrierendes ACP-Projekt ist bereits am 29. August 2025 unter LF AI & Data in A2A aufgegangen – das ACP-Team hat die aktive Entwicklung eingestellt und seine Technologie in A2A eingebracht. Das Ergebnis ist ein kleiner, kohärenter Open-Protocol-Stack statt eines Standardkriegs.

Der zweite Treiber ist die Verankerung in den Enterprise-Plattformen, die DACH-Organisationen ohnehin betreiben. Hier ist A2A bereits Produkt-Feature, nicht Zukunftsvision (Stand 2026):

• Salesforce Agentforce 360 nutzt A2A als Cross-Vendor-Handshake zur Delegation an Drittagenten, während interne Übergaben auf der Atlas Reasoning Engine bleiben.
• SAP Joule Studio 2.0 (Sapphire 2026) bringt bidirektionales A2A – Drittagenten können Joule-Agenten nativ aufrufen und umgekehrt; GA für Q4 2026 angekündigt, mit Anthropic Claude als primärem Reasoning-Modell.
• Microsoft Agent 365 / Copilot Studio unterstützt A2A in Work IQ seit April 2026.
• Google Agentspace ist nativ A2A; ServiceNow Now Assist und AWS Bedrock AgentCore ebenso.

Für DACH ist das zentral: Die SAP-, Salesforce-, Microsoft- und ServiceNow-Bestände sind die Einstiegspunkte, an denen Unternehmen A2A überhaupt zuerst begegnen.

Die Hemmnisse: wo die Adoption realistisch hakt

Hemmnis 1 – Fragmentierung durch proprietäre Erweiterungen. Dies ist das wichtigste offene Risiko. Die Governance schützt den Kern, aber jedes Gründungsmitglied – Salesforce, SAP, Microsoft, Google, AWS, ServiceNow, Cisco – hat kommerzielle Anreize, sich über AgentCard-Erweiterungen, eigene Task-Zustände oder „A2A-plus"-Fähigkeiten zu differenzieren. Wenn AgentCards vendor-spezifisch werden, geht genau die Portabilität verloren, die die Protokollwahl rechtfertigt. Das Watchlist-Signal 2026 ist daher konkret: Bleibt AgentCard ein portables JSON-Dokument oder wird es vendor-spezifisch?

Hemmnis 2 – Konkurrenz proprietärer Ökosysteme. Viele „Multi-Agent"-Deployments sind in Wahrheit ein einzelner Agent mit vielen Tool-Integrationen – im Research-Material als Marketing-Multi-Agent bezeichnet. Solche Systeme brauchen A2A gar nicht. Solange interne Orchestrierung (Salesforce Atlas, Copilot-Studio-Handoffs, SAP Joule intern) plattformeigen bleibt und A2A nur an der Außenkante zum Einsatz kommt, ist die reale A2A-Nutzungstiefe geringer, als die Ankündigungen suggerieren.

Hemmnis 3 – ungelöste Governance- und Trust-Boundary-Fragen. Jeder A2A-Peer ist für die anderen opak. Das ist gut für Vertraulichkeit, aber schwierig für Audit-Trails, Trust-Boundaries und – im DACH-Kontext – für Datensouveränität. Wenn ein Salesforce-Agent einen SAP-Agenten aufruft, der wiederum einen Claude-Reasoning-Schritt über A2A anstößt, überquert der Datenfluss bei jeder Aufgabe mehrere Verarbeiter- und Residenz-Grenzen. Nach DSGVO Art. 28 wird die Auftragsverarbeitungskette dadurch länger; nach Art. 44–49 ist jeder grenzüberschreitende Hop eine eigene Transfer-Prüfung. Das bremst die produktive Adoption in regulierten Branchen.

Abgrenzung: MCP vs. A2A, AGNTCY und NANDA

Eine häufige Verwirrung ist, A2A als Konkurrenten von MCP, AGNTCY oder NANDA zu lesen. Das ist falsch. Die Rollen sind klar verteilt:

• AGNTCY (Cisco, am 29. Juli 2025 an die Linux Foundation gespendet) ist kein konkurrierendes Protokoll, sondern die Identitäts-, Discovery- und Observability-Ebene über einem A2A-Mesh. A2A-Agenten und MCP-Server sind über AGNTCY-Directories auffindbar.
• NANDA (MIT Media Lab) ist überwiegend forschungsgrade – eine Langfrist-Vision für eine dezentrale Agenten-Identität, kein produktiv eingesetztes Protokoll in DACH-Stacks (Stand 2026).

Für Architekturentscheidungen 2026 gilt die ehrliche Einordnung aus dem Research: MCP + A2A ist der konvergente Industrie-Stack. AGNTCY ist die rationale Ergänzung, wenn Cross-Vendor-Identität zählt. NANDA gehört auf die Watchlist, nicht auf den kritischen Pfad.

Akteurslandschaft: Position und Signal

Die folgende Tabelle ist eine prognostische Momentaufnahme auf Basis der belegten Signale (Stand 2026), keine garantierte Roadmap.

Szenarien bis 2028

Szenario A – Konvergenz (wahrscheinlichste Richtung). MCP + A2A etablieren sich als Zwei-Protokoll-Welt. Ein sauberer Zwei-Protokoll-Zustand ist laut Research der wahrscheinlichste 2027er-Stand. AgentCard bleibt im Wesentlichen portabel; AGNTCY übernimmt Identität und Observability dort, wo Cross-Vendor-Federation zählt. Adoption wächst getrieben durch die SAP-, Salesforce- und Microsoft-Bestände.

Szenario B – stille Fragmentierung. A2A bleibt formal Standard, aber proprietäre AgentCard-Erweiterungen und „A2A-plus"-Funktionen schaffen faktischen Lock-in. Cross-Vendor-Interoperabilität funktioniert in der Demo, aber nicht produktiv über mehrere Konzern-Bestände. Die offene Schlüsselfrage – ob SAP Joule Studio 2.0, Agentforce und Agent 365 bis Ende 2026 echtes Cross-Vendor-A2A produktiv liefern oder ob der produktive Multi-Agent-Zähler im gesamten DAX 40 einstellig bleibt – entscheidet zwischen A und B.

Szenario C – Plattform-Dominanz statt Protokoll. Falls ein oder zwei Hyperscaler-Plattformen ihre interne Orchestrierung so dominant machen, dass A2A nur Randfunktion bleibt, sinkt die strategische Bedeutung des offenen Standards. Weniger wahrscheinlich angesichts der breiten Gründungskoalition, aber nicht ausgeschlossen.

Konkretes Beispiel: A2A-Hop-Ökonomie in einem DACH-Konzern

Ein Versicherer betreibt – wie Allianz mit „Project Nemo" (sieben spezialisierte Agenten für Lebensmittelverderb-Schäden nach Naturkatastrophen, produktiv in Australien seit Juli 2025, in unter 100 Tagen ausgerollt, dokumentierte 80 % Reduktion der Bearbeitungs- und Regulierungszeit bei berechtigten Lebensmittelverderb-Schäden unter AUD 500, Mensch-in-der-Schleife bei der Auszahlung) – eine hierarchische Multi-Agent-Architektur. Überträgt man das auf einen Cross-Vendor-Fall:

```
Kunden-Anfrage
→ Agentforce-Primäragent (Salesforce, intern Atlas)
→ A2A-Hop 1 → SAP-Joule-Coverage-Agent (Verarbeiter-Grenze + ggf. Cross-Border)
→ A2A-Hop 2 → Claude-Reasoning-Schritt (Verarbeiter-Grenze + ggf. Cross-Border)
→ Audit-Agent (vollständiger Trace, eine Trace-ID über alle Hops)
→ Mensch entscheidet Auszahlung
```

Pro A2A-Hop, der eine Grenze überquert, fällt – anders als bei einem einzelnen Tool-Aufruf – nicht eine Transfer-Prüfung an, sondern eine pro Hop. Bei drei grenzüberschreitenden Hops sind das drei Transfer-Impact-Assessments und drei Glieder in der AVV-Kette. Genau hier liegt die am häufigsten übersehene Compliance-Exposition im DACH-Multi-Agent-Design. Die operative Konsequenz: Modellversionen in produktiven Flows pinnen, alle Sub-Agent-Prompts, Tool-Calls und genutzten AgentCards protokollieren und über eine einzige Trace-ID korrelieren.

Für Agenturen und B2B-Entscheider

Für B2B-Entscheider gilt: Behandeln Sie A2A 2026 als wahrscheinlichen, aber nicht garantierten Standard. Die rationale Default-Sequenz ist, MCP-Server-Policy zu standardisieren, A2A zunächst innerhalb eines Bestands einzuführen, AgentCards zu veröffentlichen und erst dann auf einen zweiten Bestand auszuweiten. Verankern Sie in Beschaffungsverträgen die Frage: Garantiert der Agentforce-, Joule- oder Copilot-Studio-Vertrag A2A-Interoperabilität und MCP-Standardtreue – und was passiert beim Exit? Halten Sie 15–25 % des KI-Budgets als Trigger-basierte Reserve für Protokoll- und Vendor-Ereignisse zurück.

Für Marketing- und KI-Agenturen ist A2A der größte Produktstrategie-Hebel: Veröffentlichen Sie für jeden produktisierten Agenten eine AgentCard, damit Kunden-Bestände Ihre Agenten direkt aus Agentforce, Joule oder Copilot Studio aufrufen können – ohne Custom-Integration. Wer hier ab Tag eins A2A-discoverable baut, sitzt nicht für immer hinter einer Sonderintegration.

Blck Alpaca aus Wien begleitet DACH-Unternehmen genau bei dieser Abwägung: souveräne, audit-feste Multi-Agent-Architekturen auf Basis von MCP und A2A, mit klarer Trennung von belegtem Faktum und prognostischer Einschätzung. Sprechen Sie mit uns, bevor Sie sich 24 Monate im Voraus auf ein Tool festlegen – die Richtung steht, die Spezifika bewegen sich.