Was ist Agent2Agent (A2A)? Wie KI‑Agenten kommunizieren und zusammenarbeiten

Agent2Agent (A2A) ist ein offenes Protokoll, das KI‑Agenten ermöglicht, einander zu entdecken, Nachrichten auszutauschen, Aufgaben zu delegieren, Fortschritte zu melden und Ergebnisse über Systemgrenzen hinweg zurückzugeben. Es ist für Situationen konzipiert, in denen ein Agent Hilfe von einem anderen benötigt, ohne dass eine Seite ihr internes Denken, Gedächtnis oder ihre Implementierung offenlegen muss.

Wenn Organisationen spezialisierte Agenten einsetzen, wird die Kommunikation zu einem Infrastrukturproblem. Ein Beschaffungs‑Agent kann Informationen von einem Compliance‑Agenten benötigen; ein Kundenservice‑Agent kann einen Logistik‑Agenten benötigen, um eine Sendung zu untersuchen. A2A bietet einen gemeinsamen Weg, diese Arbeit zu koordinieren, selbst wenn die Agenten unterschiedliche Frameworks, Anbieter oder Modelle verwenden.

Warum Agenten einen Kommunikationsstandard benötigen

Traditionelle APIs stellen Funktionen und Daten bereit, aber eine Agent‑zu‑Agent‑Interaktion kann offener sein. Der empfangende Agent muss möglicherweise ein Ziel interpretieren, entscheiden, wie es zu lösen ist, Nachfragen stellen, Minuten oder Stunden arbeiten, Updates streamen und mehrere Artefakte zurückgeben.

Ohne ein gemeinsames Protokoll würde jede Plattform eigene Formate für Identität, Fähigkeitsentdeckung, Aufgaben, Nachrichten, Status und Fehler definieren. Diese Fragmentierung erschwert die plattformübergreifende Delegation und sperrt nützliche Agenten in einzelnen Produkten ein.

A2A standardisiert die Kommunikationsebene, während jeder Agent als Black‑Box bleibt. Die aktuelle A2A‑Spezifikation definiert die Kernobjekte und Interaktionen des Protokolls.

Die Schlüsselrollen in A2A

Diese Trennung ist es, die A2A von einem einfachen Funktionsaufruf unterscheidet. Der entfernte Teilnehmer kann eine langlaufende Aufgabe verwalten, nach zusätzlichen Informationen fragen, unterstützte Inhaltstypen aushandeln und ein oder mehrere Artefakte zurückgeben. Der Client‑Agent verfolgt diese Aufgabe, während er die Identität und Autorität des Benutzers oder der Anwendung, die sie initiiert hat, bewahrt.

Eine A2A‑Interaktion umfasst in der Regel zwei logische Rollen:

• Client agent: der Agent oder die Anwendung, die Arbeit anfordert.
• Remote agent: der Agent, der die Anfrage empfängt und die Arbeit ausführt oder koordiniert.

Die Begriffe „Client“ und „Remote“ beschreiben die aktuelle Interaktion, nicht eine permanente Hierarchie. Derselbe Agent kann in einem Kontext Arbeit anfordern und in einem anderen Kontext einem anderen Agenten dienen.

Agent‑Karten: Fähigkeiten entdecken

Bevor eine Aufgabe delegiert wird, muss ein Client wissen, was ein Remote‑Agent kann und wie man mit ihm kommuniziert. A2A verwendet eine Agent‑Karte, um beschreibende und operationelle Metadaten zu veröffentlichen.

Eine Agent‑Karte kann den Namen eines Agenten, dessen Endpunkt, unterstützte Protokoll‑Features, Authentifizierungserwartungen, Fähigkeiten und akzeptierte Inhaltstypen beschreiben. Eine Fähigkeit ist ein deklarierter Kompetenzbereich, z. B. das Übersetzen eines Dokuments, das Prüfen eines Vertrags oder das Recherchieren eines Marktes.

Die Entdeckung beweist nicht Qualität oder Vertrauenswürdigkeit. Eine Agent‑Karte ist ein Anspruch auf Fähigkeit, keine unabhängige Zertifizierung. Produktionssysteme benötigen weiterhin Identität, Autorisierung, Richtlinienprüfungen, Reputation und Bewertung.

Nachrichten, Aufgaben und Artefakte

A2A stellt Zusammenarbeit durch mehrere Kernobjekte dar.

Nachrichten

Nachrichten transportieren die Kommunikation zwischen Agenten. Sie können Text und andere strukturierte Teile enthalten, sodass die Agenten Anweisungen, Klarstellungen oder kontextuelles Material austauschen können.

Aufgaben

Eine Aufgabe stellt eine Arbeitseinheit dar, deren Zustand sich im Laufe der Zeit ändern kann. Ein Remote‑Agent kann die Arbeit annehmen, die Verarbeitung fortsetzen, mehr Eingaben anfordern, sie abschließen, fehlschlagen oder abbrechen. Eine persistente Aufgabenidentität ist für langlaufende Vorgänge nützlich, da der Client auf denselben Job über Updates hinweg verweisen kann.

Artefakte

Artefakte sind die durch die Arbeit erzeugten Ergebnisse, wie ein Bericht, Datensatz, Bild, Code‑Patch oder strukturierte Empfehlung. Die Trennung von Artefakten und konversationellen Nachrichten erleichtert es dem Client, die endgültigen Lieferungen zu identifizieren und zu nutzen.

Wie eine A2A‑Interaktion funktioniert

Angenommen, ein Reiseplanungs-Agent benötigt einen Spezialisten, um Einreisebestimmungen zu überprüfen.

1. Der Client entdeckt einen entfernten Agenten und liest dessen Agentenkarte.
2. Er prüft, ob der Agent die relevante Fähigkeit und eine kompatible Interaktionsmethode anbietet.
3. Der Client authentifiziert sich und sendet eine Nachricht, die die Aufgabe, Reisenden, Daten und das gewünschte Ergebnis beschreibt.
4. Der entfernte Agent erstellt oder aktualisiert eine Aufgabe und beginnt mit der Arbeit.
5. Der entfernte Agent kann den Fortschritt streamen oder nach einer fehlenden Angabe fragen.
6. Der Client liefert die Klarstellung, während er den Aufgaben‑Kontext bewahrt.
7. Der entfernte Agent schließt die Aufgabe ab und gibt ein strukturiertes Artefakt mit seinem Ergebnis zurück.
8. Der Client bewertet dieses Ergebnis, bevor er es im übergeordneten Reiseplan verwendet.

Der entfernte Agent entscheidet, wie er seine Aufgabe erledigt. Er könnte seine eigenen Werkzeuge aufrufen, private Daten konsultieren oder zusätzliche Agenten koordinieren. A2A verlangt nicht, dass diese internen Schritte offengelegt werden.

A2A vs. MCP

Die Protokolle können auf verschiedenen Ebenen derselben Architektur liegen. Ein Reiseplanungs‑Agent könnte über A2A eine spezialisierte Visaforschungs‑Aufgabe delegieren. Dieser Spezialisten‑Agent könnte dann MCP‑Verbindungen nutzen, um zugelassene Datenbanken zu durchsuchen und Richtliniendokumente abzurufen. A2A koordiniert die Verantwortung zwischen Agenten; MCP standardisiert den Zugriff zwischen einem KI‑Host und Fähigkeiten.

A2A und das Model Context Protocol lösen unterschiedliche Integrationsprobleme.

• MCP verbindet eine KI‑Anwendung mit Werkzeugen und Kontext. Ein Client entdeckt Fähigkeiten wie Funktionen, Ressourcen und Eingabeaufforderungen von einem MCP‑Server.
• A2A verbindet Agenten mit Agenten. Ein Client delegiert eine zielorientierte Aufgabe an einen entfernten Agenten, der seinen eigenen Prozess verwalten und ein Ergebnis zurückgeben kann.

Der Unterschied ähnelt der Nutzung eines Werkzeugs gegenüber der Beauftragung eines Spezialisten. Ein Taschenrechner stellt eine Operation bereit; ein Analyst nimmt ein Ziel entgegen und entscheidet, welche Operationen benötigt werden. In realen Systemen kann ein entfernter A2A‑Agent MCP intern nutzen, um seine eigenen Werkzeuge und Daten zu erreichen.

A2A vs. gewöhnliche APIs

Eine konventionelle API ist ideal, wenn der Aufrufer die genaue Operation und das Eingabeformat kennt: einen Datensatz abrufen, ein Angebot berechnen oder ein Feld aktualisieren. A2A ist nützlich, wenn die Anfrage konversationell, zustandsbehaftet, asynchron oder ergebnisorientiert ist.

A2A ersetzt nicht jede API. Entfernte Agenten rufen häufig gewöhnliche APIs auf, um ihre Arbeit zu erledigen, und Organisationen können deterministische Dienste direkt bereitstellen, wenn die Agenten‑Entscheidungsfreiheit keinen Mehrwert bietet.

Warum Interoperabilität wichtig ist

Agenten‑Ökosysteme werden heterogen sein. Unterschiedliche Teams werden für verschiedene Domänen, Modelle, Sicherheitsgrenzen und Bereitstellungsumgebungen optimieren. Ein gemeinsames Protokoll ermöglicht es Organisationen, diese Spezialisierung zu bewahren und gleichzeitig Zusammenarbeit zu ermöglichen.

Interoperabilität kann auch die Kopplung von Integrationen verringern. Ein Client kann sich auf eine deklarierte Fähigkeit und das Protokollverhalten verlassen, anstatt das Framework des entfernten Agents zu importieren oder dessen interne Logik zu duplizieren. Die Übersicht des A2A-Projekts beschreibt dieses Ziel als die Ermöglichung, dass Agenten, die auf unterschiedlichen Stacks aufgebaut sind, als Peers kommunizieren; das Update des Projekts für 2026 über den Beitritt zur Agentic AI Foundation spiegelt den Vorstoß zu neutraler, branchenübergreifender Governance wider.

Sicherheits- und Vertrauensherausforderungen

Delegierung erzeugt eine Kette von Verantwortung. Der Client muss die Identität des entfernten Agents und dessen beworbene Fähigkeiten überprüfen, den geteilten Kontext minimieren und die Autorisierung des initiierenden Benutzers bewahren. Der entfernte Agent sollte nicht breitgefächerte Privilegien erben, nur weil ein anderer Agent die Aufgabe angefordert hat. Jeder Sprung erfordert Authentifizierung, abgegrenzte Anmeldeinformationen, Nachvollziehbarkeit und eine klare Regel dafür, was geschieht, wenn Anforderungen im Konflikt stehen oder das Vertrauen gering ist.

Agent-zu-Agent-Delegierung erzeugt eine Kette von Autorität. Ein Client kann versehentlich sensible Kontextinformationen teilen, einem entfernten Agenten mehr Ermessensspielraum geben als beabsichtigt, oder auf ein unzuverlässiges Artefakt reagieren. Der entfernte Agent kann zudem bösartige Anweisungen oder Dateien von einem nicht vertrauenswürdigen Client erhalten.

Starke Deployments benötigen Kontrollen auf mehreren Ebenen:

• Identität und Authentifizierung: prüfen, welcher Agent und welche Organisation beteiligt sind.
• Autorisierung: die für jeden Aufrufer verfügbaren Fähigkeiten, Daten, Aktionen und den Aufgabenbereich einschränken.
• Datenminimierung: nur den Kontext teilen, den der entfernte Agent benötigt.
• Herkunft: festhalten, wer die Arbeit angefordert hat, welcher Agent sie erzeugt hat und welche Quellen sie unterstützen.
• Ausgabevalidierung: entfernte Artefakte als nicht vertrauenswürdig behandeln, bis sie relevante Prüfungen bestehen.
• Delegationsgrenzen: steuern, ob ein entfernter Agent zusätzliche Agenten oder Dienste einbinden darf.
• Menschliche Genehmigung: bei finanziellen, rechtlichen, externen, destruktiven oder sonstigen folgehaltigen Aktionen pausieren.

Protokollkompatibilität impliziert nicht automatisch organisatorisches Vertrauen. Ein Agent kann A2A korrekt sprechen und dennoch für eine bestimmte Aufgabe ungeeignet sein.

Wann sollten Teams A2A einsetzen?

A2A ist besonders überzeugend, wenn unabhängige Agenten über Produkt-, Anbieter- oder Organisationsgrenzen hinweg zusammenarbeiten müssen; wenn die Arbeit langfristig ist; oder wenn das empfangende System die Freiheit behalten soll, wie es das Ergebnis erzeugt.

Es kann für eine einfache Funktion, einen festen internen Workflow oder eng gekoppelte Komponenten innerhalb einer Anwendung überflüssig sein. In solchen Fällen kann eine gewöhnliche API, ein Event‑Bus oder ein direkter Tool‑Aufruf einfacher zu betreiben und zu bewerten sein.

Was man über Agent2Agent (A2A) wissen sollte

A2A bietet eine gemeinsame Sprache, damit Agenten Fähigkeiten entdecken und zielgerichtete Arbeit koordinieren können, ohne ihre interne Funktionsweise zu teilen. Sein Kernwert liegt nicht darin, dass mehrere Agenten automatisch besser sind als einer, sondern dass unabhängig entwickelte Spezialisten über eine stabile Grenze hinweg zusammenarbeiten können.

Diese Grenze muss mehr als nur Nachrichten transportieren. Sie benötigt Identität, Aufgabenstatus, Artefakte, Berechtigungen, Herkunft und Fehlermanagement. A2A liefert die Protokollgrundlage; Organisationen stellen weiterhin das Vertrauensmodell bereit.