Agent2Agent vs. MCP: Auf diesen 2 Protokollen läuft Ihr AI-Agent-Stack im Jahr 2026 wirklich

Einen Agenten mit einem Tool zu verbinden, ist ein gelöstes Problem. Einen Agenten mit einem anderen Agenten zu verbinden, der von einem anderen Anbieter auf einem anderen Modell entwickelt wurde, war bis zu diesem Jahr ungelöst. Zwei Protokolle teilen sich nun diese Arbeit: das Model Context Protocol (MCP), das Anthropic im November 2024 veröffentlichte, um zu standardisieren, wie ein Agent auf Tools und Daten zugreift, und Agent2Agent (A2A), das Google im April 2025 einführte und Mitte 2025 an die Linux Foundation spendete. A2A überschritt bis April 2026 die Marke von 150 unterstützenden Organisationen und erreichte laut der Linux Foundation eine produktionsreife Einführung in Unternehmen. Die meisten Unternehmen betrachten die beiden immer noch als konkurrierende Standards. Das sind sie nicht. Sie befinden sich auf unterschiedlichen Ebenen des Stacks, und eine professionelle Agenten-Infrastruktur nutzt beide.

Die Verwechslung ist verständlich. Beide kamen im selben Zeitraum von achtzehn Monaten auf den Markt, beide tragen das Wort „Protokoll“ im Namen und beide versprechen Interoperabilität für KI-Agenten. Aber sie beantworten unterschiedliche Fragen. MCP beantwortet: „Wie erreicht ein Agent die Systeme, die er benötigt?“ A2A beantwortet: „Wie arbeiten zwei Agenten zusammen, die sich keine gemeinsame Codebasis teilen?“ Wenn Sie diesen Unterschied missachten, bauen Sie entweder eine Ebene übermäßig aus oder lassen die andere völlig unberücksichtigt.

Warum MCP zwei Agenten nicht miteinander sprechen lassen kann

MCP löst ein vertikales Problem: Ein Agent greift nach unten auf die Systeme zu, die er benötigt. Anthropic beschreibt es als „einen neuen Standard für die Verbindung von KI-Assistenten mit den Systemen, in denen Daten liegen, einschließlich Content-Repositories, Business-Tools und Entwicklungsumgebungen“. Stellen Sie es sich wie die Verkabelung zwischen einem einzelnen Agenten und seinen Händen vor: einem CRM, einer Datenbank, einem Slack-Workspace, einer internen API. Die Architektur ist Client-Server über JSON-RPC, wobei ein MCP-Server eine definierte Reihe von Tools, Ressourcen und Prompts bereitstellt, die jeder konforme Client aufrufen kann.

Diese Standardisierung war wichtig, da die Alternative ein individueller Integrationscode für jede Tool-Modell-Paarung gewesen wäre. Vor MCP bedeutete die Verbindung von fünf Agenten mit zehn Tools bis zu fünfzig maßgeschneiderte Integrationen, von denen jede ein Wartungsrisiko darstellte. MCP bündelt dies in einer einzigen Schnittstelle. Bis Mitte 2025 hatte die Community Tausende von aktiven MCP-Servern aufgebaut, und OpenAI, Microsoft sowie Google DeepMind übernahmen das Protokoll. MCP ist heute der De-facto-Standard, mit dem Agenten Dateien lesen, Funktionen aufrufen und Kontext abrufen, mit vorgefertigten Servern für Systeme wie Google Drive, GitHub, Postgres und Slack.

Was MCP jedoch nicht leistet, ist die Koordination zweier unabhängiger Agenten. Ein MCP-Server stellt einem Client Tools zur Verfügung. Er hat kein Konzept von einem gleichgestellten Partner-Agenten mit eigenen Zielen, eigenem Modell und eigener Handlungsbefugnis. Wenn Ihr Beschaffungsagent Ihren Finanzagenten bitten muss, eine Zahlung freizugeben, hat MCP dazu nichts beizutragen. Der Finanzagent ist kein Tool, das aufgerufen werden kann; er ist ein Akteur mit eigener Urteilskraft, eigenen Zugriffskontrollen und dem Recht, die Anfrage abzulehnen. Das ist ein horizontales Problem, und es erfordert ein anderes Protokoll.

Was sich änderte, als A2A Produktionsreife erreichte

A2A deckt den horizontalen Fall ab: Agenten finden sich gegenseitig, tauschen Nachrichten aus und koordinieren Aufgaben über Unternehmens- und Plattformgrenzen hinweg. Jeder Agent veröffentlicht eine „Agent Card“, die beschreibt, was er tun kann, und andere Agenten fragen diese Karte ab, um zu entscheiden, welche Aufgaben sie delegieren. Das Protokoll geht davon aus, dass die Agenten auf beiden Seiten von unterschiedlichen Teams entwickelt wurden, auf unterschiedlichen Modellen laufen und sich gegenseitig nur so weit vertrauen, wie es die Sicherheitsebene zulässt. Genau darum geht es bei dieser Annahme. A2A wurde für eine Welt entwickelt, in der kein einzelner Anbieter jeden Agenten in einem Workflow besitzt.

Der Wandel vom interessanten Konzept zum zuverlässigen Standard vollzog sich im ersten Jahr des Protokolls. Nachfolgende stabile Releases brachten Mandantenfähigkeit auf Enterprise-Niveau, modernisierte Sicherheitsabläufe und signierte Agent Cards, die kryptografische Signaturen verwenden, sodass ein empfangender Agent verifizieren kann, dass eine Karte tatsächlich von der Domain stammt, die dies behauptet. Frühere Entwürfe hatten bereits gRPC-Unterstützung und eine breitere SDK-Abdeckung hinzugefügt; erst die stabilen Releases machten die Schnittstelle zuverlässig genug, um darauf produktive Systeme aufzubauen.

Zum einjährigen Jubiläum im April 2026 meldete die Linux Foundation aktive Produktivproduktions-Einsätze in den Bereichen Lieferkette, Finanzdienstleistungen, Versicherungen und IT-Schnittstellen. A2A wurde zudem in Microsoft Azure AI Foundry, Copilot Studio, AWS Bedrock AgentCore und Google Cloud integriert. Produktiveinsatz, keine Testprojekte. Dieser Unterschied ist entscheidend. A2A verbrachte seine ersten Monate als vielversprechende Spezifikation, die von sieben Gründungspartnern (Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow) unterstützt wurde. Im zweiten Jahr etabliert es sich als Standardtechnologie, über die Unternehmen echtes Geld bewegen. Genau das ist die Schwelle, an der ein Protokoll aufhört, ein Forschungsobjekt zu sein, und zu einer Beschaffungsentscheidung wird.

MCP vs. A2A im direkten Vergleich

Der einfachste Weg, den Unterschied zu verstehen, ist ein direkter Vergleich.

Die beiden Protokolle ergänzen sich konzeptionell. Die Positionierung von A2A selbst versteht sich als Ergänzung zu MCP, nicht als Ersatz: MCP stattet einen einzelnen Agenten mit Fähigkeiten aus, und A2A lässt diesen ausgestatteten Agenten mit anderen zusammenarbeiten. Ein Enterprise-Agent nutzt MCP, um seine Aufgabe zu erfüllen, und A2A, um mit Agenten zu interagieren, die nicht von ihm selbst stammen. Das passende mentale Modell dazu: MCP ist die Art und Weise, wie ein Agent seine Hände benutzt, und A2A ist der Handschlag zwischen zwei Agenten.

Sie werden beide benötigen, und zwar früher als gedacht

Dieses Thema verliert seine theoretische Natur durch die Geschwindigkeit der Einführung. Gartner prognostiziert, dass bis Ende 2026 40 % der Unternehmensanwendungen über aufgabenspezifische KI-Agenten verfügen werden, verglichen mit weniger als 5 % im Jahr 2025 (Gartner, August 2025). Das ist ein achtfacher Sprung in einem einzigen Jahr, schneller als die frühe Adoptionskurve von Cloud oder Mobile.

Wenn 40 % Ihrer Anwendungen eigene Agenten mitbringen, werden diese Agenten nicht alle von einem einzigen Anbieter stammen, mit demselben Modell laufen oder in derselben Cloud liegen. Ihr Salesforce-Agent, Ihr ServiceNow-Agent und der benutzerdefinierte Agent, den Ihr Team im letzten Quartal entwickelt hat, müssen sich bei Workflows koordinieren, die alle drei Systeme betreffen. MCP gibt jedem von ihnen seine Tools. A2A gibt ihnen eine gemeinsame Sprache, um miteinander zu sprechen. Wenn Sie sich für ein Protokoll entscheiden und das andere ignorieren, bleibt die Hälfte Ihres Stacks stumm: Agenten, die zwar handeln, aber nicht zusammenarbeiten können, oder Agenten, die zwar verhandeln können, aber keine Hände haben.

Dies ist auch der Grund, warum sich die Frage „Eigenbau oder Kauf“ stillschweigend in Richtung Standards auflöst. Vor einem Jahr hätte ein Unternehmen vielleicht noch einen proprietären Message Bus geschrieben, um seine Agenten zu koordinieren. Mit A2A unter der Schirmherrschaft der Linux Foundation und MCP, das von den großen Modellanbietern übernommen wurde, ist benutzerdefinierter Interoperabilitäts-Code heute technologische Altlast, die Sie sehenden Auges aufbauen. Die Protokolle sind etabliert. Die interessanten Entscheidungen haben sich eine Ebene nach oben verlagert.

(Wenn Sie wöchentlich erfahren möchten, wie sich die Infrastruktur für Enterprise-Agenten tatsächlich entwickelt, informiert Sie der Newsletter von Beam AI über Protokolländerungen, Best Practices in der Produktion und die Probleme im Detail.)

Was keines der Protokolle löst: Die Ebene, an der Projekte tatsächlich scheitern

Hier liegt die Falle. MCP und A2A im Einsatz zu haben, fühlt sich an wie eine Agenten-Plattform. Das ist es aber nicht. Beide Protokolle beantworten: „Wie verbinden sich diese Komponenten?“ Keines beantwortet die Fragen: „Wer darf was tun, und woher wissen wir, wenn etwas schiefgegangen ist?“

Drei Lücken liegen oberhalb der Protokollebene, und genau diese Lücken bringen Projekte zum Scheitern:

• Governance und Richtlinien. A2A definiert, wie Agenten Nachrichten austauschen. Es definiert nicht, ob Ihr Finanzagent berechtigt ist, eine Zahlung in Höhe von 2 Millionen US-Dollar ohne menschliche Freigabe zu genehmigen, oder welche Agenten welche anderen aufrufen dürfen. Diese Richtlinien befinden sich oberhalb der Übertragungsebene, und kein Protokoll wird sie für Sie schreiben.

• Observability. Wenn ein Workflow aus fünf Agenten eine falsche Antwort liefert, sagt Ihnen keines der Protokolle, welcher Agent falsch gedacht hat, welches Tool veraltete Daten zurückgegeben hat oder an welcher Stelle die Kette gerissen ist. Sie benötigen Tracing über die gesamte Interaktion hinweg, nicht nur ein wohlgeformtes Nachrichtenformat. Eine signierte Agent Card sagt Ihnen, dass eine Nachricht authentisch ist; sie sagt Ihnen nichts darüber, ob die Entscheidung dahinter vernünftig war.

• Identität und Autorisierung über Agenten hinweg. Signierte Agent Cards verifizieren, dass ein Agent der ist, für den er sich ausgibt. Sie verwalten jedoch nicht, was dieser Agent im Namen welches Menschen mit welchen Zugangsdaten und unter welchem Audit-Trail tun darf. Agentenübergreifende Identität, Delegation und Sperrung sind eine Disziplin für sich, an der Sicherheitsprüfungen häufig scheitern.

Dies ist kein Randproblem. Gartner prognostiziert, dass über 40 % der agentenbasierten KI-Projekte bis Ende 2027 aufgrund eskalierender Kosten, unklarem Geschäftsnutzen und unzureichendem Risikomanagement eingestellt werden (Gartner, Juni 2025). „Unzureichendes Risikomanagement“ benennt die Governance-Ebene direkt beim Namen. Projekte scheitern nicht, weil sich Agenten nicht verbinden können. Sie scheitern, weil niemand die Agenten nach der Verbindung verwalten, überwachen oder sichern konnte. Das Verbindungsproblem macht die einfachen 20 % aus. Das Kontrollproblem ist die 80 %-Hürde, die darüber entscheidet, ob das System das erste Audit übersteht.

Wo die Orchestrierungsebene liegt

MCP und A2A sind Infrastrukturstandards. Infrastrukturstandards sind notwendig, etabliert und nicht mehr der Ort, an dem die komplexen Probleme liegen. Die Verbindung ist doppelt gelöst. Die ungelöste Aufgabe ist die Orchestrierungs- und Governance-Ebene. Sie entscheidet, welche Agenten in welcher Reihenfolge, unter welchen Richtlinien und mit welchem Audit-Trail laufen – und wo ein Mensch eingebunden wird, wenn es die Risiken erfordern.

Das ist die Ebene, für deren Bereitstellung Enterprise-Plattformen da sind. Eine Plattform wie Beam AI nutzt MCP und A2A als Transportebene darunter und fügt dann die Komponenten hinzu, die die Protokolle bewusst aussparen: Richtliniendurchsetzung für das, was KI-Agenten tun dürfen, End-to-End-Observability über Multi-Agenten-Workflows hinweg, Identitäts- und Zugriffskontrolle für jede Agenten-Aktion sowie eine von Anfang an integrierte menschliche Kontrolle, anstatt diese nachträglich anzuflanschen. Die Protokolle übertragen die Nachrichten. Die Plattform entscheidet, ob die Nachrichten hätten gesendet werden dürfen, protokolliert dies und stoppt diejenigen, die nicht gesendet werden sollten.

Für jeden CTO, der die Agenten-Architektur für 2026 plant, lautet die ehrliche Einschätzung: Setzen Sie auf MCP, da Ihre Agenten einen Standardweg benötigen, um Tools zu erreichen – und Anthropic, OpenAI und Google sich bereits darauf geeinigt haben. Nutzen Sie A2A, da Ihre Agenten mit Agenten zusammenarbeiten müssen, die Sie nicht selbst entwickelt haben, und die Linux Foundation diesen Standard nun betreut. Konzentrieren Sie Ihre eigentliche Arbeit dann auf die Ebene darüber. Das ist die Ebene, die ein funktionierendes Agenten-System von einem Projekt unterscheidet, das zu den von Gartner prognostizierten 40 % abgebrochenen Projekten gehört. Und es ist die einzige Ebene, deren Erfolg wirklich in Ihrer Hand liegt.