Warum es ein offenes Protokoll für KI-Agenten braucht
In den meisten Unternehmen entstehen KI-Agenten heute dort, wo sie gebraucht werden: ein Bestandsagent in der Logistik, ein Recherche-Agent im Marketing, ein Auftragsagent im Vertrieb. Jeder dieser Agenten ist in einem eigenen Framework gebaut – etwa LangChain, CrewAI oder einer hauseigenen Plattform – und lebt in seinem eigenen Ökosystem. Sobald zwei Agenten miteinander reden sollen, beginnt der Integrationsaufwand: proprietäre APIs, individuelle Datenformate, manuell verdrahtete Workflows.
Genau hier setzt das Agent2Agent-Protokoll (A2A) an. Es ist ein offener Standard für die Kommunikation zwischen KI-Agenten – unabhängig davon, wer sie gebaut hat oder auf welchem Framework sie laufen. Ursprünglich im April 2025 von Google und Technologiepartnern eingeführt, wird A2A inzwischen als Open-Source-Projekt unter dem Dach der Linux Foundation weiterentwickelt. Damit positioniert sich A2A als Messaging-Schicht für Multi-Agent-Systeme – vergleichbar mit einer gemeinsamen Sprache, die Agenten unterschiedlicher Anbieter trotz unterschiedlicher Architekturen miteinander sprechen lässt.
A2A vs. MCP: Zwei Protokolle, zwei Aufgaben
A2A wird häufig in einem Atemzug mit dem Model Context Protocol (MCP) von Anthropic genannt – die beiden Protokolle stehen aber nicht in Konkurrenz, sondern ergänzen sich:
-
MCP standardisiert, wie eine KI-Anwendung mit externen Tools, APIs und Datenquellen spricht.
-
A2A standardisiert, wie KI-Agenten untereinander kommunizieren und gemeinsam an Aufgaben arbeiten.
Ein Beispiel aus dem Handel: Ein Bestandsagent nutzt MCP, um in der Warenwirtschaft den Lagerbestand abzufragen. Erkennt er Unterdeckung, beauftragt er per A2A einen internen Auftragsagenten, der wiederum über A2A mit den Agenten externer Lieferanten verhandelt. MCP regelt den Zugriff auf Daten und Tools, A2A die Zusammenarbeit zwischen den handelnden Akteuren.
Die Bausteine des A2A-Protokolls
A2A folgt einem klaren Client-Server-Modell mit wenigen, gut definierten Bausteinen:
-
A2A-Client (Client-Agent): die Anwendung oder der Agent, der eine Aufgabe delegiert.
-
A2A-Server (Remote-Agent): der Agent, der die Aufgabe ausführt – erreichbar über einen HTTP-Endpunkt.
-
Agent Card: eine öffentlich abrufbare JSON-Datei, die den Agenten beschreibt – Name, Version, Endpunkt, unterstützte Modalitäten, Authentifizierung und Fähigkeiten. Die Agent Card ist quasi der Lebenslauf eines Agenten und macht ihn für andere auffindbar.
-
Task: eine Arbeitseinheit mit eigener ID und definiertem Lebenszyklus (gesendet, in Arbeit, Eingabe nötig, abgeschlossen, fehlgeschlagen).
-
Message und Part: die kleinste Einheit der Kommunikation. Eine Nachricht enthält ein oder mehrere Teile – als TextPart, FilePart oder strukturierter DataPart in JSON.
-
Artifact: das greifbare Ergebnis, das der Remote-Agent zurückliefert – ein Dokument, ein Bild, eine Tabelle oder strukturierte Daten.
So funktioniert A2A in drei Schritten
Die Zusammenarbeit zweier Agenten läuft über einen dreistufigen Workflow:
1. Discovery
Der Client-Agent sucht passende Remote-Agenten und liest deren Agent Cards. Anhand der dort beschriebenen Fähigkeiten entscheidet er, wer für die Aufgabe geeignet ist.
2. Authentifizierung
Vor dem ersten Aufruf authentifiziert sich der Client-Agent gemäß dem in der Agent Card angegebenen Sicherheitsschema. A2A unterstützt etablierte, OpenAPI-konforme Mechanismen – API-Keys, OAuth 2.0, OpenID Connect Discovery. Der Remote-Agent ist anschließend für die Autorisierung zuständig.
3. Kommunikation
Die eigentliche Zusammenarbeit läuft über HTTPS und JSON-RPC 2.0. Der Client-Agent sendet eine Aufgabe, der Remote-Agent verarbeitet sie, fragt bei Bedarf nach Details und liefert am Ende eine Nachricht plus Artefakte zurück. Für lange Aufgaben unterstützt A2A asynchrone Push-Benachrichtigungen an Client-Webhooks; für laufende Updates und große Antworten gibt es Streaming via Server-Sent Events (SSE).
Warum A2A für Unternehmen relevant ist
A2A löst drei Probleme, die in produktiven Multi-Agent-Szenarien sonst unweigerlich auftauchen:
-
Datenschutz durch Opazität: Agenten arbeiten zusammen, ohne ihre internen Modelle, Prompts oder Tool-Implementierungen offenlegen zu müssen. Das schützt geistiges Eigentum und sensible Daten – auch zwischen Unternehmen.
-
Nahtlose Integration: A2A baut auf bewährten Standards auf – HTTP, JSON-RPC, SSE. Es lässt sich in bestehende Stacks einpassen, ohne dass eine neue Infrastrukturschicht entsteht.
-
Sicherheit auf Enterprise-Niveau: Das Protokoll wurde von Beginn an mit Authentifizierung und Autorisierung im Blick entworfen und ist mit gängigen Identity-Konzepten kompatibel.
Was Unternehmen jetzt tun sollten
A2A ist noch jung, aber die Richtung ist klar: Multi-Agent-Architekturen werden zur Norm – und sie funktionieren nur, wenn Agenten sich finden, vertrauen und strukturiert zusammenarbeiten können. Drei Schritte, mit denen Organisationen sich realistisch vorbereiten:
-
Agenten-Inventar aufbauen: Welche Agenten existieren bereits, welche Fähigkeiten haben sie, welche Identitäten und Berechtigungen brauchen sie?
-
Schnittstellen vereinheitlichen: Bei neuen Agenten von Anfang an Agent Cards definieren, Sicherheitsschema dokumentieren und A2A-kompatible Endpunkte vorsehen.
-
Governance mitdenken: Wer darf welchen Agenten beauftragen, welche Daten dürfen über A2A fließen, wie werden Tasks und Artefakte auditiert?
Fazit: Vom isolierten Copiloten zum vernetzten Agentenökosystem
Mit A2A entsteht das, was MCP für Tool-Zugriffe geleistet hat – nur eine Ebene höher: ein offener, einheitlicher Weg für KI-Agenten, miteinander zu arbeiten. Für Unternehmen bedeutet das die Möglichkeit, Agenten verschiedener Hersteller, Frameworks und Geschäftsbereiche in ein konsistentes, sicheres und auditierbares Agentenökosystem zu überführen – ohne sich an einen einzigen Anbieter zu binden.
Die strategische Frage ist nicht mehr, ob Multi-Agent-Systeme produktiv werden, sondern wie schnell die eigene Architektur darauf vorbereitet ist – und A2A ist dafür einer der wichtigsten Bausteine.