Agent-to-Agent (A2A) Protocol

Was ist das Agent-to-Agent (A2A) Protocol?

Das Agent-to-Agent (A2A) Protocol ist ein offener Standard dafür, wie autonome AI Agents miteinander kommunizieren – über Prozess-, System-, Plattform- und Herstellergrenzen hinweg. Während ein einzelner Agent über das Model Context Protocol (MCP) auf Tools, Daten und externe Systeme zugreift, regelt A2A die Schicht darüber: die Zusammenarbeit zwischen eigenständigen Agents. Der zentrale konzeptionelle Schritt von A2A ist, dass es definiert, wie Agents sprechen, nicht wie sie denken. Die interne Logik eines entfernten Agents – seine Prompts, sein Modell, sein Speicher – bleibt opak. Genau das erlaubt es etwa einem Salesforce-Agent, einen SAP-Agent aufzurufen, ohne dass eine Seite ihre internen Strukturen offenlegt.

A2A wurde im April 2025 auf der Google Cloud Next mit über 50 Partnern vorgestellt und war zunächst Google-getrieben. Bereits am 23. Juni 2025 übergab Google die Spezifikation, die SDKs (Python, TypeScript) und das Entwickler-Tooling an die Linux Foundation. Damit ist A2A kein Vendor-Standard mehr, sondern ein herstellerneutral governter offener Standard – ein wesentliches Argument für Entscheider, die langfristige Plattformunabhängigkeit bewerten.

Agent-zu-Agent-Kommunikation: der technische Kern

A2A baut bewusst auf etablierten Web-Standards auf, um die Hürde für Unternehmen niedrig zu halten. Die wichtigsten Bausteine:

• Transport. JSON-RPC 2.0 über HTTPS. Streaming erfolgt über Server-Sent Events (SSE); für lang laufende Aufgaben sind optionale Push Notifications vorgesehen.
• Task-Lebenszyklus. Aufgaben durchlaufen definierte Zustände: submitted → working → input-required → completed | failed | canceled. Dieser explizite Lebenszyklus ist der vertragliche Kern zwischen zwei Agents – er macht klar, wann ein Agent auf eine Rückfrage wartet (input-required) und wann ein Ergebnis vorliegt.
• Messages und Artifacts. A2A unterstützt mehrteilige Nachrichten (Text plus multimodale Inhalte, etwa Formulare). Das Ergebnis einer Aufgabe sind ein oder mehrere Artifacts.
• Drei Interaktionsmodi. Synchron (einzelne Anfrage/Antwort), asynchrones Polling sowie Streaming/Push für lang laufende Tasks.

Diese Architektur erlaubt es, einen internen Multi-Agent-Flow (etwa eine LangGraph-Orchestrierung mit durablem State) nach außen als A2A-Endpoint mit einer AgentCard bereitzustellen – die interne und die externe Schicht komponieren sauber.

Agent Cards und Discovery

Das Herzstück der Auffindbarkeit (Discovery) in A2A ist die AgentCard. Jeder Agent veröffentlicht ein JSON-Dokument, das beschreibt:

• den Endpoint, über den der Agent erreichbar ist,
• seine Fähigkeiten (capabilities) und unterstützten Skills,
• die Modalitäten (Text, Formulare, multimodal),
• die unterstützten Authentifizierungsschemata.

Über die AgentCard findet ein aufrufender Agent heraus, was ein anderer Agent kann und wie er ihn ansprechen darf – ohne Innensicht auf dessen Implementierung. Für die Praxis ist die AgentCard damit der entscheidende Hebel: Veröffentlicht ein Anbieter für seine produktivierten Agents jeweils eine AgentCard, können Kundensysteme – Salesforce Agentforce, SAP Joule, Microsoft Copilot Studio – diese Agents aus der eigenen Umgebung heraus aufrufen, ohne eine kundenspezifische Integration zu bauen. Für DACH-AI-Agenturen ist das laut Research-Report 2026 einer der wichtigsten produktstrategischen Hebel überhaupt.

Ein offener Punkt für 2026: Es gibt kommerzielle Anreize einzelner Hersteller, AgentCards mit proprietären Erweiterungen zu versehen. Das zentrale Beobachtungssignal für die Portabilität von A2A ist daher, ob die AgentCard ein portables JSON-Dokument bleibt oder herstellerspezifisch wird.

A2A vs. MCP: komplementär, nicht konkurrierend

Die häufigste Frage von Tech-Leads im DACH-Raum lautet: „A2A oder MCP?" Die Antwort der maßgeblichen Anbieter (Google, Salesforce, Microsoft, IBM) ist eindeutig und konsistent: beides, für unterschiedliche Schichten. Die offizielle Formel lautet: „MCP ist für Fähigkeiten (agent-to-tool). A2A ist für Zusammenarbeit (agent-to-agent)." Microsofts eigene Multi-Agent-Leitlinie formuliert es operativ: „Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging."

MCP wird teilweise auch für Agent-zu-Agent genutzt, indem ein Agent als MCP-„Server" mit tool-förmigen Fähigkeiten exponiert wird. Das funktioniert, ist aber nicht die Auslegung von MCP – Anthropic, Google und Microsoft empfehlen für echte Peer-Kollaboration konsistent A2A. Im konvergenten Stack 2026 gilt damit: MCP als Standard für die Tool-Schicht, A2A als Standard für die Agent-Schicht.

Die Linux Foundation und die Konsolidierung der Protokolllandschaft

A2A steht im Zentrum einer bemerkenswerten Standardisierung. Bei der Übergabe an die Linux Foundation am 23. Juni 2025 (Open Source Summit North America, Denver) waren AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow Gründungsmitglieder; inzwischen unterstützen über 100 Unternehmen das Protokoll (Quelle: Linux Foundation, 2025). Repository und kanonische Dokumentation liegen unter github.com/a2aproject/A2A bzw. a2a-protocol.org.

Diese Bündelung hat die fragmentierte Protokolllandschaft konsolidiert:

• ACP → A2A. IBMs Agent Communication Protocol (ACP, März 2025) wurde am 29. August 2025 unter LF AI & Data in A2A überführt. Der offizielle LF-Blog: „the ACP team is winding down active development and contributing its technology and expertise to A2A." Die Design-Prinzipien von ACP (REST, async-by-default) leben in A2A weiter.
• AGNTCY als Overlay. Ciscos AGNTCY-Projekt (an die Linux Foundation gespendet am 29. Juli 2025, mit Dell, Google Cloud, Oracle und Red Hat als formativen Mitgliedern) ist kein Konkurrent zu A2A, sondern eine Schicht darüber für Discovery, Identität und Observability. Das Open Agent Schema Framework (OASF) nimmt A2A-AgentCards und MCP-Server-Beschreibungen explizit als Eingabeformate auf – „A2A agents and MCP servers are discoverable through AGNTCY directories."
• NANDA als Forschungsvision. Das MIT-Media-Lab-Projekt NANDA setzt konzeptionell auf MCP und A2A auf, ist 2026 aber überwiegend forschungsnah und keine Grundlage für produktive Architekturentscheidungen.

Der ehrliche Stand 2026: MCP plus A2A bilden den konvergenten Industriestandard, AGNTCY ist das rationale Add-on dort, wo herstellerübergreifende Identität zählt, NANDA bleibt Langfristvision.

A2A in der DACH-Praxis: Plattformen und Deployments

Für DACH-Unternehmen ist A2A das Inter-Agent-Protokoll, dem sie am häufigsten begegnen – weil ihre bestehenden Salesforce-, SAP-, Microsoft- und ServiceNow-Landschaften die Einstiegspunkte sind. Konkrete Beispiele aus dem Research-Report:

• SAP Joule Studio 2.0 / Joule Work (Sapphire 2026, GA Q4 2026): bidirektionales A2A, sodass Drittagenten nativ Joule-Agenten aufrufen können und umgekehrt. Für die SAP-lastige DACH-Landschaft ist das laut Report die wichtigste Multi-Agent-Plattformentwicklung 2026.
• Salesforce Agentforce 360 Multi-Agent Orchestration: A2A als herstellerübergreifender Handshake für die Delegation an Drittagenten; interne Übergaben laufen über die Atlas Reasoning Engine.
• Microsoft Agent 365 / Copilot Studio: A2A-Unterstützung in Work IQ seit April 2026.
• Google Agentspace und ServiceNow Now Assist: natives A2A bzw. A2A als plattformübergreifender Handshake.

Als dokumentiertes DACH-Flaggschiff nennt der Report Allianz Project Nemo – ein hierarchisches Sieben-Agenten-System (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) für Schadensfälle, das in unter 100 Tagen live ging und für berechtigte Fälle eine 80 % Reduktion der Bearbeitungs- und Regulierungszeit erzielte (Quelle: Allianz, 2025) – mit explizitem Human-in-the-Loop beim Auszahlungsschritt.

Compliance und Audit (informativ, keine Rechtsberatung)

Die folgenden Hinweise sind informativ und ersetzen keine Rechtsberatung. A2A-Ketten haben strukturelle Compliance-Folgen, die in US-zentrierten Referenzarchitekturen oft untergehen:

• DSGVO-AVV-Kette (Art. 28). Jeder Agent-Anbieter ist potenziell Auftragsverarbeiter; Multi-Agent verlängert die AVV-Kette. Jeder A2A-Hop ist potenziell eine eigene Verarbeiter-Beziehung mit eigenem Auftragsverarbeitungsvertrag.
• Grenzüberschreitende Übermittlung (Art. 44–49). Bei einem hybriden Salesforce-/SAP-/Microsoft-/Anthropic-Stack über US-EU-Clouds gilt: Sie führen nicht ein Transfer Impact Assessment durch, sondern eines pro grenzüberschreitendem Agent-zu-Agent-Hop. Standardvertragsklauseln (SCCs) und TIAs bleiben Pflicht.
• EU AI Act (high-level). Wer ist Provider, wer Deployer bei einer Salesforce-→-SAP-→-Anthropic-A2A-Komposition? Die vorsichtige Lesart: Jeder Hersteller ist Provider seines eigenen Agents, die integrierende Organisation ist Deployer des komponierten Systems. Diese Zuordnung ist 2026 noch nicht abschließend geklärt; entsprechende Aussagen sind als provisorisch zu betrachten, bis Durchführungsrechtsakte Klarheit schaffen.
• Audit-Trail. Jede A2A-Nachricht kann prüfungsrelevant sein. Empfohlen wird, eine durchgehende Trace-ID durch jeden A2A-Task und jeden MCP-Call zu propagieren, Modellversionen zu pinnen und genutzte AgentCards mitzuprotokollieren. Das Audit-Agent-Muster aus Allianz Project Nemo gilt als DACH-relevante Blaupause: Auditierbarkeit gehört in die Agent-Topologie, nicht nur in die Logging-Pipeline.

Ausblick und Praxis-Hinweis

A2A ist 2026 von einem Google-Standard zu einem herstellerneutral governten Linux-Foundation-Projekt mit über 100 Unterstützern gereift. Die strukturell stärkste Absicherung – die Linux-Foundation-Governance – steht offenen Fragen gegenüber: Ob A2A echte herstellerübergreifende Interoperabilität in Produktion erreicht oder durch proprietäre AgentCard-Erweiterungen fragmentiert, ist das zentrale Beobachtungssignal der kommenden Quartale.

Für die Praxis im DACH-Raum lautet die pragmatische Empfehlung: MCP für Tools, A2A für Agents – alles andere ist eine bewusste Abweichung vom konvergenten Stack und sollte begründet werden. Wer als Anbieter oder Deployer agiert, sollte AgentCards veröffentlichen, da sie der system­übergreifende Vertrag sind, der darüber entscheidet, ob ein Agent am Enterprise-Ökosystem 2026 teilnimmt. AGNTCY und NANDA verdienen einen Watchlist-Platz, gehören aber 2026 nicht auf den kritischen Pfad eines Multi-Agent-Programms. Die sinnvolle Einführungssequenz für Konzerne: zuerst MCP-Server-Policy standardisieren, dann A2A innerhalb einer Plattform einführen, anschließend auf eine zweite ausweiten, eine AgentCard-Registry aufbauen – und herstellerübergreifende Identität (AGNTCY) erst dann ergänzen, wenn das Volumen es rechtfertigt.