Agent to Agent

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: MCP und A2A beantworten zwei verschiedene Architekturfragen, und die eigentliche Entscheidung ist, an welchen Systemgrenzen ein Protokoll überhaupt nötig ist.

🎚️ Soundcheck

In Ausgabe #005 ging es um MCP als standardisierten Weg, über den ein Agent Tools aufruft und Aktionen ausführt. Sobald mehrere Agenten im Spiel sind, stellt sich die nächste Frage: Wie delegiert ein Agent eine Aufgabe an einen anderen Agenten, den ein anderes Team, ein anderer Anbieter oder eine andere Organisation betreibt? Für diese Ebene positioniert sich das Agent2Agent-Protokoll (A2A), ursprünglich von Google initiiert und seit April 2026 in Version 1.0 unter dem Dach der Linux Foundation, nach eigenen Angaben mit über 150 unterstützenden Organisationen und Integrationen in Azure AI Foundry, Copilot Studio und Amazon Bedrock AgentCore. MCP wiederum wurde im Dezember 2025 an die Agentic AI Foundation der Linux Foundation übergeben und wird seither von Anthropic, OpenAI und Block gemeinsam getragen. Beide Protokolle sind damit herstellerneutral verankert, und die Frage nach ihrem Zusammenspiel ist eine Architekturentscheidung geworden.

🎤 Main Set: Zwei Protokolle, zwei Architekturfragen

MCP: Agent zu Tool

MCP standardisiert die vertikale Verbindung zwischen einem Agenten und seinen Werkzeugen: Tools, Ressourcen und Prompts werden mit typisierten Schemas beschrieben, der Agent ruft sie strukturiert auf. Das Spec-Release vom 28. Juli 2026 hat den Protokollkern auf eine zustandslose Architektur umgestellt, ergänzt um header-basiertes Routing, cache-bare Listenergebnisse und ein formales Erweiterungs-Framework, was den Betrieb hinter Load Balancern und in skalierten Umgebungen deutlich vereinfacht. Das Ökosystem ist dabei mittlerweile auf eine beträchtliche Größe gewachsen: Die offizielle MCP-Registry zählte im Mai 2026 rund 9.650 Server-Einträge.

A2A: Agent zu Agent

A2A adressiert die horizontale Ebene, also Delegation zwischen Agenten, die einander nicht als Funktionsbibliothek, sondern als eigenständige Dienste begegnen. Die Spezifikation definiert drei Schichten. Das Datenmodell umfasst unter anderem Agent Card, Task, Message, Part und Artifact. Die Agent Card ist ein öffentliches JSON-Manifest unter dem Well-known-Pfad /.well-known/agent-card.json, das Fähigkeiten, Authentifizierungsanforderungen und Service-URL eines Agenten beschreibt und seit Version 1.0 kryptografisch signiert werden kann. Die Operationen (SendMessage, GetTask, CancelTask, Streaming- und Push-Varianten) sind auf langlaufende Aufgaben ausgelegt: Ein Task hat einen definierten Lebenszyklus mit Zustandsübergängen, liefert Streaming-Updates und produziert Artifacts als Ergebnisobjekte. Als Transport-Bindings sind JSON-RPC 2.0 über HTTPS, gRPC und HTTP+JSON spezifiziert.

Der Unterschied in einem Satz zusammengefasst: MCP beschreibt, wie ein Agent ein Werkzeug aufruft, A2A beschreibt, wie ein Agent eine Aufgabe an einen anderen Agenten übergibt, deren Bearbeitung er weder steuert noch einsehen kann.

🥁 Track 2: An welchen Grenzen ein Protokoll nötig ist

Die Praxiserfahrung des „ersten A2A-Jahres“ zeigt ein differenziertes Bild. Tragfähig ist der Einsatz an drei Arten von Grenzen: erstens zwischen unabhängigen Teams, die eigene Spezialagenten mit klaren Ownership-Grenzen betreiben, etwa für HR, Finance oder IT-Betrieb, zweitens zwischen Anbietern, wenn Agenten einander per Discovery finden müssen und getrennte Deployment-Zyklen haben, drittens bei langlaufenden delegierten Aufgaben, die Zustandsverfolgung, Streaming und Artifact-Austausch erfordern. Umgekehrt gilt: Agenten, die dasselbe Team im selben Prozess mit denselben Berechtigungen betreibt, benötigen kein Interoperabilitätsprotokoll, dort sind interne APIs oder Message Queues die einfachere und wartbarere Lösung.

Zwei Einschränkungen sind durch aktuelle Untersuchungen belegt. Eine vergleichende Threat-Modeling-Analyse über MCP, A2A, Agora und ANP kommt zu dem Ergebnis, dass die Sicherheitsprinzipien dieser Protokolle bislang unzureichend untersucht und standardisiertes Threat Modeling kaum etabliert ist (arXiv 2602.11327), unter anderem mit Blick auf Agenten, die Fähigkeiten falsch deklarieren, und auf unklare Verantwortlichkeit über Delegationsketten hinweg. Eine Governance-Analyse über fünf Interoperabilitätsprotokolle zeigt zudem, dass Mechanismen wie Abstimmung, Dissens-Erhalt und strukturierte Deliberation in keinem der Protokolle ausdrückbar sind (arXiv 2606.31498). Die Protokolle koordinieren Aufgaben, sie ersetzen aber weder ein Berechtigungskonzept noch eine Governance-Struktur.

🎯 Encore: Der eine Gedanke für Entscheider

Die Frage ist nicht, ob MCP oder A2A das bessere Protokoll ist, denn sie liegen auf verschiedenen Ebenen und werden in Multi-Agent-Architekturen kombiniert. Die Entscheidungsfrage ist, wo im eigenen System echte Grenzen zwischen Ownership-Domänen, Anbietern oder Identitäten verlaufen, denn nur an diesen Grenzen rechtfertigt sich der Aufwand eines Interoperabilitätsprotokolls samt Identitäts-, Berechtigungs- und Audit-Konzept. Ein Protokoll an einer Grenze einzuziehen, die keine ist, erhöht die Komplexität ohne Gegenwert, eine echte Grenze ohne Protokoll zu überbrücken, erzeugt genau die implementierungsspezifischen Kopplungen, die Standardisierung vermeiden soll.

Die Prüffrage für Entscheider: An welchen Stellen unserer Agenten-Architektur wechseln Ownership, Identität oder Anbieter, und ist an genau diesen Stellen definiert, wie Delegation, Authentifizierung und Nachvollziehbarkeit funktionieren?

💿 B-Side

Anti-Pattern: A2A zwischen Agenten einführen, die dasselbe Team mit denselben Berechtigungen im selben Deployment betreibt. Die Delegation über ein Netzwerkprotokoll mit Discovery, Agent Cards und Task-Lifecycle bringt dort keinen Zugewinn gegenüber einem internen Funktionsaufruf, erhöht aber Angriffsfläche, Latenz und Betriebsaufwand.

Zur Vertiefung: der Survey über die vier Interoperabilitätsprotokolle MCP, ACP, A2A und ANP (arXiv 2505.02279) sowie die Governance-Gap-Analyse (arXiv 2606.31498) zu dem, was diese Protokolle strukturell nicht ausdrücken können.

Das war Rag'n'Roll #010. Die nächste Ausgabe behandelt die Optimierung des Retrievers: hybride Suche mit Rangfusion und Reranking als zweite Bewertungsstufe.

Weiterleiten erwünscht🤘