Agent-to-Agent-Protokolle: Wie MCP und A2A die Multi-Agent-Interoperabilität neu definieren

Vor sechs Monaten bedeutete 'Multi-Agent-System' ein handgestricktes Netz aus HTTP-Endpunkten, zusammengehalten von Adaptern, Retry-Logik und Hoffnung. Heute verändern zwei Protokolle das: Model Context Protocol (MCP) und Agent-to-Agent (A2A). Sie lösen unterschiedliche Probleme, lassen sich elegant komponieren – und die meisten Teams wenden sie trotzdem falsch an.

Das Interoperabilitätsproblem, das niemand lösen wollte

In den letzten zwei Jahren hat jedes ernstzunehmende KI-Team denselben Schmerz neu entdeckt: Agenten sprechen mit nichts auf standardisierte Weise. Jedes Framework – LangChain, LlamaIndex, AutoGen, CrewAI – hat seine eigene Tool-Calling-Konvention erfunden. Jeder Anbieter hat sein eigenes JSON-Schema für 'Function Calling' ausgeliefert. Ergebnis: jede Integration maßgeschneidert, jede Migration eine Neuschreibung, und jedes 'Multi-Agent-System' war in Wahrheit ein einzelnes Framework, das sich als viele Agenten ausgab.

Die Branche hat das schon einmal erlebt. Wir hatten SOAP, bis REST die Service-zu-Service-Kommunikation standardisiert hat. Wir hatten proprietäre Container-Formate, bis OCI die Runtime standardisiert hat. Wir hatten anbietergebundene Orchestrierung, bis Kubernetes kam. Die agentische Schicht war der nächste Ort, der auf sein Protokoll wartete – und hat jetzt zwei.

MCP: das USB-C für Agent-Tooling

Model Context Protocol (MCP) beantwortet eine eng gefasste Frage: Wie entdeckt und ruft ein Agent die ihm verfügbaren Werkzeuge, Ressourcen und Prompts auf? Die Analogie, die sich durchgesetzt hat – und das zu Recht – ist USB-C. Jeder MCP-kompatible Client kann sich mit jedem MCP-kompatiblen Server verbinden, ohne individuellen Klebecode.

Ein MCP-Server exponiert drei Primitive: Tools (Funktionen, die der Agent aufrufen kann), Resources (Daten, die der Agent lesen kann) und Prompts (Template-Anweisungen, die der Server injizieren kann). Der Transport ist JSON-RPC 2.0, üblicherweise über stdio für lokale Server oder HTTP mit Server-Sent Events für entfernte. Mehr nicht. Die Einfachheit ist das Ziel.

• Ein Agent, viele MCP-Server: Dein Claude-basierter Coding-Agent kann sich gleichzeitig mit einem GitHub-MCP-Server, einem Postgres-MCP-Server, einem Filesystem-MCP-Server und einem internen Jira-MCP-Server verbinden – ohne eine einzige Zeile benutzerdefinierten Adaptercodes.
• Serverseitige Capability-Kontrolle: Der MCP-Server bestimmt, was der Agent sehen und tun darf. Du übergibst dem Agenten keine Credentials; du betreibst den Server mit diesen Credentials und legst eine enge Werkzeug-Oberfläche offen.
• Komponierbarer Kontext: MCP-Resources erlauben einem Agenten, frischen Kontext (Dateien, Datenbankzeilen, API-Antworten) zum Zeitpunkt des Reasonings zu ziehen, statt alles in den System-Prompt vorzuladen.
• Kein SDK-Lock-in: MCP ist ein Wire-Protokoll. Du kannst einen Server in Python, Rust, TypeScript, Go oder jeder Sprache schreiben, die JSON-RPC spricht.

Bei Xcapit bauen wir KI-Agenten, bei denen jede externe Fähigkeit hinter einem MCP-Server liegt. Das ist keine stilistische Entscheidung – sondern eine Governance-Entscheidung. Wenn ein Werkzeug hinter einem MCP-Server liegt, hast du einen einzigen, auditierbaren Engpass für Autorisierung, Rate-Limiting und Logging. Liegt es im Code des Agenten selbst, hast du nichts davon.

A2A: das Protokoll, wenn ein Agent nicht genügt

Agent-to-Agent (A2A) löst ein Problem, das MCP nie lösen sollte: Wie verhandeln, delegieren und kollaborieren zwei Agenten – möglicherweise von unterschiedlichen Anbietern, auf unterschiedlichen Frameworks gebaut und mit unterschiedlichen Modellen – an einer Aufgabe? A2A behandelt jeden Agenten als Peer-Service mit einer auffindbaren 'Agent Card' (Fähigkeiten, Authentifizierungsanforderungen, Skills) und definiert die Nachrichtenformate für den Lebenszyklus einer Aufgabe: submitted → working → input-required → completed → failed.

Das Protokoll ist bewusst zurückhaltend darin, was es standardisiert. Es schreibt nicht vor, wie ein Agent räsoniert, welches Modell er nutzt oder wie er plant. Es standardisiert nur die Kanten, an denen Agenten aufeinandertreffen: Identität, Task-Handoff, Status-Streaming, Artifact-Austausch. Alles Innere des Agenten bleibt deine Implementierungsentscheidung. Genau richtig.

• Agent Cards: ein öffentliches JSON-Dokument unter /.well-known/agent.json, das deklariert, was ein Agent kann, wie man sich authentifiziert und welche Skills er exponiert. Discovery wird trivial.
• Typisierter Task-Lebenszyklus: jeder A2A-Austausch ist ein Task mit einer definierten Zustandsmaschine. Keine Ad-hoc-Polling-Schleifen und keine undokumentierten Webhook-Retries mehr.
• Streaming per Default: Langlaufende Agent-Arbeit streamt Status-Updates und Teil-Artefakte via SSE. Deine UI tut nicht mehr so, als wäre der Agent eine synchrone Funktion.
• Cross-Vendor by Design: Ein auf Claude gebauter Agent kann einen auf Gemini gebauten Agenten aufrufen, der wiederum einen auf einem Open-Source-Modell gebauten aufruft – ohne dass einer die Interna der anderen kennt.

Die Komposition: MCP innen, A2A außen

Das mentale Modell, das bei jedem Team, das wir begleitet haben, einrastet: MCP ist, wie ein Agent seine Fähigkeiten erreicht. A2A ist, wie ein Agent andere Agenten erreicht. Sie leben auf unterschiedlichen Ebenen der Architektur, und ein reifes System nutzt beide.

Konkret: In einem aktuellen Projekt haben wir ein System zur Prüfung juristischer Dokumente mit vier Agenten ausgeliefert: einen Intake-Agenten (Python, Claude Sonnet), einen Clause Analyzer (Rust, Claude Opus), einen Compliance Checker (TypeScript, feinabgestimmtes Open-Modell) und einen Summarizer (Python, Gemini). Jeder Agent exponiert seine Skills via A2A. Jeder Agent erreicht seine Werkzeuge – Vektorsuche, OCR, Compliance-Register, Dokumentspeicher – intern via MCP. Der Orchestrator weiß nicht, wie irgendein Agent funktioniert; er reicht nur Aufgaben ein und nimmt Ergebnisse per Streaming entgegen. Die Agenten wissen nicht, worauf ihre Peers laufen; sie rufen einander nur per Agent Card auf.

Genau diese Entkopplung lässt die Architektur die nächsten zwei Jahre überleben. Wenn Gemini 3 erscheint oder DeepSeek R2 bei der Klauselextraktion alle schlägt, tauschst du die Interna des Clause Analyzers aus. Nichts anderes ändert sich. Kein Orchestrator-Rewrite, keine Datenbankmigration, kein Sprint des 'Platform Teams'.

Fehler, die wir auf die harte Tour gelernt haben

• Pack keine Business-Logik in den MCP-Server. Er ist eine Protokoll-Grenze, keine Domänenschicht. Domänenregeln gehören in den Service hinter dem MCP-Server, nicht in die Tool-Definitionen.
• Überspringe nicht die Agent-Identität. Ein A2A-Caller muss sich authentifizieren, und die Authentifizierung muss Service-zu-Service sein (mTLS, OIDC Client Credentials, signierte JWTs), nicht 'ein API-Key im Header', der aus deinen REST-Zeiten recycelt wurde.
• Logge nicht nur die Endantwort. Logge für jeden A2A-Task die vollständige Historie der Zustandsübergänge und jeden MCP-Tool-Aufruf mit seinen Argumenten. Wenn ein Agent eine Entscheidung halluziniert, musst du den Reasoning-Pfad rekonstruieren können – und das geht nur, wenn du ihn eingefangen hast.
• Mische Transportschichten nicht willkürlich. stdio-MCP-Server sind in Ordnung für Entwickler-Tooling; Produktions-MCP-Server sollten HTTP+SSE mit ordentlicher Auth sein. A2A sollte immer HTTPS mit signierten Agent Cards sein.
• Exponiere nicht alles. Nur weil ein Agent jedes MCP-Tool aufrufen kann, heißt das nicht, dass er sollte. Wende Least Privilege am Server an: Ein Clause Analyzer braucht keinen Schreibzugriff auf dein CRM.
• Baue keinen eigenen 'Orchestrator', bevor du A2A versucht hast. Der erste Instinkt ist, einen Supervisor-Agenten mit hartcodierter Delegationslogik zu schreiben. Das A2A-Task-Modell ersetzt mit passenden Agent Cards normalerweise 80 % dieses Codes.

Was als Nächstes kommt

Drei Verschiebungen sind im Ökosystem bereits sichtbar. Erstens absorbiert MCP Governance-Primitive – Autorisierungs-Metadaten, Rate-Limit-Deklarationen, Kostenschätzungen – die es zu einem tragfähigen Backbone für regulierte Branchen machen, nicht nur für Entwickler-Tooling. Zweitens wächst in A2A ein Delegation-of-Authority-Modell, sodass Agent B mit begrenztem Scope im Namen von Agent A handeln kann – das fehlende Stück für cross-organisationale agentische Workflows. Drittens die Verifikationsschicht: signierte Agent Cards, signierte Task-Artefakte und On-Chain-Attestierungen von Agent-Aktionen – die Brücke zu verifizierbaren KI-Agenten und zur Governance-Diskussion, über die José Trajtenberg separat schreibt.

Die unbequeme Wahrheit ist: Die meisten Unternehmen, die heute Agentensysteme bauen, schreiben Code, der in achtzehn Monaten obsolet sein wird. Nicht weil die Agenten falsch sind – sondern weil der Kleber zwischen ihnen maßgeschneidert ist. Wer 2026 ein Multi-Agent-System architektiert, stellt nicht mehr die Frage 'welches Framework?' – sondern 'welche Protokolle, und wie regiere ich sie?'.

Wenn dein Team MCP, A2A oder das Einbetten beider in eine produktionsreife Governance-Schicht evaluiert, lass uns sprechen. Wir haben die Fehler gemacht, damit dein Team das nicht muss.