A2A erklärt

Wäre KI emotionsfähig, würde sie A2A wahrscheinlich lieben.Anton Brehov | shutterstock.com



In gewissem Sinn ähnelt das Agent2Agent-Protokoll (A2A) dem Web selbst: Es bietet eine gemeinsame Protokollschicht, über die heterogene Systeme mittels standardisierter Anfragen und Antworten kommunizieren und zusammenarbeiten können. Eingeführt wurde die Open-Source-Spezifikation im April 2025 von Google. Das Ziel des Konzerns: Interoperabilität im wachsenden Ökosystem autonomer Agenten zu fördern und diese plattformübergreifend miteinander zu verbinden. Außerdem sollen Entwicklern mit A2A die Integrationsprobleme früher Agentic-AI-Initiativen erspart bleiben.



In diesem Grundlagenartikel lesen Sie:




wie A2A funktioniert,



worin der Unterschied zu Model Context Protocol (MCP) besteht,



welche Datenformen und Designprinzipien für A2A zentral sind,



wie es um die Sicherheit des Protokolls bestellt ist, und



wie Agent2Agent in der Unternehmenspraxis aussieht.




Wie Agent2Agent funktioniert



Die meisten KI-Agenten von heute wurden als isolierte Systeme aufgebaut. Jedes davon verfügt über ein eigenes Framework, eigene API-Konventionen und Annahmen. Agent2Agent ist ein offenes, herstellerneutrales Protokoll, das autonome KI-Agenten dazu befähigt:




miteinander zu kommunizieren,



sich untereinander zu koordinieren, sowie



Tasks aneinander zu delegieren.




Damit verlagert das Protokoll den Fokus von einem einzelnen monolithischen Agenten auf kollaborative Multi-Agenten-Teams, die komplexe (Business-)Workflows übernehmen. Um sichere, nicht einsehbare (dazu gleich mehr) Interoperabilität zu gewährleisten, regelt das Protokoll die Kommunikation zwischen den Agenten und verwendet dazu strukturierte Datenformen. Das Ziel von A2A besteht dabei nicht darin, bestehende Standards neu zu erfinden. Vielmehr soll es die Lücke schließen zwischen der Art und Weise, wie Agenten Tasks ausführen und der, wie sie dabei zusammenarbeiten.



Die gemeinsame Grundlage, die Agent2Agent für Discovery, Messaging und Task-Delegation schafft, macht es Unternehmen möglich, KI-Agenten verschiedener Anbieter und Entwickler an mehrstufigen Workflows kollaborieren zu lassen – ohne benutzerdefinierte Middleware. Anstatt einen monolithischen “Superagent” zu entwickeln, können Anwender mit A2A ein Netzwerk spezialisierter KI-Agenten aufbauen, die sich von Anfang an verstehen und auch mit externen Agenten kommunizieren können.



Agent2Agent ist als Protokoll-Layer für Interoperabilität konzipiert, nicht als Laufzeit-, Modell- oder Orchestrierungs-Framework. Es definiert über eine klare Handshake- und Message-Struktur, die jedes kompatible System verwenden kann, wie die Agenten untereinander kommunizieren und Informationen austauschen. Dabei bleibt allerdings jeder kommunizierende KI-Agent für den jeweils anderen eine Black Box (Google nennt das “opaque”, also nicht einsehbar).



Die Spezifikation setzt dabei bemerkenswerterweise nicht zwingend voraus, dass ein Agent auch ein KI-System sein muss. Jeder Prozess – oder Mensch – kann als ein solcher fungieren, solange er ordnungsgemäß formatierte Messages empfangen kann. Ein menschlicher Benutzer, der einen Workflow wie den Mechanical Turk ausführt, kann also theoretisch ein A2A-Agent sein, wenn er sich an die Struktur des Protokolls hält. Diese Anpassungsfähigkeit macht A2A skalierbar und erweitert sein Anwendungsgebiet über einfache Demo-Agenten hinaus auf Enterprise-Umgebungen.  



A2A vs. MCP



Dass sowohl Agent2Agent als auch Model Context Protocol (MCP) darauf abzielen, den Informationsaustausch zwischen KI-Systemen zu standardisieren, könnte zu Verwirrung führen. Allerdings arbeiten die Protokolle auf unterschiedlichen Ebenen des gerade neu entstehenden Agenten-Stacks:




MCP definiert, wie ein einzelner Agent mit Tools, Datenquellen und Ausführungskontexten verbunden ist. Es standardisiert zudem, wie ein Agent verfügbare Funktionen – etwa APIs, Dateien oder Datenbanken – findet und sicher aufruft. Im Wesentlichen geht es also darum, dass Agenten ihre Reichweite vergrößern.



Im Gegensatz dazu regelt A2A, wie Agenten miteinander kommunizieren. Und ermöglicht diesen – trotz jeweils unterschiedlicher Frameworks oder Modelle – strukturierte Tasks anzufordern, den Fortschritt zu überwachen und Ergebnisse zu liefern, ohne die interne Logik des jeweils anderen zu verstehen.




Anders ausgedrückt: MCP verbindet Agenten mit ihrer Umgebung, während Agent2Agent die Agenten selbst miteinander verbindet. Zusammen bilden sie komplementäre Teile derselben Architektur: MCP macht einzelne Agenten leistungsfähiger, A2A ermöglicht ganze Agenten-Netzwerke.



A2A-Datenformen



Das Agent2Agent-Protokoll organisiert die Kommunikation anhand von vier primären Objekttypen. Jeder repräsentiert dabei eine bestimmte Phase im Workflow.




Die Agent Card ist eine kleine JSON-Datei (agent.json), die die Identität, Fähigkeiten, Authentifizierungsmethoden und optional auch digitale Signatur eines Agenten öffentlich beschreibt. Andere Agenten lesen diese – etwa, um Trust zu verifizieren.



Ein Task ist ein strukturierter Work Request, der eine eindeutige task_id, einen Input-Payload sowie Metadaten zu Prioritäten oder erforderlichen Modalitäten enthält. Der Task definiert, was zu tun ist und dient als Anker für die gesamte nachfolgende Kommunikation.



Die Message ist ein Stream von Status-Updates und Zwischeninformationen zum Task. Messages enthalten Fortschrittsanzeigen, Requests für zusätzlichen Input oder kontextbezogene Notizen und werden in der Regel über SSE oder gRPC-Streams übertragen.



Das Artifact ist das Ergebnis des abgeschlossenen Tasks. Artifacts können Text, Dateien oder strukturierte Daten enthalten. Sie schließen die Transaktion ab und können gespeichert, validiert oder zur weiteren Verarbeitung mit einem anderen Task verkettet werden.




Bei einem typischen A2A-Austausch ruft der anfragende Agent zunächst eine Agent Card ab, um die Fähigkeiten und unterstützten Protokolle eines anderen Agenten zu bestätigen. Der anfragende Agent wird als Client bezeichnet. Sein Gegenüber als Server. Dabei handelt es sich jedoch nicht um dauerhafte Zustände: Ein Agent kann in einem Kontext als Client und in einem anderen als Server agieren – und die Rollen können im Laufe einer einzelnen Interaktion wechseln.



In jedem Fall sendet der Client-Agent eine createTask-Anfrage, die der Server-Agent durch die Rückgabe einer task_id bestätigt. Während der Task ausgeführt wird, überträgt der Server-Agent Message-Objekte, die den Status anzeigen oder um Klarstellung bitten. Ist die Aufgabe abgeschlossen – oder schlägt fehl – gibt der Server ein oder mehrere Artifact-Objekte zusammen mit einem Completion Code aus.



Weil jeder Schritt dem gleichen Schema folgt, kann jeder kompatible Agent ohne benutzerdefinierte Adapter an dieser Konversation teilnehmen. Ein LLM-basierter Planungs-Agent könnte einen Datenerfassungs-Task an einen Python-Microservice delegieren. Dieser könnte wiederum einen Human-in-the-Loop-Agenten dazu veranlassen, den Output zu überprüfen – wobei die gesamte Kommunikation über A2A-Messages erfolgt.



Agent2Agent-Designprinzipien



Das A2A-Protokoll wendet zahlreiche bewährte Prinzipien an, die bereits von Standards wie HTTP, REST oder OAuth bekannt sind, auf die Welt der autonomen Systeme an.




Interoperabilität: A2A ist ausdrücklich Framework-unabhängig. Agenten, die in beliebigen Sprachen oder Frameworks geschrieben sind können über dasselbe standardisierte Nachrichtenschema kommunizieren. Diese Entkopplung von Implementierung und Interaktion ermöglicht Multi-Agent-Ökosysteme.



Transparenz: Jeder Agent legt seine Funktionen und Grenzen durch eine strukturierte Agent Card offen, die als eine Art Fähigkeitsbeschreibung fungiert. Diese Transparenz ermöglicht es anderen Agenten, potenzielle Kooperationspartner zu finden und zu bewerten, ohne Zugriff auf deren Quellcode oder eine zusätzliche Integration.



Sicherheit: Authentifizierung, Autorisierung und Message-Integrität sind zentrale Bestandteile der Spezifikation. Agent2Agent unterstützt mehrere Authentifizierungsmethoden. Jeder Task und jede Message wird zudem nachgehalten, wodurch ein überprüfbarer Datensatz der Agenten-Aktivitäten entsteht.



Modularität: Das Protokoll behandelt jeden Agenten als “opaque service” mit genau definierten In- und Outputs. Agenten können ihre Funktionen untereinander wiederverwenden und sie ohne manuelle Verkettung zu längeren Workflows verknüpfen. Diese Modularität spiegelt das kombinierbare Design von APIs und Microservices wider.



Skalierbarkeit und Resilienz: Agent2Agent wurde für asynchrone, verteilte Umgebungen entwickelt. Agenten können langlaufende Aufgaben generieren, Teilergebnisse streamen und sich von vorübergehenden Netzwerkausfällen erholen. Weil das Protokoll das Laufzeitverhalten nicht diktiert, lässt es sich auf natürliche Weise von ein paar lokalen auf Hunderte von Cloud-basierten Agenten skalieren, die domänenübergreifend koordiniert werden.




In Kombination machen diese Prinzipien das A2A-Protokoll zu einer gemeinsamen Sprache für verteilte Intelligenz. Diese kann sich mit Agenten, Frameworks und Kommunikationstechnologien weiterentwickeln.



Wie sicher ist A2A?



Sicherheit funktioniert bei Agent2Agent auf zwei Ebenen:




der Protokollintegrität und



dem Vertrauen zwischen den Agenten.




Die Spezifikation enthält dieselben Sicherheitsvorkehrungen, die auch Web-Scale-APIs schützen – Authentifizierung, Autorisierung und Verschlüsselung. Dazu kommen Funktionen, mit denen autonome Systeme die Zuverlässigkeit anderer Systeme bewerten und darauf reagieren können. Wie bereits erwähnt, können Agent Cards auch digitale Signaturen enthalten. Das ermöglicht Client-Agenten, die Organisation zu überprüfen, die den Server-Agenten erstellt hat, bevor eine Verbindung aufgebaut wird. 



Sobald die Kommunikation beginnt, werden Tasks und Messages über sichere Kanäle – in der Regel HTTPS, gRPC oder WebSockets – ausgetauscht. Sämtliche Payloads sind also während ihrer Übertragung verschlüsselt. Darüber hinaus definiert das A2A-Protokoll eindeutige Antwort-Codes und Event Logs, was einen Audit Trail schafft, der sich in Observability-Tools integrieren lässt. Auch Error-Handling-Mechanismen sind in Form von Fehlercodes und -meldungen integriert. Wird eine solche zurückgegeben, ist es “on the fly” möglich, auf einen anderen, zuverlässigeren Agenten zu wechseln. Dabei wirken sich wiederholte Fehler auch auf die Vertrauensreputation von Agenten aus.



Dieses selbstregulierende Verhalten ist für große Multi-Agenten-Systeme unerlässlich, in denen kein zentraler Controller jeden Teilnehmer überprüfen kann. Das Vertrauensmodell von A2A ermöglicht es, leistungsschwache oder schadhafte Agenten automatisch zu isolieren, während zuverlässige Agenten durch erfolgreiche Interaktionen an Glaubwürdigkeit gewinnen. Dennoch wirft das offene Design von A2A auch Fragen auf. Etwa:




Wie sollten Unternehmen Drittanbieter-Agenten authentifizieren, die bestimmte Fähigkeiten beanspruchen?



Was passiert, wenn zwei Agenten ein Schema unterschiedlich interpretieren?



Was, wenn ein Agent durch eine fehlerhafte Nachricht sensible Daten preisgibt?




Identitätsbetrug, Modell-Halluzinationen und Versionskonflikte stellen potenzielle Risiken dar, denen Unternehmen mit Governance-Frameworks begegnen sollten. Für die allermeisten Implementierungen erfordert die A2A-Sicherheit eine Kombination aus protokollbasierten und operativen Kontrollmaßnahmen. Das beinhaltet:




signierte Agent Cards zwingend vorauszusetzen,



API-Keys oder OAuth-Token über einen zentralen Broker zu managen, und



Reputationsdatenbanken zu pflegen, die die Zuverlässigkeit der Agenten in der gesamten Umgebung erfassen.




Im Laufe der Zeit könnten sich diese Praktiken zu standardisierten Trust-Registern entwickeln, die den Zertifizierungsstellen im weltweiten Netz ähneln. Das würde die Grundlage schaffen für sichere, überprüfbare Agenten-Ökosysteme.



Agent2Agent-Praxisbeispiele



Das Agent2Agent-Protokoll wird von diversen Unternehmen unterstützt, die als Kontributoren auftreten. Dazu gehören unter anderem SAP, ServiceNow, Atlassian, Box, Salesforce und Oracle – sowie diverse große Beratungsunternehmen wie Deloitte, PWC, Capgemini und die Boston Consulting Group. Auch Microsoft kündigte inzwischen A2A-Support für seine Plattformen Azure AI Foundry und Copilot Studio an.



Mit Blick auf reale Implementierungen gibt es zwar noch keine vollständig dokumentierten, großangelegten Projekte. Etwas kleiner dimensionierte Beispiele unterstreichen aber, dass dem Protokoll in Enterprise-Ökosystemen eine bedeutende Akzeptanz über die Pilotphase hinaus zukommt. Beispielsweise:  




koordinieren sich KI-Agenten bei Box über A2A-kompatible Endpunkte mit anderen Agenten auf Dutzenden von Plattformen.



nutzt Twilio A2A-Extensions um Latenz-Informationen zu übertragen, was ein intelligentes Routing zwischen Agenten und eine reibungslose Degradation ermöglicht, wenn nur langsamere Agenten verfügbar sind.




Die große Hoffnung ist, dass A2A nicht nur ein weiteres KI-Hype-Protokoll ist, sondern sich zu einem grundlegenden Kommunikations-Layer für Multi-Agenten-Ökosysteme entwickelt. Die Vorzeichen sehen gut aus – und Unternehmen, die sich jetzt mit Agent Cards, Task-Definition und Event Streaming beschäftigen, können sich einen Vorsprung erarbeiten. (fm)