Kurz erklärt
Was bedeutet Agent2Agent?
A2A schafft eine gemeinsame Außenschnittstelle zwischen Agenten. Zwei Agenten müssen nicht dasselbe Framework, dasselbe Modell oder denselben Anbieter verwenden. Entscheidend ist, dass Client und Server die vereinbarten A2A-Strukturen und Interaktionsmuster verstehen.
Das Protokoll wurde ursprünglich von Google initiiert und wird inzwischen als offenes Projekt im Umfeld der Linux Foundation und der Agentic AI Foundation weiterentwickelt. Im April 2026 meldete die Linux Foundation mehr als 150 unterstützende Organisationen und produktive Einsätze in mehreren Branchen. Für die technische Bewertung bleibt jedoch die aktuelle A2A-Spezifikation maßgeblich.
Warum A2A?
Das Problem: Jeder Agent spricht sonst seine eigene Sprache
Ein Unternehmen kann mehrere spezialisierte Agenten betreiben: einen Service-Agenten, einen Recherche-Agenten, einen Coding-Agenten oder einen Agenten für Vertragsprüfung. Ohne gemeinsamen Standard braucht jede Verbindung eigene Integrationslogik: Wie findet der eine Agent den anderen? Welche Fähigkeiten bietet er? Welche Formate akzeptiert er? Wie wird eine länger laufende Aufgabe verfolgt? Wie wird ein Ergebnis zurückgegeben?
A2A versucht, genau diese Schnittstelle zu standardisieren. Der Agent bleibt intern eine Black Box: Er kann ein eigenes Modell, eigene Tools, eigene Prompts oder eigene Orchestrierung verwenden. Für den aufrufenden Agenten zählt die veröffentlichte Schnittstelle.
A2A standardisiert Zusammenarbeit zwischen Agenten. Es macht einen Agenten nicht automatisch besser, autonomer oder sicherer.
Kernbegriffe
Agent Card, Task, Message, Part und Artifact
Digitale Visitenkarte
Ein JSON-Dokument beschreibt Identität, Anbieter, Endpunkte, Fähigkeiten, Skills, Ein-/Ausgabeformate und Sicherheitsanforderungen eines Agenten.
Zustandsbehaftete Arbeit
Eine Task repräsentiert eine länger laufende Arbeitseinheit mit eigener ID und Lebenszyklus. So kann ein Client Status und Ergebnisse später erneut abrufen.
Kommunikation
Messages transportieren Anweisungen, Rückfragen, Kontext oder Statusinformationen zwischen Client und Agent.
Inhaltsbaustein
Parts können Text, Binärdaten, URLs oder strukturierte Daten tragen und ermöglichen unterschiedliche Modalitäten.
Konkretes Ergebnis
Artifacts sind greifbare Outputs einer Task, etwa Dokumente, Dateien oder strukturierte Daten. Sie können auch schrittweise geliefert werden.
Discovery
Die Agent Card beschreibt, was ein Agent anbietet
Die Agent Card ist einer der zentralen Bausteine von A2A. Ein Client kann daraus lesen, welcher Agent angesprochen wird, welche Skills er anbietet, welche Ein- und Ausgabeformate unterstützt werden, welche A2A-Fähigkeiten vorhanden sind und welche Sicherheitsanforderungen gelten.
Für öffentlich auffindbare Agenten beschreibt die A2A-Dokumentation eine standardisierte well-known-URL wie /.well-known/agent-card.json. Daneben sind private Registries, Konfigurationen oder andere Discovery-Verfahren möglich. Gerade in Unternehmen ist dynamische öffentliche Discovery nicht zwingend sinnvoll; sensible Agent Cards können interne Endpunkte oder Skills verraten und sollten entsprechend geschützt werden.
{
"name": "Research Agent",
"supportedInterfaces": […],
"capabilities": { "streaming": true },
"securitySchemes": { … },
"skills": [ … ]
}Ablauf
Wie läuft eine A2A-Kommunikation typischerweise ab?
- Agent entdecken.
Der Client erhält oder findet die Agent Card des Zielagenten und prüft Skills, Endpunkt, Protokollversion und Sicherheitsanforderungen.
- Vertrauen und Zugriff klären.
Authentifizierung und Autorisierung werden über etablierte Web- beziehungsweise Enterprise-Mechanismen hergestellt; Credentials gehören nicht in den eigentlichen Aufgabeninhalt.
- Message senden.
Der Client übermittelt eine Nachricht mit Aufgabe und Kontext. Der Server kann unmittelbar mit einer Message antworten oder für komplexere Arbeit eine Task erzeugen.
- Status verfolgen.
Bei längeren Tasks kann der Client pollen, einen Stream abonnieren oder – wenn unterstützt – Push-Benachrichtigungen erhalten.
- Ergebnis übernehmen.
Der Agent liefert Messages oder Artifacts. Der Client entscheidet anschließend, wie das Ergebnis im eigenen Workflow weiterverarbeitet wird.
Lange Aufgaben
Polling, Streaming und Push Notifications
A2A ist nicht nur für kurze Frage-Antwort-Interaktionen gedacht. Die aktuelle Dokumentation beschreibt mehrere Muster für länger laufende Aufgaben:
Der Client sendet eine Aufgabe und fragt den Task-Status bei Bedarf erneut ab. Das ist einfach und eignet sich für viele klassische Integrationen.
Wenn ein Agent Streaming unterstützt, kann der Client laufend Status- und Artifact-Updates empfangen. Die Fähigkeit wird in der Agent Card deklariert.
Für sehr lange oder entkoppelte Abläufe kann der Server Änderungen an einen konfigurierten Webhook senden, sofern Push Notifications unterstützt werden.
Diese Muster sind für agentische Workflows wichtig, weil eine Aufgabe Minuten oder länger dauern und zwischendurch zusätzliche Eingaben benötigen kann. A2A modelliert deshalb nicht nur einen HTTP-Aufruf, sondern einen nachvollziehbaren Task-Lebenszyklus.
A2A vs. MCP
A2A und MCP lösen unterschiedliche Probleme
Die offizielle A2A-Dokumentation beschreibt MCP als eher vertikale Integrationsschicht und A2A als horizontale Verbindung zwischen unabhängigen Agenten. Ein Agent kann also MCP verwenden, um auf interne Werkzeuge zuzugreifen, und gleichzeitig A2A, um Aufgaben an einen anderen Agenten zu delegieren.
Security
Ist A2A sicher?
A2A ist kein Sicherheitszertifikat. Das Protokoll definiert Interoperabilität und beschreibt Sicherheitsmechanismen, setzt aber weiterhin auf etablierte Web-Sicherheitspraktiken. Die aktuelle Spezifikation sieht verschlüsselte Kommunikation für produktive Deployments vor; Authentifizierungsanforderungen werden in der Agent Card beschrieben und Credentials typischerweise über den Transport beziehungsweise HTTP-Header übertragen.
Für Unternehmen ergeben sich daraus mehrere Prüfbereiche: Serveridentität, Authentifizierung, Autorisierung, Token-Scopes, Netzwerkgrenzen, Schutz der Agent Card, erlaubte Skills und die Frage, welche Daten überhaupt an einen Remote-Agenten weitergegeben werden dürfen.
Interne URLs, Skills oder weitere Metadaten können sensibel sein. Erweiterte Karten sollten bei Bedarf authentifiziert ausgeliefert werden.
Statische Secrets gehören nicht in Agent Cards oder Aufgabeninhalte. Zugriff sollte über etablierte Authentifizierungsmechanismen erfolgen.
Ein fremder Agent sollte nur den Kontext erhalten, den er für die delegierte Aufgabe tatsächlich benötigt.
Auch ein authentifizierter Agent kann fehlerhafte oder unerwartete Ergebnisse liefern. Kritische Folgeaktionen brauchen eigene Regeln oder Freigaben.
Mehr zu Berechtigungen, Human Approval, Prompt Injection und Auditierbarkeit steht in der AgentenCode-Referenz zur KI-Agenten-Sicherheit.
Stand 2026
Wie weit ist A2A inzwischen verbreitet?
A2A wurde 2025 von Google vorgestellt und anschließend als offenes Projekt an die Linux Foundation übergeben. Im April 2026 berichtete die Linux Foundation von mehr als 150 unterstützenden Organisationen, Integrationen in große Cloud-Plattformen und ersten produktiven Einsätzen. Im August 2026 wurde A2A außerdem als Growth-Stage-Projekt in die Agentic AI Foundation aufgenommen.
Diese Entwicklung zeigt, dass A2A nicht mehr nur ein experimentelles Konzept ist. Sie bedeutet aber nicht, dass jeder Agent oder jede Plattform A2A vollständig unterstützt. Für AgentenCode zählt deshalb weiterhin die produktbezogene Evidenz: A2A-Unterstützung, Client-Rolle und Server-Rolle werden getrennt dokumentiert und nur bestätigt, wenn eine belastbare Primärquelle sie für den konkreten Agenten belegt.
Praxis
Wann ist A2A sinnvoll – und wann nicht?
Spezialisierte Agenten
Ein Orchestrator delegiert Teilaufgaben an Agenten mit klar abgegrenzten Skills, etwa Recherche, Support oder Codeanalyse.
Anbietergrenzen
Agenten verschiedener Teams, Frameworks oder Anbieter sollen über eine gemeinsame Schnittstelle zusammenarbeiten.
Lange Aufgaben
Aufträge brauchen Status, Zwischenstände, Rückfragen oder asynchrone Ergebnislieferung.
Ein einzelner Agent
Wenn ein Agent lediglich interne Tools nutzt und keine unabhängigen Agenten anspricht, kann MCP oder eine klassische API völlig ausreichen.
Einfacher Funktionsaufruf
Für eine stabile, eng definierte Systemintegration kann eine direkte API einfacher und kontrollierbarer sein.
Nur „Multi-Agent“ im Marketing
Mehrere interne Subagenten bedeuten nicht automatisch A2A. Entscheidend ist die dokumentierte Protokollunterstützung.
Unternehmens-Checkliste
A2A vor dem produktiven Einsatz prüfen
- Rolle klären.
Ist das Produkt A2A-Client, A2A-Server oder beides?
- Agent Card prüfen.
Welche Skills, Endpunkte, Protokollversionen, Ein-/Ausgabeformate und Sicherheitsanforderungen werden tatsächlich veröffentlicht?
- Discovery-Modell festlegen.
Öffentliche well-known-URL, private Registry oder kontrollierte Konfiguration?
- Authentifizierung definieren.
Wie werden Identität und Credentials beschafft, erneuert und entzogen?
- Autorisierung begrenzen.
Welche Agenten dürfen welchen Remote-Agenten und welche Skills aufrufen?
- Datenminimierung anwenden.
Nur Kontext übertragen, der für die delegierte Aufgabe erforderlich ist.
- Task-Lifecycle planen.
Polling, Streaming oder Push passend zur erwarteten Laufzeit und Infrastruktur auswählen.
- Timeouts und Abbruch definieren.
Was passiert, wenn ein Remote-Agent nicht antwortet oder eine Task hängen bleibt?
- Artifacts validieren.
Ergebnisse externer Agenten nicht automatisch als vertrauenswürdige Eingabe für kritische Aktionen behandeln.
- Audit Trail sicherstellen.
Delegation, Identität, Zielagent, Task-ID, Status und Ergebnis sollten nachvollziehbar bleiben.
- Versionen beobachten.
Protokoll- und Agent-Card-Änderungen können bestehende Integrationen beeinflussen.
- Fallback vorsehen.
Definieren, wie der Workflow bei Nichterreichbarkeit oder Inkompatibilität weiterläuft.
AgentenCode
Wie AgentenCode A2A dokumentiert
AgentenCode trennt drei Aussagen bewusst voneinander: A2A unterstützt, A2A Client und A2A Server. Ein Produkt kann beispielsweise andere Agenten aufrufen, ohne selbst als A2A-Endpunkt erreichbar zu sein. Eine allgemeine Formulierung wie „A2A-ready“ reicht deshalb nicht automatisch als Beleg für alle drei Felder.
Ein aktuelles Beispiel ist Gemini CLI: Im offiziellen Repository ist ein eigenes A2A-Server-Paket dokumentiert. Dadurch konnte AgentenCode die Server-Rolle als eigenen Field-Level-Claim ergänzen. Fehlt eine belastbare Quelle, bleibt ein A2A-Feld unknown und wird nicht als „Nein“ interpretiert.
A2A als Anforderung
Agenten mit dokumentierter Protokoll-Evidenz vergleichen.
AgentenFit kann A2A-, MCP-, API-, Hosting-, Security- und Governance-Anforderungen gegen die vorhandene Field-Level-Evidenz prüfen.
Primärquellen
Grundlage dieser A2A-Referenz
- A2A Protocol – Core Concepts ↗Agent Card, Task, Message, Part, Artifact und Interaktionsmuster.
- A2A Protocol – Agent Discovery ↗well-known-Discovery, Registries, Schutz und Caching von Agent Cards.
- A2A Protocol – Streaming & Asynchronous Operations ↗Polling, Streaming, Status- und Artifact-Updates sowie asynchrone Aufgaben.
- A2A Protocol – Enterprise Features ↗TLS, Authentication, Authorization und Enterprise-Sicherheitsmechanismen.
- A2A Protocol – A2A and MCP ↗Offizielle Einordnung der komplementären Rollen beider Protokolle.
- Linux Foundation – A2A adoption milestones 2026 ↗Projektstatus, unterstützende Organisationen und produktive Nutzung.
Letzte redaktionelle Prüfung: 2. Oktober 2026. A2A entwickelt sich weiter; für normative Details und Versionsfragen ist die aktuelle offizielle Spezifikation maßgeblich.
FAQ
Häufige Fragen zum A2A-Protokoll
Was ist A2A bei KI-Agenten?
A2A steht für Agent2Agent. Das offene Protokoll standardisiert, wie unabhängige KI-Agenten einander entdecken, Fähigkeiten beschreiben, Aufgaben austauschen und Ergebnisse zurückgeben.
Was ist eine Agent Card?
Eine Agent Card ist ein strukturiertes JSON-Dokument mit Identität, Endpunkten, Fähigkeiten, Skills, unterstützten Formaten und Sicherheitsanforderungen eines A2A-Agenten.
Was ist der Unterschied zwischen A2A und MCP?
MCP verbindet einen Agenten mit Tools, Ressourcen und Kontext. A2A verbindet unabhängige Agenten miteinander. Beide Protokolle sind komplementär und können im selben System eingesetzt werden.
Ist A2A ein Sicherheitsprotokoll?
Nein. A2A definiert Interoperabilität und beschreibt Sicherheitsanforderungen, ersetzt aber keine Authentifizierung, Autorisierung, Netzwerkabsicherung oder Datenklassifikation.
Wie finden sich A2A-Agenten?
A2A standardisiert die Selbstauskunft über Agent Cards. Eine verbreitete Methode ist eine well-known-URL; auch private Registries oder feste Konfigurationen sind möglich.
Unterstützt A2A lange laufende Aufgaben?
Ja. Tasks besitzen einen Lifecycle und können über Polling, Streaming oder Push-Mechanismen verfolgt werden, abhängig von den veröffentlichten Fähigkeiten des Servers.
Wann ist A2A für Unternehmen sinnvoll?
Vor allem dann, wenn spezialisierte Agenten über Team-, Plattform- oder Anbietergrenzen hinweg zusammenarbeiten und proprietäre Punkt-zu-Punkt-Integrationen reduziert werden sollen.
Muss jeder KI-Agent A2A unterstützen?
Nein. Wenn ein Agent keine unabhängigen Agenten aufrufen oder selbst als Agenten-Endpunkt dienen soll, ist A2A nicht zwingend erforderlich.
Ist jedes Multi-Agent-System automatisch A2A?
Nein. Mehrere interne Agenten oder Subagenten können proprietär orchestriert werden. A2A ist erst dann belegt, wenn das Protokoll konkret unterstützt wird.