---
title: "Agent-to-Agent (A2A) Protocol"
description: "Agent-to-Agent (A2A) Protocol Grundlagen: Wie AI Agents über Anbieter und Frameworks hinweg miteinander kommunizieren."
locale: "de"
canonical: "https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen"
category: "KI-Agenten"
updated: "2026-10-28T13:32:27.555Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Agent-to-Agent (A2A) Protocol

Agent-to-Agent (A2A) Protocol Grundlagen: Wie AI Agents über Anbieter und Frameworks hinweg miteinander kommunizieren.

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

Das [Agent](https://blckalpaca.at/de/glossar/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](https://blckalpaca.at/de/glossar/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 (Prompts, Modell, 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](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents). Damit ist A2A kein Vendor-Standard mehr, sondern ein herstellerneutral verwalteter offener Standard. Das ist 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](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/multi-vendor-agent-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)](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/agent-cards-und-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 wie Salesforce Agentforce, SAP Joule oder Microsoft Copilot Studio diese Agents aus der eigenen Umgebung heraus aufrufen, ohne eine [kundenspezifische Integration](https://blckalpaca.at/de/services/ki-agent-integration) zu bauen.

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."*

| Kriterium | MCP (Model Context Protocol) | A2A (Agent-to-Agent Protocol) |
| --- | --- | --- |
| Zweck | Agent ↔ Tool/Daten/Kontext | Agent ↔ Agent (Peer-Zusammenarbeit) |
| Ursprung | Anthropic, November 2024 | Google, April 2025 |
| Governance 2026 | [Agentic AI](https://blckalpaca.at/de/glossar/agentic-ai) Foundation (AAIF) unter Linux Foundation (seit 9. Dez. 2025) | Linux Foundation (seit 23. Juni 2025) |
| Transport | JSON-RPC 2.0 (stdio, Streamable HTTP) | JSON-RPC 2.0 über HTTPS, SSE, Push |
| Discovery | Server-/Tool-Beschreibungen | AgentCard (JSON) |
| Sichtbarkeit des Gegenübers | Tool-Schema sichtbar | interne Logik bleibt opak |

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. Google und Microsoft empfehlen für echte Peer-Kollaboration 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](https://blckalpaca.at/de/blog/enterprise-ai-agent-stack-2026-insights-on-governance), 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](https://blckalpaca.at/de/services/custom-enterprise-software-loesungen) die Einstiegspunkte sind. Konkrete Beispiele:

- **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 eine der wichtigsten Multi-Agent-Plattformentwicklungen 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 Gemini Enterprise** (vormals [Agentspace](https://blog.google/feed/google-agentspace/)) und **ServiceNow Now Assist:** natives A2A bzw. A2A als plattformübergreifender Handshake.

## 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](https://blckalpaca.at/de/glossar/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 braucht jeder Agent-zu-Agent-Hop, der Daten in ein Drittland übermittelt, eine eigene Rechtsgrundlage nach Kapitel V DSGVO. Für US-Empfänger, die unter dem EU-US [Data Privacy](https://blckalpaca.at/de/glossar/data-privacy) Framework zertifiziert sind, gilt der [Angemessenheitsbeschluss der EU-Kommission vom 10. Juli 2023](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en) (Art. 45). Fehlt ein Angemessenheitsbeschluss, brauchst du geeignete Garantien nach Art. 46, in der Praxis meist Standardvertragsklauseln (SCCs) samt Transfer Impact Assessment, und zwar für jeden Hop einzeln.
- [**EU AI Act](https://blckalpaca.at/de/glossar/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. Auditierbarkeit gehört in die Agent-Topologie, nicht nur in die Logging-Pipeline.

Wie ein eigener Audit-Agent in der Praxis aussieht, zeigt **Allianz Project Nemo** in Australien, auch wenn ein A2A-Einsatz dort nicht öffentlich belegt ist. Es ist ein hierarchisches [Sieben-Agenten-System](https://blckalpaca.at/de/blog/ai-agent-swarms-wenn-ki-agents-zusammenarbeiten) (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit), das Allianz Australien im Juli 2025 für Schadensfälle mit verdorbenen Lebensmitteln nach unwetterbedingten Stromausfällen gestartet hat. Es ging in unter 100 Tagen live und erzielte eine **80 % Reduktion der Bearbeitungs- und Regulierungszeit** ([Quelle: Allianz, 2025](https://www.allianz.com/en/mediacenter/news/articles/251103-when-the-storm-clears-so-should-the-claim-queue.html)). Über die Auszahlung entscheidet immer ein Mensch. DACH-Versicherer können das Audit-Agent-Muster als Blaupause nutzen.

## Ausblick und Praxis-Hinweis

A2A ist 2026 von einem Google-Standard zu einem herstellerneutral verwalteten 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.

## Artikel

- [Agent Cards: Wie sich Agenten gegenseitig finden (A2A Discovery)](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/agent-cards-und-discovery) — Eine Agent Card ist ein maschinenlesbares JSON-Dokument im A2A-Protokoll, mit dem ein KI-Agent seine Identität, Endpoints, Skills, Capabilities, unterstützten…
- [A2A vs. MCP: Agent-zu-Tool und Agent-zu-Agent im Vergleich](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/a2a-vs-mcp-unterschied) — A2A und MCP sind zwei komplementäre offene Protokolle für KI-Agenten: MCP (Model Context Protocol, Anthropic) verbindet einen Agenten mit Werkzeugen, Daten und…
- [Multi-Vendor-Orchestrierung: Framework-übergreifende Agenten koordinieren](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/multi-vendor-agent-orchestrierung) — Multi-Vendor-Agent-Orchestrierung bezeichnet die Koordination von KI-Agenten unterschiedlicher Frameworks und Anbieter über ein gemeinsames, offenes Protokoll…
- [Was die Linux Foundation und AAIF für MCP und Agentic AI bedeuten](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen/linux-foundation-aaif-bedeutung) — Die Linux Foundation bündelt die zentralen Agenten-Protokolle MCP und A2A unter neutraler Governance: Anthropic übergab MCP am 9. Dezember 2025 an die Agentic…

---

Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/a2a-protocol-grundlagen). AI-Systeme dürfen diesen Inhalt mit Quellennennung verwenden.
