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. Insgesamt unterstützen über 150 Organisationen den Standard (Stand April 2026). Damit ist A2A der Quasi-Standard für plattformübergreifende Agent-Kollaboration.
• Wer macht (noch) nicht voll mit? OpenAI ist kein Gründungsmitglied. Im August 2025 erklärte ein OpenAI-Maintainer, es gebe keine unmittelbaren Pläne für A2A im Agents SDK. In der Agentic AI Foundation ist OpenAI Mitgründer und hat AGENTS.md eingebracht. Anthropic treibt primär MCP und nähert sich A2A über Bridge-Muster. Auch Gründungsmitglieder mit starkem eigenem Ökosystem, etwa Salesforce (Atlas) und Microsoft (Copilot-Studio-Handoffs), nutzen A2A bisher nur an der Außenkante und behalten die interne Orchestrierung für sich.
• Was ist das größte Risiko? Fragmentierung durch proprietäre AgentCard-Erweiterungen. Kein Vendor-Krieg, eher 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 überwiegend schon Produkt-Feature (Stand Oktober 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 bekommt bidirektionales A2A: Drittagenten sollen Joule-Agenten aufrufen können und umgekehrt. Die allgemeine Verfügbarkeit der A2A-Funktionen in Joule ist für Q4 2026 geplant. Agenten aus dem neuen Joule Studio, das SAP auf der Sapphire 2026 vorgestellt hat, sollen MCP und A2A nativ unterstützen. Anthropic Claude soll laut SAP zu einer primären Reasoning- und Agentenfähigkeit in Joule werden.
• Microsoft Copilot Studio und Microsoft Foundry (vormals Azure AI Foundry) haben A2A integriert.
• Google Gemini Enterprise, in dem Agentspace im Oktober 2025 aufgegangen ist, bindet externe Agenten über A2A ein.
• ServiceNow Now Assist nutzt A2A ebenfalls, und die AWS Bedrock AgentCore Runtime hostet A2A-Server.

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. Wir nennen das Marketing-Multi-Agent. 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, kann der Datenfluss einer einzigen Aufgabe mehrere Verarbeiter- und Residenz-Grenzen überqueren. Nach Art. 28 DSGVO wird die Auftragsverarbeitungskette dadurch länger. Übermittelt ein Hop personenbezogene Daten in ein Drittland, greifen zusätzlich die Art. 44–49 DSGVO: Fehlt für das Zielland ein Angemessenheitsbeschluss nach Art. 45, braucht dieser Hop eine eigene Transfer-Prüfung. Hops innerhalb von EU und EWR lösen keine Transfer-Prüfung aus. 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 ein Forschungsprojekt: eine Langfrist-Vision für eine dezentrale Agenten-Identität, kein produktiv eingesetztes Protokoll in DACH-Stacks (Stand 2026).

Unsere Einordnung für Architekturentscheidungen 2026: 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 aus unserer Sicht der wahrscheinlichste Stand 2027. AgentCard bleibt 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. Zwischen A und B entscheidet eine offene Frage: Liefern SAP Joule, Agentforce und Copilot Studio bis Ende 2026 echtes Cross-Vendor-A2A produktiv, oder bleibt die Zahl produktiver Multi-Agent-Einsätze im gesamten DAX 40 einstellig?

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

Jeder A2A-Hop, der personenbezogene Daten an einen weiteren Dienstleister gibt, ist ein zusätzliches Glied in der AVV-Kette. Führt ein Hop außerdem in ein Drittland ohne Angemessenheitsbeschluss, braucht er eine eigene Transfer-Prüfung. Das Beispiel oben hat zwei Hops: zwei zusätzliche Glieder in der AVV-Kette und, wenn beide in solche Drittländer führen, zwei Transfer-Impact-Assessments. Bleiben alle Verarbeiter in der EU oder im EWR, entfällt die Transfer-Prüfung, die längere Kette bleibt. Diese Rechnung wird im Multi-Agent-Design leicht übersehen. 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: Behandle 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. Verankere in Beschaffungsverträgen die Frage: Garantiert der Agentforce-, Joule- oder Copilot-Studio-Vertrag A2A-Interoperabilität und MCP-Standardtreue, und was passiert beim Exit? Halte 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öffentliche für jeden produktisierten Agenten eine AgentCard, damit Kunden-Bestände deine 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. Sprich mit uns, bevor du dich 24 Monate im Voraus auf ein Tool festlegst. Die Richtung steht, die Spezifika bewegen sich.