Kurz zusammengefasst
- A2A v1.0 ist die erste stabile Version des offenen Protokolls und unterstützt unter anderem HTTP+JSON, JSON-RPC und gRPC als Bindings.
- Agent Card, Message, Task und Artifact bilden die wichtigsten fachlichen Bausteine.
- Polling, Streaming und Push-Benachrichtigungen decken kurze wie auch länger laufende Aufträge ab.
- A2A beschreibt Kommunikation und Sicherheitsmechanismen, macht eine Agentenverbindung aber nicht automatisch vertrauenswürdig oder sicher.
Welche Bausteine verwendet A2A?
A2A behandelt den entfernten Agenten als eigenständigen Dienst. Der aufrufende Agent muss dessen interne Prompts, Modelle oder Tools nicht kennen. Er sieht stattdessen eine veröffentlichte Beschreibung der Fähigkeiten und tauscht standardisierte Objekte mit ihm aus.
Die Agent Card ist dabei eine Selbstauskunft und keine automatische Vertrauensgarantie. In A2A v1.0 kann sie signiert werden; ihre Herkunft, Signatur, Aktualität und die tatsächlich erlaubten Fähigkeiten müssen trotzdem durch die umgebende Plattform geprüft werden.
- Agent Card
- Beschreibt Identität, Endpunkte, unterstützte Protokollversionen, Fähigkeiten, Skills und angebotene Sicherheitsverfahren eines Agenten.
- Message
- Transportiert eine Eingabe, Rückfrage oder Antwort zwischen Client und Agent. Inhalte können aus mehreren Teilen wie Text, Dateien oder strukturierten Daten bestehen.
- Task
- Repräsentiert einen zustandsbehafteten Auftrag, dessen Bearbeitung länger dauern, Rückfragen benötigen oder abgebrochen werden kann.
- Artifact
- Ist ein vom Agenten erzeugtes Ergebnis, beispielsweise ein Bericht, eine Datei oder ein strukturiertes Datenset. Zwischenstand und finales Resultat müssen unterscheidbar bleiben.
Wie läuft eine A2A-Zusammenarbeit ab?
Eine kurze Anfrage kann unmittelbar mit einer Message beantwortet werden. Wird daraus ein länger laufender Auftrag, liefert der Agent einen Task mit Status und späteren Updates. Das Protokoll unterstützt damit nicht nur einen synchronen Frage-Antwort-Ablauf, sondern auch inkrementelle und asynchrone Bearbeitung.
- Schritt 1
Fähigkeit entdecken
Der Client liest eine Agent Card und prüft Version, Endpunkt, angebotene Skills, Sicherheitsverfahren und Vertrauenswürdigkeit.
- Schritt 2
Auftrag als Message senden
Ziel, Kontext und erlaubte Daten werden so knapp und strukturiert wie möglich übermittelt. Die Berechtigung wird ausserhalb des freien Nachrichtentexts durchgesetzt.
- Schritt 3
Message oder Task erhalten
Eine kurze Antwort kann direkt zurückkommen. Für längere Arbeit entsteht ein Task mit eindeutiger Kennung und nachvollziehbarem Zustand.
- Schritt 4
Fortschritt empfangen
Je nach Dauer und Infrastruktur nutzt der Client Polling, einen Streaming-Kanal oder Push-Benachrichtigungen und behandelt Wiederholungen idempotent.
- Schritt 5
Artifacts prüfen und übernehmen
Ergebnisse werden fachlich validiert, ihrer Task- und Agentenversion zugeordnet und erst danach in einen Folgeprozess übernommen.
Wie unterscheiden sich A2A, MCP und eine normale API?
Die drei Ansätze konkurrieren nicht zwingend. Sie lösen unterschiedliche Integrationsprobleme. Eine Architektur kann eine Fach-API als verlässliche Systemgrenze, MCP für die kontrollierte Tool-Nutzung innerhalb eines Agenten und A2A für die Delegation zwischen unabhängigen Agentendiensten kombinieren.
| Baustein | Verbindet | Geeignet für | Nicht seine Aufgabe |
|---|---|---|---|
| A2A | Eigenständige Agenten über System- oder Organisationsgrenzen | Fähigkeiten entdecken, Aufgaben delegieren, Status und Ergebnisse austauschen | Keine fachliche Berechtigung und kein Ersatz für interne Prozesskontrollen |
| MCP | AI-Anwendung oder Agent mit Tools, Ressourcen und Vorlagen eines Servers | Einheitlicher Zugriff auf bereitgestellte Fähigkeiten und Kontext | Keine allgemeine Koordination eigenständiger Agenten |
| Fach-API | Softwarekomponenten über explizite Endpunkte und Datenverträge | Stabile, testbare Systemaktionen und Abfragen mit klarer Semantik | Keine flexible Zielverhandlung oder agentische Aufgabenbearbeitung |
| Interner Funktionsaufruf | Komponenten derselben Anwendung | Enge, schnelle Integration unter gemeinsamer Kontrolle | Keine interoperable Grenze für unabhängige Anbieter oder Teams |
Wann lohnt sich A2A – und wann nicht?
A2A wird interessant, wenn zwei Agenten unabhängig betrieben, unterschiedlich implementiert oder organisatorisch getrennt verantwortet werden. Innerhalb einer einzelnen Anwendung erzeugt das Protokoll dagegen oft mehr Komplexität als Nutzen. Ein stabiler, vollständig spezifizierbarer Datenaustausch bleibt meist mit einer normalen API einfacher und besser testbar.
- Sinnvoll: Ein Einkaufsagent delegiert eine Lieferantenprüfung an einen separat verantworteten Compliance-Agenten.
- Sinnvoll: Mehrere Anbieteragenten sollen über eine gemeinsame, versionierte Grenze zusammenarbeiten.
- Sinnvoll: Eine Aufgabe dauert länger und benötigt Status, Rückfragen oder mehrere Ergebnisartefakte.
- Nicht nötig: Ein einzelner Agent ruft lediglich Datenbank-, Such- oder E-Mail-Tools auf – dafür passt häufig MCP oder eine direkte API.
- Nicht ideal: Ein deterministischer Systemprozess besitzt bereits einen stabilen API-Vertrag und braucht keine freie Aufgabendelegation.
Welche Kontrollen braucht A2A im Unternehmen?
TLS, Sicherheitsschemata und signierte Agent Cards schaffen technische Grundlagen, ersetzen aber keine Vertrauensentscheidung. Der empfangende Agent muss jeden Aufruf authentisieren und für die konkrete Ressource und Aktion autorisieren. Auch ein korrekt identifizierter Partner darf nur die minimal erforderlichen Daten und Fähigkeiten erhalten.
A2A v1.0 bringt Versionsverhandlung und mehrere Bindings mit. Unternehmen sollten dennoch zulässige Versionen und Erweiterungen festlegen, Kompatibilität testen und einen kontrollierten Migrationsweg vorsehen. Protokollversion, Agent-Version aus der Agent Card, Task, Identität, Freigaben und Artifacts gehören gemeinsam in die technische Nachvollziehbarkeit.
| Kontrolle | Konkrete Umsetzung | Zu prüfender Fehlerfall |
|---|---|---|
| Identität und Authentisierung | Serverzertifikat und Agent-Card-Herkunft prüfen; Client mit geeignetem Verfahren wie OAuth 2.0 oder mTLS authentisieren | Unbekannter oder imitierter Agent verwendet eine bekannte Agent Card |
| Autorisierung und Least Privilege | Rechte pro Mandant, Skill, Datentyp und Aktion durchsetzen; keine pauschale Weitergabe der Nutzerrechte | Legitimer Agent fordert Daten ausserhalb seines Auftrags an |
| Datenminimierung | Nur erforderliche Message-Teile und Artifacts übertragen; sensible Felder klassifizieren und filtern | Ein Zwischenstand enthält unnötige Kunden- oder Zugangsdaten |
| Protokollierung | Task-Verlauf, Statuswechsel, aufrufende Identität, Freigaben, Versionen und Ergebnisübernahme korrelierbar erfassen | Ein Artifact lässt sich später keinem Auftrag und keiner verantwortlichen Instanz zuordnen |
| Versionierung und Ausfall | Unterstützte Versionen festlegen, Vertragstests durchführen, Zeitlimits, Abbruch und Wiederholungen kontrollieren | Ein Update verändert Feldsemantik oder ein Retry führt eine Aktion doppelt aus |
Beispiel: Lieferantenprüfung über zwei Agentensysteme
Ein Beschaffungsagent erstellt aus einer Anfrage einen strukturierten Prüfauftrag. Über die signierte Agent Card findet er den freigegebenen Compliance-Agenten und sendet nur Lieferanten-ID, Land, Prüfzweck und benötigte Frist. Der Compliance-Agent erzeugt einen Task, meldet fehlende Angaben zurück und liefert später einen Prüfbericht als Artifact. Der Beschaffungsagent darf den Bericht anzeigen, aber keine Sperre aufheben. Identitäten, Versionen, Statuswechsel und die menschliche Freigabe werden protokolliert. Direkte ERP-Buchungen erfolgen weiterhin über eine eng begrenzte Fach-API.
Was Sie mitnehmen sollten
Setzen Sie A2A dort ein, wo unabhängige Agenten wirklich Aufgaben und Ergebnisse austauschen müssen. Verwenden Sie MCP für Tools und Kontext sowie Fach-APIs für stabile Systemaktionen – und behandeln Sie jede Agentengrenze wie eine reguläre, sicherheitskritische Serviceintegration.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft