A2A-Protokoll

Was ist das A2A-Protokoll?

Das A2A-Protokoll, kurz für Agent2Agent, ist ein offener Standard für die Kommunikation zwischen KI-Agenten, die von unterschiedlichen Teams auf unterschiedlichen Frameworks gebaut wurden. Es ermöglicht einem Agenten, die Fähigkeiten eines anderen zu entdecken, ihm eine Aufgabe zu übertragen und diese bis zum Abschluss zu verfolgen – ohne dass eine der beiden Seiten ihre internen Prompts, Modelle oder Tools offenlegen muss.

Die wichtigsten Punkte

• A2A standardisiert die Delegation zwischen Agenten so, wie das Model Context Protocol den Zugriff von Agenten auf Tools standardisiert. Beide ergänzen sich, und die meisten ausgereiften Agenten-Stacks setzen 2026 auf beide.
• Die Discovery läuft über Agent Cards: maschinenlesbare Beschreibungen dessen, was ein Agent kann und wie er erreichbar ist, veröffentlicht unter einer bekannten URL.
• Die Arbeitseinheit ist eine Task mit einem eigenen Lebenszyklus. Tasks können lange laufen, Fortschrittsupdates streamen und in den Zuständen completed, failed oder canceled enden.
• Google hat A2A am 9. April 2025 mit mehr als 50 Technologiepartnern gestartet, darunter Atlassian, Salesforce, SAP, ServiceNow und PayPal [1], und das Protokoll anschließend an die Linux Foundation übergeben, wodurch dessen Governance auf eine herstellerneutrale Basis gestellt wurde.
• Agenten bleiben füreinander undurchsichtig. Zusammenarbeit läuft über Nachrichten und Artefakte, nie über das Teilen internen Zustands – das hält organisatorische Grenzen intakt.

So funktioniert es

A2A basiert auf vertrauter Web-Infrastruktur: JSON-RPC über HTTP, mit Server-Sent Events für Streaming und Push-Benachrichtigungen für sehr lange laufende Jobs. Die Interaktion beginnt mit der Discovery. Ein Agent, der Unterstützung sucht, ruft die Agent Card eines anderen Agenten ab – ein JSON-Dokument, das dessen Fähigkeiten, Endpunkt, unterstützte Content-Typen und Authentifizierungsanforderungen beschreibt. Cards werden typischerweise unter einem bekannten Pfad auf der Domain des Agenten bereitgestellt, sodass das Auffinden eines Partneragenten ähnlich funktioniert wie das Auffinden der robots.txt einer Website.

Sobald ein Client-Agent einen Remote-Agenten ausgewählt hat, eröffnet er eine Task. Der Remote-Agent nimmt sie an und arbeitet sie über einen definierten Lebenszyklus ab, wobei er unterwegs Statusupdates ausgibt. Eine Task kann auch in einen Zustand input-required pausieren, in dem der Remote-Agent zwischendurch eine klärende Rückfrage stellt. Ergebnisse kommen als Artefakte zurück, die Text, strukturierte Daten oder Dateien sein können. Da alles über HTTP mit gängiger Unternehmensauthentifizierung läuft, lässt sich bestehende Infrastruktur für Routing, Monitoring und Zugriffskontrolle ohne Änderung weiterverwenden. Auch die Tooling-Unterstützung hat Schritt gehalten: Die Linux Foundation berichtete im April 2026, dass das zentrale A2A-Repository im ersten Jahr die Marke von 22.000 GitHub-Stars überschritten hat, während sich das SDK-Ökosystem von einer einzigen Python-Implementierung auf fünf produktionsreife Sprachen erweitert hat [2].

Das Designprinzip, das A2A von einem gemeinsamen Multi-Agent-Framework unterscheidet, ist Opazität. Der Client-Agent sieht nie, wie der Remote-Agent arbeitet, sondern nur, was er liefert. Genau das macht die Zusammenarbeit über Anbieter- und Unternehmensgrenzen hinweg realistisch: Ein Beschaffungsagent in einem Unternehmen kann einem Fulfillment-Agenten eines Lieferanten eine Aufgabe übergeben, während beide ihre internen Abläufe – und ihre Sicherheitsarchitektur – für sich behalten.

Beispiel

Ein Unternehmen betreibt einen HR-Onboarding-Agenten in einem Framework und, gebaut von einem anderen Team, einen IT-Provisioning-Agenten in einem anderen. Bei einer Neueinstellung entdeckt der HR-Agent den IT-Agenten über dessen Agent Card, eröffnet eine Task zur Bereitstellung von Laptop, Konten und Zugriffsgruppen und hängt das Rollenprofil als strukturierte Daten an. Der IT-Agent streamt den Fortschritt, während jedes System abgeschlossen wird, pausiert einmal im Zustand input-required, um eine ungewöhnliche Zugriffsanfrage zu bestätigen, und liefert dann ein Artefakt, das alles Bereitgestellte zusammenfasst. Keines der beiden Teams musste seinen Agenten umschreiben, um zum Stack des anderen zu passen – das Protokoll war der Vertrag zwischen ihnen.

Häufige Missverständnisse

Ein verbreitetes Missverständnis ist, A2A und MCP seien konkurrierende Standards, zwischen denen sich ein Team entscheiden muss. Sie arbeiten auf unterschiedlichen Ebenen. MCP verbindet einen Agenten mit Tools und Daten – Dingen ohne eigene Handlungsfähigkeit, die auf Aufrufe reagieren. A2A verbindet einen Agenten mit anderen Agenten – Peers, die selbst denken, ihren eigenen Kontext halten und Minuten oder Tage brauchen können, um fertig zu werden. In einer ausgereiften Architektur spricht derselbe Agent beide Sprachen: MCP nach unten zu seinen Tools, A2A zur Seite zu seinen Peers.

FAQ

Wer hat das Agent2Agent-Protokoll entwickelt? Google hat es im April 2025 mit Unterstützung von mehr als fünfzig Technologie- und Beratungspartnern angekündigt und es später an die Linux Foundation übergeben, sodass kein einzelner Anbieter die Spezifikation kontrolliert. Zum ersten Jahrestag des Protokolls im April 2026 zählte die Linux Foundation mehr als 150 unterstützende Organisationen, gegenüber mehr als 50 zum Start [3].

Wann sollte ich A2A verwenden, statt einfach einen größeren Agenten zu bauen? A2A lohnt sich an organisatorischen Grenzen: unterschiedliche Teams, unterschiedliche Anbieter, unterschiedliche Unternehmen. Innerhalb einer einzigen Codebasis, die einem Team gehört, sind direkte Orchestrierung oder Subagenten einfacher. Das Protokoll rechtfertigt seinen Mehraufwand, wenn die zusammenarbeitenden Agenten ihre internen Abläufe nicht teilen können oder sollen.

Kümmert sich A2A um Sicherheit zwischen Agenten? Es baut auf Standard-Web-Authentifizierung und -Autorisierung auf, und Agent Cards legen die Anforderungen jedes Agenten offen. Was es nicht leisten kann, ist einen Remote-Agenten vertrauenswürdig zu machen. Eine Aufgabe zu delegieren bedeutet, der Ausgabe eines anderen Systems zu vertrauen – behandeln Sie empfangene Artefakte also als nicht vertrauenswürdige Eingabe und validieren Sie sie wie jede externe Daten.

Quellen

1. Google for Developers Blog. "Ankündigung des A2A-Protokoll-Starts mit mehr als 50 Technologiepartnern." https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/. Abgerufen im August 2026.
2. The Linux Foundation. "Wachstum der GitHub-Stars des A2A-Repositorys und der SDK-Sprachen im ersten Jahr des Protokolls." https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year. Abgerufen im August 2026.
3. The Linux Foundation. "Wachstum der unterstützenden A2A-Organisationen von mehr als 50 auf über 150 im ersten Jahr." https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year. Abgerufen im August 2026.