A2A vs MCP: Wahl des richtigen Protokolls für die Agent-Kommunikation

Die meisten Produktions-Agentensysteme benötigen zwei Protokolle, nicht eines. Das Model Context Protocol (MCP) gibt einem Agenten Zugriff auf Tools und Datenquellen — NetSuite-Datensätze, HubSpot-Kontakte, Lieferantenkataloge, Redshift-Abfragen. Das Agent2Agent Protocol (A2A) gibt Agenten eine Möglichkeit, Arbeit an andere Agenten zu delegieren — ein Angebotsagent, der einen Katalogagenten nach Ersatzteilen fragt, ein Beschaffungsagent, der einen Compliance-Agenten bittet, eine GMP-Zertifizierung zu überprüfen. Die Verwechslung der beiden führt zu fragilen Architekturen: A2A für den Aufruf einer Datenbank oder MCP zur Koordination zweier unabhängiger Agenten erzeugt Systeme, die gegen das Design ihres eigenen Protokolls arbeiten.

Am 1. August 2026 bestätigte OpenAI Astra — seine nächste große Modellfamilie, explizit für langlaufende Multi-Agenten-Aufgaben konzipiert, die über Stunden oder Tage an Problemen arbeiten. Eine interne Version löste zehn zuvor ungelöste offene Probleme in Mathematik und theoretischer Informatik, mit Gesamtkosten von etwa 2.000 $ an Token. Astra koordiniert mehrere Agenten über längere Zeiträume — genau das Muster, in dem A2A (Agent-zu-Agent-Delegation) und MCP (Agent-zu-Tool-Zugriff) zusammenarbeiten müssen. Die Modellschicht wird nun für das Zwei-Protokoll-Muster gebaut.

Dieser Artikel ist ein Entscheidungsrahmen für Teams, die zwischen A2A und MCP wählen — oder, häufiger, entscheiden, wo jedes in einem Multi-Agenten-System hingehört. Er setzt voraus, dass Sie die Grundlagen jedes Protokolls verstehen. Wenn Sie einen Integrations-Leitfaden benötigen, decken die A2A Hermes Agent-Brücke und der MCP + A2A Protokoll-Stack-Überblick die Implementierungsseite ab.

Die Unterscheidung in einer Zeile

MCP verbindet einen Agenten mit Tools. A2A verbindet Agenten mit Agenten. MCP ist ein Tool-Aufruf-Protokoll — ein Agent fordert eine Ressource an oder ruft eine Funktion auf, und ein Server antwortet mit strukturierten Daten. A2A ist ein Aufgaben-Delegations-Protokoll — ein Agent sendet eine Arbeitseinheit an einen anderen Agenten, empfängt Streaming-Ausgabe und verfolgt die Aufgabe über eine Zustandsmaschine. Das Produktionsmuster, bestätigt über 150+ A2A-Organisationen und 10.000+ MCP-Server, ist: A2A zwischen Agenten, MCP zwischen Agenten und Tools.

Wo jedes Protokoll hingehört

Dimension	MCP	A2A
Was es verbindet	Agent → Tool, Datenquelle, API	Agent → Agent
Arbeitseinheit	Tool-Aufruf (Anfrage/Antwort)	Aufgabe (zustandsbehafteter Lebenszyklus)
Protokollkörper	Anthropic (offene Spec, 2026-07-28 final)	Google (offene Spec, Linux Foundation, 150+ Organisationen)
Transport	STDIO, Streamable HTTP (SSE verworfen, 12-Monate-Sunset)	JSON-RPC 2.0 über HTTP, SSE-Streaming
Entdeckung	Server registriert Tools; Client entdeckt	Agent Card unter /.well-known/agent-card.json
Zustand	Zustandslos (Spec 2026-07-28); Zustand lebt im Client	Zustandsbehaftete Aufgabenmaschine: submitted → working → input-required → completed/failed/canceled
Streaming	Tool-Ergebnisse sind einzelne Antworten	message/stream für Echtzeit-Token- und Artefakt-Lieferung
Human-in-the-Loop	Kein Konzept erster Klasse	INPUT_REQUIRED ist ein Aufgabenstatus erster Klasse
Authentifizierung	Pro Server; OAuth 2.1 in Spec, Bearer-Token in Praxis	Pro Agent; Agent Card deklariert Auth-Schemata, Gateway handhabt Durchsetzung
Adoption	10.000+ Server, 4 Tier-1-SDKs (TypeScript, Python, Go, C#)	150+ Organisationen, Linux-Foundation-Governance

Die Tabelle beantwortet die erste Frage, die die meisten Teams stellen: Wenn Ihre Integration "ein Agent muss NetSuite nach einem Kundendatensatz abfragen" lautet, ist das MCP. Wenn Ihre Integration "ein Beschaffungsagent einen Preisagenten bittet, drei Lieferantenangebote zu bewerten und eine Empfehlung zurückzugeben" lautet, ist das A2A. Die Unterscheidung ist, ob die Sache am anderen Ende eigenes Denken hat oder ob es eine Datenquelle ist, die auf eine strukturierte Abfrage antwortet.

Die fünf Fragen, die die Aufteilung bestimmen

1. Denkt die andere Seite oder antwortet sie?

Ein NetSuite MCP-Server denkt nicht. Er empfängt einen Tool-Aufruf (get_customer, search_items), fragt die API ab und gibt strukturiertes JSON zurück. Der Agent, der ihn aufgerufen hat, denkt. Ein A2A-Preisagent denkt — er empfängt eine Aufgabe ("bewerten Sie diese drei Angebote gegen historische Preissetzung und Lieferantenzuverlässigkeit"), führt seine eigene Modellinferenz aus, kann eigene MCP-Tools aufrufen und gibt eine Empfehlung mit angehängtem Denkprozess zurück.

Wenn die andere Seite eine Datenquelle oder API ist, verwenden Sie MCP. Wenn die andere Seite ein autonomer Agent mit eigenem Modell, eigenen Tools und eigener Entscheidungsfindung ist, verwenden Sie A2A. Der praktische Test: Hat das Ding, das Sie aufrufen, einen eigenen Prompt? Wenn ja, A2A. Wenn nein, MCP.

2. Benötigen Sie Streaming-Ausgabe?

MCP-Tool-Aufrufe sind Anfrage/Antwort. Der Server verarbeitet die Anfrage und gibt ein einzelnes Ergebnis zurück. Es gibt keinen Zwischenzustand, kein Token-für-Token-Streaming, keine teilweisen Artefakte. Das ist in Ordnung für das Abfragen einer Datenbank oder das Abrufen eines Datensatzes — Sie wollen das vollständige Ergebnis, keinen Strom von Fragmenten.

A2A unterstützt message/stream, das Token-Deltas und Artefakte bei ihrer Erstellung liefert. Ein Preisagent, der 30 Sekunden braucht, um drei Angebote zu bewerten, kann sein Denken während der Arbeit streamen, sodass der aufrufende Agent (und der beobachtende Mensch) den Fortschritt sehen, Fehler früh erkennen und abbrechen kann, wenn das Denken abdriftet. Wenn Ihr Workflow im Laufe der Zeit Ausgaben produziert und Sie auf Teilergebnisse reagieren müssen, ist A2A das Protokoll, das dies nativ unterstützt.

3. Gibt es eine menschliche Genehmigungsschwelle?

MCP hat kein Konzept erster Klasse für Human-in-the-Loop. Sie können Genehmigungslogik in den Agenten einbauen, der MCP-Tools aufruft — der Agent pausiert, fragt einen Menschen und fährt dann fort — aber das Protokoll selbst codiert dies nicht. Der Genehmigungsstatus lebt in Ihrem Anwendungscode, nicht im Protokoll.

A2A definiert INPUT_REQUIRED als Aufgabenstatus erster Klasse. Wenn ein Agent eine Entscheidung erreicht, die menschliche Genehmigung erfordert — eine Kaufautorisierung, eine Angebotsgenehmigung, eine Datenzugriffsentscheidung — überführt er die Aufgabe in INPUT_REQUIRED. Der aufrufende Agent (oder der menschliche Operator dahinter) sieht einen Standard-Protokollstatus, kein frameworkspezifisches Detail. Wenn der Mensch antwortet, wird die Aufgabe fortgesetzt. Wenn Ihr Workflow Genehmigungsschwellen enthält, die Agent-Grenzen überschreiten, transportiert A2A diese Schwellen transparent. Die Hermes Agent A2A-Brücke bildet die nativen Genehmigungsanforderungen von Hermes auf den INPUT_REQUIRED-Status von A2A ab, sodass eine Agent-Delegationskette einen menschlichen Prüfpunkt enthalten kann, unabhängig davon, auf welchem Framework jeder Agent läuft.

4. Wie lange dauert die Arbeit?

MCP-Tool-Aufrufe sind für kurze, synchrone Operationen konzipiert — eine API abfragen, einen Datensatz abrufen, eine Berechnung ausführen. Die Spec 2026-07-28 machte MCP explizit zustandslos, was bedeutet, dass der Server den Konversationskontext zwischen Aufrufen nicht aufrechterhält. Der Zustand lebt im Client (dem Agenten), nicht im Server. Das ist das richtige Design für Tools: Ein NetSuite-Server sollte sich nicht daran erinnern, dass Sie vor fünf Minuten einen Kunden abgefragt haben.

A2A-Aufgaben sind für längerlaufende Arbeit mit expliziter Lebenszyklusverwaltung konzipiert. Eine Aufgabe durchläuft submitted → working → completed (oder failed, canceled, input-required). Die Zustandsmaschine ist Teil des Protokolls. Eine Preisbewertung, die zwei Minuten dauert, eine Compliance-Prüfung, die eine Stunde dauert, oder eine Multi-Agenten-Forschungsaufgabe, die einen Tag dauert — diese passen zum Aufgabenmodell von A2A. OpenAIs Astra, am 1. August bestätigt, ist für Aufgaben gebaut, die über Stunden oder Tage an Problemen arbeiten. Astras Multi-Agenten-Koordinationsmuster ordnet sich direkt dem Aufgaben-Lebenszyklus von A2A zu, nicht dem zustandslosen Tool-Aufruf-Modell von MCP.

5. Rufen Sie ein System auf oder koordinieren Sie mehrere Agenten?

Wenn Ihr Agent mit NetSuite, HubSpot und BigCommerce sprechen muss, sind das drei MCP-Server. Jeder Server stellt Tools bereit; der Agent ruft sie nach Bedarf auf. Der Agent koordiniert — er entscheidet, welches Tool wann und in welcher Reihenfolge aufzurufen ist. Die MCP-Server wissen nichts voneinander.

Wenn Sie einen Beschaffungsagenten haben, der an einen Katalogagenten, einen Preisagenten und einen Compliance-Agenten delegieren muss — jeder mit eigenem Modell und eigenen Tools — sind das drei A2A-Endpunkte. Der Beschaffungsagent sendet Aufgaben, empfängt Streaming-Ergebnisse und koordiniert die Delegationskette. Die Katalog-, Preis- und Compliance-Agenten können jeweils MCP verwenden, um auf ihre eigenen Datenquellen zuzugreifen. Die beiden Protokolle operieren auf verschiedenen Schichten: A2A handhabt die Agent-zu-Agent-Delegation, MCP handhabt den Agent-zu-Tool-Zugriff innerhalb jedes Agenten.

Wann man beide verwendet: das Produktionsmuster

Das Produktionsmuster, bestätigt durch den tyk.io-Enterprise-Leitfaden und sichtbar in den 150+ A2A-Organisationen, ist eine Zweischicht-Architektur:

Jeder spezialisierte Agent ist ein A2A-Endpunkt (stellt eine Agent Card bereit, akzeptiert Aufgaben, streamt Ergebnisse). Jeder spezialisierte Agent verwendet auch MCP, um sich mit seinen eigenen Datenquellen zu verbinden. Der Orchestrator-Agent spricht nie direkt mit NetSuite — er delegiert an den Preisagenten, der MCP verwendet, um NetSuite abzufragen. Diese Trennung hält die Tool-Oberfläche jedes Agenten geregelt und prüfbar, während die A2A-Schicht die Inter-Agenten-Koordination handhabt.

Die Referenzimplementierung der Hermes Agent A2A-Brücke demonstriert dieses Muster: ein Gateway handhabt die A2A-Protokoll-Oberfläche (Agent Card, JSON-RPC-Dispatch, SSE-Streaming, Aufgaben-Zustandsmaschine), und steckbare Handler übersetzen die A2A-Aufgabensemantik in die native API jedes Frameworks. Das Hinzufügen eines neuen Agenten-Frameworks bedeutet, eine Handler-Klasse zu schreiben — Protokoll, Gateway und Zustandsmaschine sind gemeinsame Infrastruktur. Dasselbe Gateway kann zu Hermes Agent, OpenClaw oder einem zukünftigen Handler routen, ohne die A2A-Client-Oberfläche zu ändern.

Wann ein einzelner Agent ausreicht

Nicht jedes System benötigt A2A. Princeton NLP-Forschung fand, dass ein einzelner Agent auf 64 % der benchmarkten Aufgaben einem Multi-Agenten-System entsprach oder dieses übertraf — bei 2× den Kosten für die Multi-Agenten-Konfiguration. Wenn Ihr Workflow ein einzelner Agent ist, der NetSuite abfragt, ein Angebot erstellt und es zur Genehmigung einreicht, benötigen Sie MCP (für die NetSuite-Verbindung) und eine Anwendungsebene-Genehmigungsschwelle. Sie benötigen A2A nicht.

A2A wird notwendig, wenn Sie Agenten mit verschiedenen Modellen, verschiedenen Tool-Oberflächen oder verschiedenen Eigentums-Grenzen haben, die koordiniert werden müssen. Der Beschaffungsagent des Einkaufsteams und der Compliance-Agent des Finanzteams gehören verschiedenen Gruppen, können auf verschiedener Infrastruktur laufen und haben verschiedene Modellauswahlen. A2A gibt ihnen ein Protokoll, Arbeit zu delegieren und zu verfolgen, ohne eine Codebasis oder Bereitstellung zu teilen. Wenn alle Ihre Agenten dasselbe Modell auf derselben Infrastruktur mit demselben Eigentümer sind, ist ein einzelner Agent mit MCP-Tools einfacher und billiger.

Die finale MCP 2026-07-28-Spec: Was sich für diese Entscheidung geändert hat

Die MCP-Spezifikation wurde am 28. Juli 2026 als final veröffentlicht. Alle vier Tier-1-SDKs (TypeScript, Python, Go, C#) sprechen 2026-07-28. Die Spec machte MCP explizit zustandslos — Server halten keinen Sitzungszustand zwischen Aufrufen. Die 12-Monate-SSE-Verwerfungs-Richtlinie ist aktiv: Der Streamable-HTTP-Transport ersetzt SSE, und bestehende SSE-Bereitstellungen haben bis Juli 2027 Zeit zu migrieren.

Für die A2A-vs-MCP-Entscheidung bestätigt die finale Spec die Schichtung: MCP ist ein zustandsloses Tool-Protokoll. Wenn Sie MCP-Sitzungen verwendeten, um den Konversationsstatus des Agenten aufrechtzuerhalten, sagt die Spec, damit aufzuhören — der Zustand gehört zum Agenten (dem MCP-Client), nicht zum Server. Das macht die A2A-Schicht klarer notwendig: langlaufende, zustandsbehaftete Koordination zwischen Agenten ist nichts, wofür MCP konzipiert ist. Die Aufgaben-Zustandsmaschine von A2A füllt diese Lücke.

Eine Anmerkung zum Transport-Overlap

Beide Protokolle verwenden HTTP und SSE, was Verwirrung darüber verursachen kann, ob sie konkurrieren. Das tun sie nicht — der Transport-Overlap ist oberflächlich. MCP verwendet HTTP für Tool-Aufrufe (Anfrage → Antwort) und migriert von SSE zu Streamable HTTP für server-initiierte Benachrichtigungen. A2A verwendet JSON-RPC 2.0 über HTTP für Aufgaben-Dispatch und SSE für Streaming-Aufgaben-Ausgabe. Der Transport ist Klempnerarbeit; die Protokollsemantik ist unterschiedlich. MCP transportiert Tool-Aufrufe. A2A transportiert Aufgaben-Lebenszyklen. Sie können beide über dasselbe Gateway laufen — die Referenzimplementierung macht genau das, wobei das Gateway HTTP und SSE für beide Protokolle handhabt, während die Brückenschicht zur nativen API jedes Frameworks übersetzt.

Was das für Ihre Architektur bedeutet

Wenn Sie ein B2B-Agentensystem bauen — RFQ-Automatisierung, Beschaffungs-Workflows, Kundensupport mit Wissensgraphen, Datenpipeline-Orchestrierung — folgt die Protokollentscheidung der Workflow-Form:

• Ein Agent, mehrere Datenquellen → nur MCP. Der Agent verwendet MCP-Module, um sich mit NetSuite, HubSpot, BigCommerce und Lieferantenkatalogen zu verbinden. A2A nicht benötigt.
• Mehrere Agenten, derselbe Eigentümer, dieselbe Infrastruktur → MCP für Tools, Anwendungsebene-Koordination für Inter-Agenten-Arbeit. Erwägen Sie A2A, wenn die Koordinationslogik komplex genug wird, dass eine Protokoll-Ebene-Zustandsmaschine sie vereinfachen würde.
• Mehrere Agenten, verschiedene Eigentümer oder verschiedene Infrastruktur → A2A für Agent-zu-Agent-Delegation, MCP für Tool-Zugriff jedes Agenten. Das ist das Produktionsmuster für verteilte Agentensysteme.
• Langlaufende Aufgaben mit menschlichen Genehmigungsschwellen → A2A für den Aufgaben-Lebenszyklus und den INPUT_REQUIRED-Status, MCP für Tool-Aufrufe innerhalb jeder Aufgabe. Die Genehmigungsschwelle überschreitet Agent-Grenzen als A2A-Zustandsübergang, nicht als benutzerdefinierter Anwendungscode.

OpenAIs Astra-Bestätigung am 1. August macht das langlaufende Multi-Agenten-Muster zur Frontline-Modell-Designrichtung. Astra ist für Aufgaben gebaut, die über Stunden oder Tage an Problemen arbeiten und mehrere Agenten über längere Zeiträume koordinieren. Der Protokoll-Stack, der dieses Muster unterstützt, ist A2A für Koordination und MCP für Tool-Zugriff — die Zwei-Protokoll-Architektur, die dieser Artikel beschreibt.

---

Ein mittelständischer Distributor benötigt einen Angebotsagenten, der mit einem Katalogagenten spricht, der mit einem Compliance-Agenten spricht — jeder unterstützt von einem anderen Modell, jedem gehört von einem anderen Team, jeder verbindet sich über MCP-Module mit verschiedenen Systemen. A2A gibt diesen Agenten ein gemeinsames Protokoll für Delegation und Streaming. MCP gibt jedem Agenten regierten Zugriff auf seine Datenquellen. Das Brückenmuster ermöglicht es Hermes Agent, OpenClaw und jedem anderen Framework, am A2A-Netzwerk teilzunehmen, ohne ihre Interna umzuschreiben.

Einen scop-gedefinierten Build anfragen

Einwöchige Entdeckung. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Scope — ob Sie mit uns bauen oder nicht.