A2A und MCP sind zwei komplementäre offene Protokolle für KI-Agenten. MCP (Model Context Protocol, ursprünglich von Anthropic, November 2024) verbindet einen Agenten mit Werkzeugen, Daten und Kontext – das ist die Agent-zu-Tool-Ebene. A2A (Agent2Agent, ursprünglich von Google, April 2025) lässt eigenständige Agenten miteinander kooperieren – das ist die Agent-zu-Agent-Ebene. Sie konkurrieren nicht. Sie lösen unterschiedliche Probleme und werden in der Praxis gemeinsam eingesetzt.

Wer einmal verinnerlicht hat, dass es sich um zwei Schichten desselben Stacks handelt – nicht um zwei Lager in einem Standardkrieg – trifft schnell bessere Architekturentscheidungen.

• MCP gibt einem Agenten Werkzeuge. Es standardisiert, wie ein Agent eine Datenbank abfragt, ein CRM ausliest, eine Datei öffnet oder eine Web-Suche auslöst.
• A2A lässt Agenten zusammenarbeiten. Es standardisiert, wie ein Agent eine Aufgabe an einen anderen, eigenständigen Agenten delegiert – auch über System- und Anbietergrenzen hinweg.
• Beide ergänzen sich. Die offizielle Faustformel von Google, Salesforce und Microsoft lautet: „MCP ist für Capabilities (agent-to-tool). A2A ist für Collaboration (agent-to-agent)." IBM bestätigt nach dem Merge seines ACP-Projekts dieselbe Linie.

Das mentale Modell: Hände versus gemeinsame Sprache

Ein einprägsames Bild: MCP gibt einem Agenten Hände – die Fähigkeit, in der Außenwelt zu greifen, zu lesen und zu handeln. A2A gibt mehreren Agenten eine gemeinsame Sprache – die Fähigkeit, einander Aufträge zu erteilen und Ergebnisse zurückzugeben, ohne dass einer dem anderen seine Prompts, Modelle oder seinen Speicher offenlegen muss.

Der entscheidende konzeptionelle Zug bei A2A ist, dass die interne Logik des entfernten Agenten opak bleibt. A2A definiert, wie Agenten miteinander reden, nicht wie sie denken. Genau das erlaubt es einem Salesforce-Agenten, einen SAP-Agenten aufzurufen, ohne dass einer der beiden seine internen Prompts preisgeben muss. MCP dagegen exponiert ein Werkzeug mit einem klar beschriebenen Schema – hier ist Transparenz über die Fähigkeit gerade der Sinn der Sache.

Technischer Vergleich: Dimension, MCP und A2A

Beide Protokolle bauen auf JSON-RPC 2.0 auf und stehen unter dem Dach der Linux Foundation – das unterstreicht, dass sie als ein zusammengehöriger Stack gedacht sind.

MCP hatte 2025 eine regelrechte Adoptionsexplosion: OpenAI übernahm es im März 2025, Google DeepMind im April 2025, dazu Microsoft Copilot Studio, Cursor, Zed, Replit und viele mehr. A2A wird inzwischen von über 100 Unternehmen unterstützt; Gründungsmitglieder des Linux-Foundation-Projekts sind AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow.

Warum „komplementär" wörtlich gemeint ist

Es gibt eine technische Grauzone, die in Diskussionen oft für Verwirrung sorgt: Man kann einen Agenten als MCP-Server exponieren und ihn so für andere Agenten tool-förmig ansprechbar machen. Das funktioniert – aber es war nicht der Designzweck von MCP, und Anthropic, Google sowie Microsoft empfehlen für echte Peer-Kollaboration konsistent A2A.

Der Grund liegt in den Semantiken. MCP kennt einen Tool-Aufruf: Request rein, Response raus. A2A kennt einen vollständigen Task-Lebenszyklus mit Zwischenzuständen, der für langlaufende, eventuell rückfragende Kooperation gebaut ist – inklusive des Zustands input-required, wenn der entfernte Agent eine Klärung braucht. Wer Agent-zu-Agent über MCP nachbaut, verliert genau diese Mechanik.

Historisch gab es kurzzeitig ein drittes Protokoll, IBMs ACP (Agent Communication Protocol, März 2025). Es ist am 29. August 2025 unter LF AI & Data in A2A aufgegangen – die ACP-Designprinzipien (REST, async-default) leben in A2A weiter. Das verbleibende Bild für 2026 ist daher klar: MCP + A2A ist der konvergente Stack. AGNTCY (Cisco u. a.) ist eine Identitäts-, Discovery- und Observability-Schicht über A2A und MCP, kein Konkurrent. NANDA (MIT Media Lab) ist Forschung und gehört nicht in produktive Entscheidungen 2026.

Kombiniertes Beispiel: Schadensbearbeitung mit beiden Protokollen

Ein konkretes, vereinfachtes Beispiel macht das Zusammenspiel greifbar. Stellen Sie sich einen Versicherungs-Workflow vor – im Geist des dokumentierten Allianz-Projekts „Nemo", das sieben spezialisierte Agenten (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) einsetzt und einen Schadensfall in unter fünf Minuten durchläuft (mit Mensch-im-Loop für die finale Auszahlungsentscheidung).

Pseudocode aus Architektursicht:

```

A2A-Ebene: Orchestrator delegiert an spezialisierte Peer-Agenten

orchestrator.send_task(coverage_agent, task="Deckung prüfen für Fall #4711")
orchestrator.send_task(fraud_agent, task="Betrugsindikatoren prüfen #4711")
orchestrator.send_task(weather_agent, task="Unwetterdaten zum Schadensdatum")

Jeder Peer-Agent nutzt INTERN MCP, um an seine Werkzeuge zu kommen:

coverage_agent -> MCP-Server "Policendatenbank" (SQL-Lookup)

fraud_agent -> MCP-Server "Fraud-Scoring-API"

weather_agent -> MCP-Server "Wetterdienst-API"

A2A-Task-Lebenszyklus: submitted -> working -> completed

Ergebnisse kehren als A2A-Artefakte zurück, Orchestrator synthetisiert

```

Die Aufgabenverteilung zwischen den Agenten läuft über A2A – der Orchestrator weiß nicht und muss nicht wissen, welches Modell oder welcher Prompt im Fraud-Agenten steckt. Sobald aber ein einzelner Agent die Policendatenbank abfragt oder eine Wetter-API anspricht, läuft das über MCP. A2A koordiniert die Köpfe, MCP bedient die Hände. Genau diese saubere Trennung ist der Grund, warum die beiden Protokolle als komplementär gelten.

Zur Einordnung der Kosten- und Nutzendimension: Anthropics dokumentiertes Multi-Agenten-Forschungssystem (Lead-Modell plus parallele Sub-Agenten) erreichte intern +90,2 % auf Recherche-Breite gegenüber einem Einzel-Agenten – bei rund 15-fachem Token-Verbrauch. Multi-Agenten-Architektur (und damit A2A) lohnt sich also vor allem für parallelisierbare, breit gefächerte Aufgaben, nicht als Selbstzweck.

DACH-Realität: Komplementarität hat einen Compliance-Preis

Für DACH-B2B-Entscheider ist eine Konsequenz wichtig, die in US-zentrierten Referenzarchitekturen selten ehrlich benannt wird: Wenn Agenten über A2A bei unterschiedlichen Anbietern laufen und nebenbei MCP-Tool-Aufrufe absetzen, überschreitet der Datenfluss bei jeder Aufgabe mehrere Verarbeitungs- und ggf. Datenresidenz-Grenzen.

Jeder A2A-Hop und jeder MCP-Server ist potenziell ein eigener Auftragsverarbeiter im Sinne der DSGVO (Art. 28). Komplementarität auf Protokollebene bedeutet in der Praxis also eine längere AVV-Kette und – bei grenzüberschreitenden Hops – pro Sprung eine eigene Transfer-Frage (Art. 44–49). Wer eine hybride Salesforce-plus-SAP-plus-Microsoft-Landschaft betreibt, sollte diese Hops von Anfang an mit einer durchgängigen Trace-ID protokollieren und die AVV-Kette pro Agent dokumentieren.

Für Agenturen und B2B-Entscheider

Die praktische Empfehlung ist eindeutig: MCP für Werkzeuge, A2A für Agenten – alles andere ist 2026 eine bewusste Abweichung vom konvergenten Stack und braucht eine Begründung. Für DACH-Mittelständler heißt das konkret, zuerst MCP-Kompetenz aufzubauen (Sie werden ohnehin MCP-Server schreiben oder konsumieren) und A2A einzuführen, sobald Agenten über System- und Anbietergrenzen kooperieren müssen.

Für Agenturen und KI-nahe Produktanbieter ist der größte strategische Hebel, für jeden produktisierten Agenten eine AgentCard zu veröffentlichen. Damit kann ein Kundenbestand Ihren Agenten direkt aus Agentforce, Joule oder Copilot Studio per A2A aufrufen – ohne kostspielige Einzelintegration. Wer eine Multi-Agenten-Strategie für sein Unternehmen oder seine Kunden konzipieren will, sollte genau hier ansetzen: klare Protokolltrennung, dokumentierte AVV-Ketten und A2A-Auffindbarkeit von Tag eins an. Sprechen Sie uns an, wenn Sie diese Architektur für Ihren DACH-Kontext belastbar aufsetzen wollen.