Loading content
Das Agent2Agent Protocol definiert eine herstellerunabhängige Sprache, mit der eigenständige Agentenanwendungen Fähigkeiten bekannt machen, Aufgaben delegieren und Ergebnisse austauschen. Es beschreibt Interoperabilität zwischen Agenten und ergänzt Protokolle wie MCP, die den Zugriff auf Werkzeuge, Datenquellen und externe Systeme strukturieren.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Das Agent2Agent Protocol (A2A) ist ein offener Standard, der die Kommunikation, Zusammenarbeit und Aufgabenübergabe zwischen eigenständigen KI-Agenten festlegt.
A2A wurde ursprünglich von Google entwickelt und anschließend an die Linux Foundation übergeben. Es ist als quelloffenes, herstellerunabhängiges Kommunikationsprotokoll ausgerichtet und wird durch ein Technical Steering Committee mit Beiträgen u. a. von AWS, Cisco, IBM Research, Microsoft, Salesforce, SAP und ServiceNow sowie eine Community gepflegt; die Lizenz ist Apache License 2.0. In seiner Konzeption setzt A2A bewusst auf eine agent-to-agent Ebene, die zusammen mit MCP (für agent-to-tool) genutzt wird.
Stell dir A2A als „Agenten-Netzwerkvertrag“ vor, der statt Tool-Aufrufen Agenten als opake Gegenstellen kapselt. Schrittfolge: (1) Ein Client-Agent findet einen Remote-Agenten über dessen Agent Card (JSON-Metadaten unter /.well-known/agent-card.json) und liest daraus Fähigkeiten, Endpoint und Sicherheitsschemata. (2) Der Client authentifiziert sich gemäß dieser Security Scheme (z. B. per JWT) und sendet Nachrichten. (3) Der Remote-Agent übersetzt eine Nachricht in eine Task mit definiertem Lebenszyklus (z. B. submitted → working → completed/failed/canceled). (4) Fortschritt wird typischerweise asynchron gestreamt (u. a. über Server-Sent Events), und Ergebnisse kommen als Artifacts zurück, ohne interne Memory/Tools/Reasoning des Remote-Agenten offenzulegen. So können Agenten über Framework-, Laufzeit- und Systemgrenzen hinweg wie „fern aufrufbare Dienste“ zusammenarbeiten.
Agenten bewerben ihre Fähigkeiten und Konnektivität über eine Agent Card, sodass ein Aufrufer ohne Code-Lesen entscheiden und gezielt adressieren kann.
Eine Task ist die ID-basierte Vertragseinheit für Arbeit mit klaren Zuständen von Annahme bis Abschluss oder Fehlschlag.
Messages tragen Nutzlasten/Kommunikationszüge; Artifacts sind die zurückgelieferten Ergebnisse (z. B. Dokumente oder Daten) für eine Task.
Aufrufer behandeln Remote-Agenten als nicht vertrauenswürdig genug, bis Authentifizierung erfolgt ist; interne Logik bleibt verborgen, während nur Fähigkeiten und Ergebnisse sichtbar sind.
Fortschritt und mehrstufige Jobs laufen typischerweise asynchron und werden per Streaming-Mechanismen an den Client zurückgemeldet.
A2A hilft, wenn Agenten aus verschiedenen Teams, Anbietern oder Frameworks über System- und Vertrauensgrenzen hinweg zusammenarbeiten sollen, ohne interne Prompts, Tools oder Memory zu teilen. Es ist besonders passend für Delegation und koordinierte Teilaufgaben, bei denen ein Agent einen anderen als entfernten Spezialisten anspricht. Grenzen/Trade-offs: Für einfache Abfragen, die wie ein lokaler Tool-Aufruf wären, kann A2A Latenz und Kosten unnötig vervielfachen. Wenn Vertrauensgrenzen verwischt werden, drohen Sicherheitsprobleme—daher müssen Identität und Rechte pro A2A-Interaktion abgesichert werden. Außerdem sollte der Client den Task-Lifecycle asynchron behandeln (statt auf eine einzige synchrone Antwort zu blockieren), sonst entstehen Zeitouts oder unvollständige Fortschrittskommunikation.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.