Das A2A-Protokoll (Agent2Agent, „Agent zu Agent") ist eine offene, gemeinsame Sprache, mit der KI-Agenten (eigenständig arbeitende KI-Programme) verschiedener Hersteller miteinander reden können. Es legt fest, wie sich diese Agenten gegenseitig finden, Aufgaben aneinander weiterreichen, sich über den Bearbeitungsstand austauschen und Ergebnisse zurückmelden, unabhängig davon, welche KI oder welches Bausystem hinter dem einzelnen Agenten steht.
Was ist das A2A-Protokoll?
A2A wurde im April 2025 von Google Cloud vorgestellt und im Sommer 2025 gemeinsam mit über 50 Industriepartnern (darunter Salesforce, ServiceNow, SAP, Deloitte, Accenture, MongoDB und Atlassian) an die [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-launches-agent2agent-protocol-project-with-founding-partners) übergeben, eine gemeinnützige Stiftung, die offene Software-Standards betreut. Die technische Beschreibung liegt öffentlich im [A2A-GitHub-Repository](https://github.com/a2aproject/A2A) und wird von einer offenen Entwickler-Gemeinschaft (Community) weiterentwickelt. Ziel des Standards ist, dass Agenten unterschiedlicher Hersteller ohne individuelle Zwischenstücke (Adapter) zusammenarbeiten.
Technisch bewegt sich A2A auf etablierten Web-Standards. Der Transport erfolgt über HTTPS mit JSON-RPC 2.0; Streaming-Antworten laufen als Server-Sent Events. Jeder Agent, der Anfragen entgegennimmt, veröffentlicht eine sogenannte Agent Card an einer bekannten Well-Known-URL. Diese JSON-Selbstbeschreibung enthält Metadaten zu Fähigkeiten, unterstützten Skills, Authentifizierung, Streaming-Support und Endpunkten. Anfragen werden als Tasks modelliert, die einen definierten Lebenszyklus durchlaufen: submitted, working, input-required, completed, failed oder canceled. Ein- und Ausgaben werden als Messages und Artifacts transportiert; beide können Text, strukturierte Daten und Dateien enthalten.
Rollen im Protokoll sind bewusst symmetrisch. Ein Client-Agent stellt eine Aufgabe, ein Remote-Agent nimmt sie an und arbeitet sie ab. Derselbe Agent kann je nach Situation beide Rollen einnehmen. Damit unterscheidet sich A2A von einem klassischen Client-Server-Modell: Agenten sind Peers mit eigenem Skill-Set, die einander Aufgaben zuspielen.
Der Standard existiert, weil Multi-Agent-Systeme in Unternehmen aus Agenten unterschiedlicher Herkunft bestehen. Ein Recruiting-Agent aus dem HR-System, ein Sourcing-Agent eines externen SaaS-Anbieters und ein Compliance-Agent aus einer selbstentwickelten Anwendung nutzen typischerweise verschiedene Frameworks (LangGraph, CrewAI, Microsoft Agent Framework, Google ADK) und verschiedene Modelle. A2A ist die Interoperabilitätsschicht zwischen diesen Agenten. Es ergänzt das Model Context Protocol (MCP), das die Anbindung eines einzelnen Agenten an Werkzeuge und Datenquellen standardisiert.
Abgrenzung: A2A, MCP, Function Calling und Agent-Frameworks
Der Begriff wird häufig in Abgrenzung zu ähnlich klingenden Protokollen und Mechanismen verwendet.
| Ebene | Standard / Mechanik | Zweck |
|---|---|---|
| Agent ↔ Agent | A2A | Delegation, Task-Lifecycle, Ergebnis-Austausch zwischen eigenständigen Agenten |
| Agent ↔ Tool / Daten | MCP (Model Context Protocol) | Standardisierter Zugriff eines Agenten auf Tools, APIs, Ressourcen |
| Modell ↔ Tool-Aufruf | Function Calling / Tool Use | Anbieter-spezifische Mechanik (OpenAI, Anthropic, Google), mit der ein Modell strukturierte Tool-Calls erzeugt |
| Innerhalb eines Prozesses | Agent-Frameworks (LangGraph, CrewAI) | Framework-interne Orchestrierung, Zustandsverwaltung, Prompt-Logik |
MCP und A2A werden häufig verwechselt, sind aber komplementär. MCP standardisiert die vertikale Achse zwischen einem Agenten und seinen Werkzeugen; A2A standardisiert die horizontale Achse zwischen mehreren Agenten. Ein A2A-Remote-Agent nutzt intern oft MCP-Server für den Zugriff auf CRM-Daten oder Dateisysteme.
Function Calling liegt eine Ebene tiefer als beide Protokolle. Es beschreibt, wie ein Modell selbst einen Werkzeugaufruf formuliert; A2A geht davon aus, dass auf beiden Seiten bereits vollständige Agenten existieren. Agent-Frameworks sind wiederum kein Protokoll: Sie orchestrieren Agenten innerhalb eines Prozesses, während A2A den externen Draht zwischen Prozessen und Anbietern zieht. In der Gartner-Kategorie Communication Frameworks ist A2A eine konkrete, offene Ausprägung.
Beispiel: Multi-Vendor-Workflow im Recruiting
Ein Recruiting-Agent im HR-System eines Unternehmens bekommt den Auftrag, für eine offene Stelle geeignete Kandidaten vorzuschlagen. Über einen Agent-Katalog entdeckt er zwei weitere Agenten: einen Sourcing-Agenten eines externen SaaS-Anbieters und einen internen Compliance-Agenten für DSGVO-Prüfungen. Beide veröffentlichen eine Agent Card mit den jeweils angebotenen Skills.
Der Recruiting-Agent legt eine A2A-Task an den Sourcing-Agenten an: Task: Kandidaten für Rolle X vorschlagen, Region DACH, Budget Y. Der Sourcing-Agent nimmt die Task entgegen (working), fragt intern über MCP eine Kandidaten-Datenbank ab und liefert nach kurzer Zeit ein Artifact mit einer strukturierten Kandidatenliste zurück (completed). Der Recruiting-Agent reicht diese Liste als neuen Task an den Compliance-Agenten weiter, der die enthaltenen personenbezogenen Daten auf DSGVO-Konformität prüft und ein zweites Artifact mit dem Prüfergebnis zurückgibt. Am Ende fasst der Recruiting-Agent Vorschläge und Prüfergebnis für den Recruiter zusammen.
Jeder der drei Agenten stammt von einem anderen Anbieter, läuft in einem anderen Framework und nutzt ein anderes Modell. Die Agent Cards, der Task-Lifecycle und das Message-/Artifact-Format sind der gemeinsame Nenner. Ohne A2A wären für dieselbe Kette drei individuelle Adapter nötig, mit einem entsprechenden Betriebs- und Wartungsaufwand.
A2A-Protokoll (Agent2Agent) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.