Was ist das A2A-Protokoll? Agent Cards und Tasks im Überblick

Das A2A-Protokoll, kurz für Agent2Agent Protocol, ist ein offener Standard für die Kommunikation zwischen unabhängigen KI-Agent-Systemen.

Dieser Satz klingt einfach, impliziert aber etwas, das die meisten KI-Agent-Demos völlig ignorieren. Die meisten Demos gehen immer noch von einem Assistenten, einer Runtime, einem Tool-Loop und einem Eigentümer aus – der Agent kann suchen, Tools aufrufen, Code schreiben, APIs abfragen, vielleicht MCP-Server nutzen und eine Antwort zurückgeben.

A2A ist für eine andere Welt konzipiert, eine Welt, in der Agenten von verschiedenen Teams, Frameworks, Anbietern, Sprachen oder Organisationen entwickelt werden können. Es geht davon aus, dass ein Agent einen anderen Agenten entdecken, verstehen muss, was dieser kann, ihm Aufgaben übergeben, Nachrichten austauschen, Dateien oder strukturierte Ausgaben empfangen und eine Aufgabe bis zur completion verfolgen muss – was es zu mehr als nur einem weiteren Format für Tool-Aufrufe macht, sondern zu einem ernsthaften Versuch, KI-Agenten als Peers interoperabel zu machen.

Die Kernkonzepte sind:

• Agent Cards
• Agenten und Clients
• Tasks (Aufgaben)
• Messages (Nachrichten)
• Parts (Teile)
• Artifacts (Artefakte)
• Task-Status
• Streaming und asynchrone Updates

Dieser Artikel erklärt diese Konzepte in einfachen ingenieurtechnischen Begriffen, mit genügend Details, um zu verstehen, wo A2A in echten Multi-Agent-Systemen passt.

Die kurze Definition

A2A ist ein Protokoll für die Kommunikation von Agent zu Agent.

Es ermöglicht einem Agenten oder Client, mit einem anderen Agenten über ein gemeinsames Modell zu kommunizieren. Der empfangende Agent kann seine Fähigkeiten beschreiben, Arbeit annehmen, den Lebenszyklus dieser Arbeit verwalten, nach weiteren Eingaben fragen, Fortschritte streamen und konkrete Ausgaben zurückgeben.

Das Ziel ist nicht, zu standardisieren, wie ein Agent intern denkt – es geht darum zu standardisieren, wie Agenten an ihren Grenzen kommunizieren.

Ein A2A-Agent kann intern Folgendes nutzen:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• benutzerdefinierten Code
• MCP-Server
• private APIs
• Vektordatenbanken
• Workflow-Engines

Der Aufrufer muss nichts davon wissen. Was der Aufrufer wissen muss, ist:

• Was kann dieser Agent?
• Wie spreche ich mit ihm?
• Welche Eingabe akzeptiert er?
• Welche Ausgabe kann er erzeugen?
• Wie verfolge ich die Arbeit?
• Wie erhalte ich das Ergebnis?

Diese sechs Fragen definieren die Protokollgrenze, die A2A zwischen unabhängig arbeitenden Agenten etablieren möchte.

Warum A2A existiert

KI-Systeme entwickeln sich von einzelnen Assistenten zu Netzwerken aus spezialisierten Agenten.

Ein Unternehmen könnte haben:

• einen Support-Agenten
• einen Abrechnungsagenten
• einen Agenten für rechtliche Prüfungen
• einen DevOps-Agenten
• einen Datenanalyse-Agenten
• einen Recherche-Agenten
• einen Dokumentationsagenten
• einen Code-Review-Agenten

Jeder Agent kann seine eigenen Tools, Berechtigungen, Domänenwissen, Prompts, Speicher, Retrieval-Systeme und Audit-Regeln haben.

Ohne ein gemeinsames Protokoll wird jede Integration individuell – der Support-Agent benötigt eine maßgeschneiderte Verdrahtung zum Abrechnungsagenten, der Abrechnungsagent benötigt eine eigene zum Rechtsagenten, und der Recherche-Agent benötigt noch eine weitere zum Dokumentationsagenten. Dieser kombinatorische Overhead skaliert nicht gut, wenn das Agenten-Netzwerk wächst.

A2A gibt diesen Agenten eine gemeinsame Art der Interaktion und reduziert das N×M-Integrationsproblem auf einen einzigen gemeinsamen Vertrag. Das Versprechen ist keine magische Autonomie; das Versprechen ist Interoperabilität.

A2A ist nicht MCP

A2A wird oft mit MCP verglichen, aber sie lösen unterschiedliche Probleme.

MCP, oder Model Context Protocol, bezieht sich hauptsächlich auf die Verbindung einer KI-App oder eines Agenten mit Tools, Ressourcen und Prompts, während A2A hauptsächlich die Verbindung von Agenten mit anderen Agenten betrifft.

Ein nützliches mentales Modell ist:

MCP: Agent zu Tool
A2A: Agent zu Agent

Zum Beispiel kann ein Agent MCP nutzen, um Zugriff auf Folgendes zu erhalten:

• GitHub
• ein Dateisystem
• eine Datenbank
• Slack
• ein Suchsystem für Dokumentation
• eine Cloud-API

Praktische Leitfäden für den Aufbau dieser MCP-Server sind verfügbar für Go und Python.

Derselbe Agent kann A2A nutzen, um Arbeit an folgende Agenten zu delegieren:

• einen Sicherheitsprüfungsagenten
• einen Recherche-Agenten
• einen Planungsagenten
• einen Compliance-Agenten
• einen Coding-Agenten

Die beiden Protokolle können und arbeiten oft zusammen. Eine saubere Architektur sieht oft so aus:

A2A außerhalb der Agent-Grenze.
MCP innerhalb der Agent-Grenze.

Das bedeutet, dass andere Agenten mit Ihrem Agenten über A2A kommunizieren, während Ihr Agent intern MCP nutzt, um auf Tools zuzugreifen – eine klare Trennung der Verantwortlichkeiten, die die externe Schnittstelle stabil hält, unabhängig davon, was intern geändert wird. Für einen detaillierten Vergleich, wie die beiden Protokolle die architektonische Verantwortung aufteilen und wann Sie beide tatsächlich benötigen, siehe A2A vs MCP: Brauchen KI-Agenten wirklich beide Protokolle?

Kernrollen in A2A

A2A nutzt ein einfaches Rollenmodell, das sich um zwei Parteien dreht: einen Agenten, der Fähigkeiten offenlegt, und einen Client, der diese nutzen möchte.

Der Client kann sein:

• ein anderer Agent
• ein Orchestrator
• eine Assistenten-Anwendung
• ein Workflow-System
• ein Gateway
• ein Testframework
• eine nutzerorientierte App

Der Agent kann sein:

• ein spezialisierter KI-Dienst
• ein Domänenassistent
• ein Workflow-owning Agent
• ein externer Vendor-Agent
• ein internes Enterprise-Agent

Wichtig ist, dass der Agent nicht nur eine Funktion ist. Er besitzt eine bestimmte Fähigkeit und stellt diese über eine Agent-Schnittstelle zur Verfügung.

Agent Cards

Die Agent Card ist eines der wichtigsten Konzepte in A2A.

Eine Agent Card beschreibt einen Agenten – sie ist das Entdeckungsdocument, das Clients mitteilt, wer der Agent ist, was er kann, wie man mit ihm kommuniziert und welche Einschränkungen gelten.

Man kann sich eine Agent Card als Mischung aus Folgendem vorstellen:

• Service-Metadaten
• Fähigkeitsdeklaration
• API-Entdeckungsdocument
• Agent-Profil
• Vertragsoberfläche

Eine typische Agent Card kann Dinge wie Folgendes beschreiben:

• Agent-Name
• Beschreibung
• Service-Endpoint
• unterstützte Protokollfunktionen
• unterstützte Eingabe- und Ausgabemodi
• verfügbare Skills
• Authentifizierungsanforderungen
• Anbieterinformationen
• Versionsinformationen
• Dokumentationslinks
• optionale Metadaten

Die Agent Card ist wichtig, weil Agenten nicht über hartcodiertes Wissen über jeden anderen Agenten verfügen müssen.

Ein Client kann die Card inspizieren und entscheiden:

• Ist dies der richtige Agent für die Aufgabe?
• Unterstützt er den Inhaltstyp, den ich brauche?
• Unterstützt er Streaming?
• Erfordert er Authentifizierung?
• Welche Skills wirbt er an?
• Kann er die Art von Artefakt zurückgeben, die ich brauche?

In praktischen Systemen werden Agent Cards zur Grundlage für Agent-Registries, Developer-Portale und interne Agent-Kataloge – die maschinenlesbare Entsprechung eines Service-Verzeichnisses, in dem Clients nachsehen können, was verfügbar ist, bevor sie sich für eine Integration entscheiden.

Agent Cards sind Fähigkeitsgrenzen

Eine Agent Card sollte nicht als Marketingtext behandelt werden – sie ist eine Fähigkeitsgrenze, auf die sich andere Systeme zur Laufzeit verlassen.

Wenn Ihre Agent Card besagt, dass Ihr Agent Finanzanalysen durchführen kann, beginnen Clients möglicherweise, Finanzanalysearbeit an ihn zu delegieren. Wenn sie sagt, dass der Agent Dateien akzeptiert, senden Clients möglicherweise Dateien. Wenn sie sagt, dass der Agent Streaming unterstützt, erwarten Clients möglicherweise Fortschrittsereignisse.

Schlechte Agent Cards führen zu schlechten Systemen, da Routing-Entscheidungen und Fähigkeitsannahmen durch das gesamte Agenten-Netzwerk kaskadieren. Eine nützliche Agent Card sollte sein:

• spezifisch
• genau
• stabil
• versioniert
• sicherheitsbewusst
• ehrlich über Einschränkungen

Eine vage Skill wie „führt Geschäftsaufgaben aus“ ist nicht hilfreich.

Ein besserer Skill ist:

Analysiert SaaS-Rechnungsdaten und erstellt eine monatliche Ausgabenübersicht.

Noch besser ist es, erwartete Eingabe- und Ausgabemodi einzubeziehen.

Eingabe: CSV- oder JSON-Rechnungssätze.
Ausgabe: Markdown-Zusammenfassung und strukturierte JSON-Gesamtsummen.

Je präziser die Agent Card, desto einfacher ist es für andere Agenten, Aufgaben korrekt zu routen.

Agent-Entdeckung

Agent-Entdeckung ist der Prozess des Findens einer Agent Card.

In einfachen Bereitstellungen kann die Entdeckung statisch sein. Ein Client kennt bereits die URL eines bestimmten Agenten.

In größeren Bereitstellungen kann die Entdeckung Folgendes umfassen:

• eine Registry
• ein Developer-Portal
• einen internen Katalog
• DNS-basierte Entdeckung
• Konfigurationsmanagement
• umgebungsspezifisches Routing
• tenant-sensible Gateways

Die wichtige Designentscheidung ist, ob die Entdeckung öffentlich, privat oder berechtigt ist.

Nicht jeder Agent sollte von jedem entdeckt werden können – ein interner Lohnbuchhaltungsagent sollte nicht dieselbe Agent Card für jeden Aufrufer offenlegen, und ein Partner-Agent darf möglicherweise nur partnersichere Skills sehen. Agent-Entdeckung ist nicht nur eine Komfortfunktion; sie ist Teil Ihres Sicherheits- und Governance-Modells, und die Einschränkung der Sichtbarkeit ist eine Designentscheidung erster Klasse.

Tasks (Aufgaben)

Ein Task repräsentiert Arbeit, die von einem Agenten ausgeführt wird.

Hier wird A2A interessanter als einfache Request- und Response-APIs.

Einige Agent-Interaktionen sind schnell. Ein Client sendet eine Nachricht, und der Agent gibt eine direkte Antwort zurück.

Aber viele echte Agent-Workflows sind nicht instant.

Ein Task kann Folgendes beinhalten:

• das Durchsuchen mehrerer Quellen
• das Fragen nach Klärung
• das Aufrufen von Tools
• das Delegieren von Arbeit
• das Warten auf Genehmigung
• das Generieren eines Berichts
• das Erzeugen von Dateien
• das Streamen von Fortschritt
• das Behandeln von Wiederholungen
• das Zurückgeben mehrerer Artefakte

A2A modelliert diese Art von Arbeit als Task – was der Arbeit eine Identität und einen Lebenszyklus gibt, was wichtig ist, weil lang laufende Agent-Arbeit verfolgt, inspiziert und möglicherweise abgebrochen oder wiederholt werden muss.

Task-Lebenszyklus

Ein Task kann verschiedene Status durchlaufen.

Das genaue Statusmodell hängt von der Protokollversion und der Implementierung ab, aber die Grundidee ist einfach:

• eingereicht
• in Bearbeitung
• Eingabe erforderlich
• abgeschlossen
• fehlgeschlagen
• abgebrochen
• abgelehnt

Der wichtige Punkt ist, dass ein Task nicht nur ein Response-Payload ist – er ist eine laufende Arbeitseinheit mit eigenem Status, den ein Client jederzeit abfragen kann. Ein Client kann den Task-Status verwenden, um zu verstehen, was passiert:

• Hat der Agent den Task akzeptiert?
• Arbeitet er noch daran?
• Benötigt er weitere Eingaben?
• Ist er erfolgreich abgeschlossen?
• Ist er fehlgeschlagen?
• Wurde er abgebrochen?
• Sind Artefakte verfügbar?

Dies ist besonders nützlich für Workflows, die Sekunden, Minuten oder länger dauern.

Zum Beispiel kann ein Recherche-Agent sofort einen Task zurückgeben und dann im Hintergrund weiterarbeiten, während er Fortschrittsereignisse streamt oder das Ergebnis später verfügbar macht.

Stateless Message oder Stateful Task

A2A unterstützt sowohl einfache als auch komplexe Interaktionen.

Bei einer einfachen Interaktion kann ein Agent eine direkte Message zurückgeben; bei einer komplexen Interaktion kann er einen Task zurückgeben. Diese Unterscheidung ist wichtig, weil nicht alles Task-Tracking benötigt, und das Überengineering kurzer Interaktionen in vollständige Task-Workflows unnötigen Overhead hinzufügt.

Wenn ein Client fragt:

Fasse diesen einen Absatz zusammen.

Kann eine direkte Antwort ausreichen.

Wenn ein Client fragt:

Erforsche die fünf besten Open-Source-Vektordatenbanken, vergleiche sie und erstelle eine Migrationsempfehlung.

Ist ein Task angemessener.

Die praktische Regel ist einfach: Verwenden Sie eine direkte Message für einfache, sofortige Interaktionen und einen Task für lang laufende, zustandsbehaftete, auditierbare oder artefakterzeugende Arbeit.

Messages (Nachrichten)

Messages sind die Kommunikationseinheiten, die zwischen Client und Agent ausgetauscht werden.

Eine Message kann einen oder mehrere Parts enthalten.

Eine Message kann Folgendes repräsentieren:

• eine Benutzeranfrage
• eine Agentenantwort
• eine Klärungsfrage
• zusätzliche Eingabe
• taskbezogene Kommunikation
• Fortschrittskontext
• strukturierte Anweisungen

Messages sind nicht nur Strings – Agent-Kommunikation muss oft viel mehr als reinen Text tragen, und die Message-Struktur ist darauf ausgelegt, dies zu berücksichtigen.

Eine Message kann Folgendes enthalten:

• Text
• Dateien
• strukturierte JSON-Daten
• Bilder
• Referenzen
• Metadaten

Die Message ist der Umschlag; die Parts sind der tatsächliche typisierte Inhalt darin.

Parts (Teile)

Ein Part ist ein Stück Inhalt innerhalb einer Message oder eines Artefakts.

So unterstützt A2A multimodale und strukturierte Kommunikation.

Ein Part kann verschiedene Inhaltstypen enthalten, wie:

• Text
• Filedaten
• strukturierte Daten
• binäre Inhalte per Referenz
• JSON-ähnliche Daten

Ein Part kann auch Metadaten wie Folgendes enthalten:

• Medientyp
• Dateiname
• zusätzlicher Kontext

Der Medientyp ist wichtig, weil er dem empfangenden Agenten mitteilt, wie er den Inhalt interpretieren soll.

Zum Beispiel:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Dies ist einer der unterschätzten Teile von A2A. Agent-Kommunikation sollte nicht alles auf reinen Text reduzieren – wenn ein nachgelagerter Agent eine Tabelle, ein Bild, eine JSON-Payload, eine Logdatei oder ein PDF benötigt, sollte das Protokoll diesen Inhalt als Inhalt bewahren, anstatt ihn in einen Absatz zu verwandeln. Gute Agent-Systeme vermeiden diese unnötigen Textengpässe, indem sie jedem Part erlauben, seinen natürlichen Medientyp bis zum Verbraucher zu tragen.

Artifacts (Artefakte)

Artifacts sind konkrete Ausgaben, die von einem Agenten während der Task-Verarbeitung erzeugt werden.

Dies unterscheidet sich von einer allgemeinen Message: Eine Message ist Kommunikation zwischen Agenten, während ein Artifact ein konkretes Lieferstück ist, das der Task erzeugt hat.

Beispiele für Artifacts sind:

• ein Markdown-Bericht
• ein JSON-Analyseergebnis
• ein CSV-Export
• ein generiertes Bild
• ein PDF-Dokument
• ein Code-Patch
• eine Testergebnisdatei
• ein Bereitstellungsplan
• ein Diagramm
• ein Datenextrakt

Diese Unterscheidung ist in der Praxis nützlich. Wenn ein Recherche-Agent sagt „Ich habe die Antwort gefunden“, ist das eine Message. Wenn er market-analysis.md, sources.json und risk-summary.csv zurückgibt, sind das Artifacts – konkrete Ausgaben, die die Arbeit des Tasks inspizierbar, wiederverwendbar und komponierbar machen. Das Artifact eines Agenten wird zum Input eines anderen Agenten ohne Verlust der Struktur.

Messages vs. Artifacts

Eine einfache Art, darüber nachzudenken:

Messages sind Konversation.
Artifacts sind Ausgabe.

Messages helfen Agenten bei der Koordinierung; Artifacts sind das, was der Task tatsächlich produziert hat.

Zum Beispiel in einem Softwareentwicklungs-Workflow:

• Der Client sendet eine Message mit einer Anfrage nach einem Bugfix.
• Der Coding-Agent sendet Messages mit Klärungsfragen.
• Der Coding-Agent arbeitet an dem Task.
• Der Agent gibt Artifacts wie eine Patch-Datei, Testausgabe und Erklärung zurück.

Diese Trennung ist hilfreich, weil sie das Mischen von Task-Koordinierung mit Lieferstücken vermeidet und es viel einfacher macht, Logs zu führen, Audits durchzuführen und Ausgaben an nachgelagerte Verbraucher weiterzugeben.

Ein praktisches Beispiel

Stellen Sie sich vor, ein primärer Assistent benötigt Hilfe von einem Dokumentationsagenten.

Der Benutzer fragt:

Erstelle Entwicklerdokumentation für unsere neue Billing-Webhook-API.

Der primäre Assistent prüft eine Agent-Registry und findet einen Dokumentationsagenten.

Der Dokumentationsagent hat eine Agent Card, die besagt, dass er:

• API-Dokumentation schreiben kann
• OpenAPI-Spezifikationen akzeptiert
• Markdown-Styleguides akzeptiert
• Markdown-Dokumente erzeugt
• Beispiele in Python und JavaScript erzeugt
• lang laufende Tasks unterstützt
• Artifacts zurückgibt

Der primäre Assistent sendet eine Message mit:

• einer kurzen Anweisung
• einer OpenAPI-Datei
• einem Styleguide
• Metadaten über die Zielgruppe

Der Dokumentationsagent erstellt einen Task.

Der Task wechselt in den Status „in Bearbeitung“.

Der Dokumentationsagent kann Messages wie Folgendes senden:

Ich extrahiere Endpunktbeschreibungen.

Dann:

Ich brauche Klärung zu Authentifizierungsbeispielen.

Der primäre Assistent liefert die fehlende Eingabe.

Der Task setzt fort.

Schließlich gibt der Dokumentationsagent Artifacts zurück:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Das ist das A2A-Modell in Aktion: nicht nur „rufe diese Funktion auf“, sondern „delegiere diesen Task an einen anderen Agenten, kommuniziere bei Bedarf und verfolge das Ergebnis bis zur completion“.

Warum Tasks für echte Systeme wichtig sind

Tasks sind das, was A2A für ernsthafte Workflows geeignet macht.

Ein normaler HTTP-API-Aufruf ist oft zu dünn für Agent-Arbeit. Agent-Tasks können Unsicherheit, mehrere Schritte, Zwischenergebnisse und Nachfolgefragen beinhalten.

Ein Task gibt Ihnen einen Ort, um Folgendes anzuhängen:

• Status
• Verlauf
• Messages
• Artifacts
• Fehler
• Metadaten
• Fortschritt
• Abbruch
• Audit-Informationen

Dies ist nützlich für:

• Recherche-Workflows
• Code-Generierung
• Datenanalyse
• Compliance-Prüfung
• Dokumentenerstellung
• Incident-Untersuchung
• mehrstufige Planung
• Workflows mit menschlicher Genehmigung

Ohne ein Task-Modell bauen Entwickler diese Logik normalerweise selbst mit benutzerdefinierten Job-IDs, Warteschlangen, Status-Endpunkten und Webhook-Callbacks neu – A2A versucht, die agentenspezifische Version dieses Musters zu standardisieren, damit Sie es nicht für jede neue Agent-Integration neu erfinden müssen.

Streaming und asynchrone Arbeit

A2A unterstützt die Idee, dass Agent-Arbeit gestreamt oder asynchron sein kann.

Streaming ist nützlich, wenn der Client Live-Updates wünscht.

Zum Beispiel:

• Fortschrittsereignisse
• partielle Ergebnisse
• Zwischenstatus
• generierter Text
• Schritt-Updates

Asynchrone Workflows sind nützlich, wenn der Task lange dauern kann oder der Client keine offene Verbindung halten kann.

Zum Beispiel:

• Hintergrundrecherche
• Generierung großer Dokumente
• Multi-Agent-Review
• Datenverarbeitung
• menschliche Genehmigung
• Batch-Analyse

In der Praxis sollte ein robustes A2A-System um drei Modi herum entworfen werden: sofortige Antwort für einfache Arbeit, Streaming für interaktive lang laufende Arbeit und Async für dauerhafte Hintergrundarbeit, die jede einzelne Verbindung überleben kann.

Agent Cards und Streaming-Unterstützung

Eine Agent Card kann anzeigen, ob ein Agent Streaming unterstützt.

Das ist wichtig, weil Clients nicht davon ausgehen können, dass jeder Agent Streaming unterstützt – einige Agenten unterstützen möglicherweise nur einfache Request- und Response, einige unterstützen Task-Polling, und andere unterstützen Push-Benachrichtigungen oder Server-Sent Events. Ein guter Client inspiziert die Agent Card, bevor er ein Interaktionsmuster wählt, weshalb Agent Cards nicht nur Dokumentation sind: Sie gestalten das Laufzeitverhalten direkt.

A2A und multimodale Agenten

A2A ist darauf ausgelegt, mehr als nur reinen Text zu unterstützen.

Das ist wichtig, weil echte Agent-Systeme zunehmend gemischte Eingaben und Ausgaben verarbeiten:

• Text
• Bilder
• Audio
• Video
• PDFs
• Tabellenkalkulationen
• strukturierte JSON-Daten
• Logs
• Code
• Diagramme

Wenn jede Agent-Grenze alles in Text umwandelt, kann wichtige Informationen verloren gehen.

Zum Beispiel sollte ein visueller Troubleshooting-Agent ein Bild als Bild erhalten, nicht als schwache Textbeschreibung. Ein Finanzagent sollte strukturierte Tabellendaten erhalten, nicht einen kopierten Absatz. Ein Code-Review-Agent sollte Quelldateien oder Diffs erhalten, nicht eine vage Zusammenfassung.

Parts und Medientypen sind die Art und Weise, wie A2A reichhaltigere Inhalte über Agent-Grenzen hinweg bewahrt – und dies ist eine der Stellen, an denen das Protokoll wichtiger ist, als es zunächst erscheint, weil Informationsverlust an der Grenze sich bei jedem Hop in einer Multi-Agent-Kette vervielfacht.

A2A ist kein Agent-Framework

A2A sagt Ihnen nicht, wie Sie einen Agenten bauen.

Es definiert nicht:

• Reasoning-Strategie
• Planungsalgorithmus
• Speichersystem
• Vektordatenbank
• Prompt-Vorlage
• Modellanbieter
• Tool-Framework
• Orchestrierungs-Runtime
• Evaluierungsmethode

Das ist ein Feature, kein Bug. A2A ist ein Grenzprotokoll, das es verschiedenen Agent-Implementierungen ermöglicht, zu kommunizieren, ohne dass sie dieselbe interne Architektur teilen müssen – ähnlich wie HTTP Ihnen nicht sagt, wie Sie eine Webanwendung bauen, sondern nur definiert, wie Systeme kommunizieren. A2A sollte auf die gleiche Weise verstanden werden.

A2A ist kein Ersatz für APIs

A2A ersetzt auch nicht jede API.

Wenn Sie einen deterministischen Dienst mit einem stabilen Request- und Response-Vertrag haben, kann eine normale API besser sein.

Zum Beispiel:

• Währungsumrechnung
• Adressvalidierung
• Rechnungssuche
• Bildvergrößerung
• Suchendpunkt
• Feature-Flag-Suche
• interner CRUD-Dienst

Diese werden nicht automatisch zu Agenten, nur weil sie von einem KI-System aufgerufen werden. A2A macht Sinn, wenn das entfernte System genuinely wie ein Agent handelt:

• es besitzt einen Task
• es kann nach weiteren Eingaben fragen
• es kann intern Tools nutzen
• es kann Zeit brauchen
• es kann Artifacts erzeugen
• es hat Fähigkeiten, die es wert sind, entdeckt zu werden
• es kann als Peer in einem größeren Workflow operieren

Verwenden Sie A2A nicht nur, weil es modern klingt – verwenden Sie es, wenn die Abstraktion genuinely zum Problem passt.

Wo A2A in der KI-Systemarchitektur passt

A2A passt am besten an der Grenze zwischen unabhängig bereitstellbaren Agenten.

Eine nützliche Architektur könnte so aussehen:

Benutzer
  |
  v
Primärer Assistent
  |
  |-- A2A --> Recherche-Agent
  |-- A2A --> Coding-Agent
  |-- A2A --> Compliance-Agent
  |-- A2A --> Dokumentationsagent

Jeder spezialisierte Agent kann intern Tools nutzen:

Recherche-Agent
  |
  |-- MCP --> Websuche
  |-- MCP --> Dokumentenspeicher
  |-- MCP --> Vektordatenbank

Dies gibt Ihnen separate Schichten:

Benutzeroberflächenschicht
Agent-Koordinierungsschicht
Tool-Integrationsschicht
Daten- und Ausführungsschicht

A2A lebt in der Agent-Koordinierungsschicht, MCP oft in der Tool-Integrationsschicht, und normale APIs, Warteschlangen, Datenbanken und Speichersysteme leben darunter – jede Schicht mit ihrer eigenen Abstraktion und ihren eigenen Ausfallmodi. Für eine querschnittliche Karte, wie LLM-Inferenz, Speicher, Routing, Tooling und Observability in produktiven Assistenten zusammenpassen, siehe KI-Assistent-Architektur: LLM, Speicher, Tools, Routing, Observability.

Architekturmuster: Orchestrator und Spezialisten

Das häufigste A2A-Muster ist wahrscheinlich Orchestrator plus Spezialisten.

In diesem Muster empfängt ein primärer Agent die Benutzeranfrage und delegiert Teile der Arbeit an spezialisierte Agenten.

Beispiel:

Primärer Assistent
  |
  |-- A2A --> Rechtsagent
  |-- A2A --> Finanzagent
  |-- A2A --> Recherche-Agent
  |-- A2A --> Schreibagent

Dieses Muster ist einfach zu verstehen: Der Orchestrator besitzt den Gesamtworkflow, und spezialisierte Agenten besitzen domänenspezifische Arbeit. Der Nachteil ist, dass der Orchestrator zu einem Engpass werden kann, und er benötigt eine solide Routing-Strategie, um effektiv zu delegieren – die zugrunde liegende Modellselection und Orchestrierungs-Trade-offs werden in Multi-Model-Systemdesign: Wenn ein Modell nicht ausreicht behandelt. Trotzdem ist dies für die meisten Teams die beste erste Multi-Agent-Architektur, bevor komplexere Topologien erkundet werden.

Architekturmuster: Peer-Agenten

In einem Peer-to-Peer-Muster können Agenten direkter miteinander kommunizieren.

Zum Beispiel:

Recherche-Agent --> Datenagent --> Charting-Agent --> Schreibagent

Das kann mächtig sein, aber es ist schwerer zu kontrollieren.

Sie benötigen starke Regeln für:

• wer wen aufrufen darf
• was für Kontext geteilt werden kann
• wie Schleifen verhindert werden
• wer den finalen Output besitzt
• wie Kosten kontrolliert werden
• wie Delegation auditet wird

Peer-Agent-Netzwerke klingen elegant, können aber schnell chaotisch werden – verwenden Sie sie nur, wenn Sie starke Governance-Regeln und klare Eigentumsverhältnisse über jede Kante im Graphen haben.

Architekturmuster: A2A-Gateway

Ein produktionsfreundlicheres Muster ist ein A2A-Gateway.

Anstatt dass jeder Agent direkt jeden anderen Agenten aufruft, fließt der Verkehr durch ein Gateway.

Das Gateway kann Folgendes handhaben:

• Authentifizierung
• Autorisierung
• Routing
• Tenant-Mapping
• Logging
• Ratenlimits
• Policy-Checks
• Protokollversionsbehandlung
• Observability
• Audit-Trails

Dies ist besonders in Enterprise-Umgebungen nützlich, wo das Gateway zur Control Plane für Agent-Kommunikation wird – die Durchsetzung von Policies an einer Stelle, anstatt sie über jeden Agenten neu zu implementieren. In kleineren Systemen kann dies übertrieben sein, aber in größeren Systemen mit mehreren Teams und Anbietern wird es oft früher als erwartet notwendig.

Sicherheitsüberlegungen

A2A-Sicherheit verdient ernsthafte Aufmerksamkeit.

Agent-zu-Agent-Kommunikation kann sensiblen Kontext über Grenzen hinweg bewegen. Sie kann auch Arbeit an Systeme delegieren, die ihre eigenen Tools und Berechtigungen haben können.

Die Kern-Sicherheitsfragen sind:

• Welche Agenten dürfen diesen Agenten entdecken?
• Welche Agenten dürfen ihm Tasks senden?
• Welche Authentifizierung ist erforderlich?
• Welche Berechtigungen sind mit dem Aufrufer verbunden?
• Kann ein Agent Benutzerautorität an einen anderen delegieren?
• Welche Daten können in Messages enthalten sein?
• Welche Artifacts können zurückgegeben werden?
• Wie wird der Task auditet?
• Kann der empfangende Agent Tools oder andere Agenten aufrufen?
• Wie werden Geheimnisse geschützt?

Agent Cards sollten keine statischen Geheimnisse enthalten, und sensible Agent Cards sollten hinter Authentifizierung geschützt sein, anstatt offen veröffentlicht zu werden. Verschiedene Clients benötigen oft verschiedene Ansichten desselben Agenten – ein interner Aufrufer kann mehr Skills sehen als ein externer Partner, während ein öffentlicher Client möglicherweise nur einen begrenzten Satz an sicheren Fähigkeiten sieht.

Sicherheit sollte nicht hinzugefügt werden, nachdem das Agenten-Netzwerk gebaut ist; sie sollte das Netzwerk von Anfang an gestalten, da das Nachrüsten von Auth- und Berechtigungsgrenzen über eine live Agent-Topologie significantly schwieriger ist als das Designen von Beginn an.

Observability-Überlegungen

A2A-Systeme benötigen starke Observability.

Wenn ein Task Agent-Grenzen überschreitet, wird das Debugging substantially schwieriger, weil kein einzelnes System das vollständige Bild hält. Sie müssen wissen:

• welcher Agent den Task erstellt hat
• welcher Agent ihn akzeptiert hat
• welche Messages ausgetauscht wurden
• welche Statusänderungen aufgetreten sind
• welche Artifacts erzeugt wurden
• welche Fehler aufgetreten sind
• wie lange jeder Schritt gedauert hat
• welche Tools intern verwendet wurden
• ob ein anderer Agent aufgerufen wurde
• wer riskante Aktionen genehmigt hat

Ein nützlicher Trace sollte die Arbeit über die vollständige Kette hinweg verfolgen.

Zum Beispiel:

Benutzeranfrage
  -> primärer Assistent Task
  -> Recherche-Agent Task
  -> Dokumentensuch-Tool-Aufruf
  -> Zusammenfassungs-Artefakt
  -> finale Antwort

Ohne diesen End-to-End-Trace werden Multi-Agent-Systeme in der Produktion sehr schwer zu vertrauen – Sie können nicht mit Sicherheit beantworten, warum das System eine gegebene Ausgabe produziert hat, geschweige denn identifizieren, wo es falsch gelaufen ist. Observability für LLM-Systeme: Metriken, Traces, Logs und Testing in der Produktion behandelt die Instrumentierungs- und Tooling-Seite dieses Problems in der Tiefe.

Häufige Fehler

Fehler 1: Jedes Tool als Agent zu bezeichnen

Nicht jedes Tool ist ein Agent.

Ein Rechner ist ein Tool. Ein Dateileser ist ein Tool. Ein Datenbankabfrage-Endpoint ist ein Tool.

Wenn es keinen Task besitzt, nach Eingabe fragt, Artifacts erzeugt oder als unabhängiger Peer handelt, benötigt es wahrscheinlich kein A2A.

Fehler 2: Agent Cards zu vage zu machen

Eine Agent Card sollte nicht sagen:

Dieser Agent hilft bei Geschäftsaufgaben.

Das ist für jeden Agenten, der versucht, Arbeit intelligent zu routen, nutzlos. Eine gute Card sollte sagen, was der Agent tatsächlich tut, was er akzeptiert, was er zurückgibt und welche Einschränkungen gelten.

Fehler 3: Task-Status ignorieren

Wenn Sie A2A verwenden, aber jede Interaktion als Request und Response behandeln, verpassen Sie einen Großteil des Werts.

Das Task-Modell ist einer der Hauptgründe, A2A gegenüber einer normalen API zu verwenden – das Überspringen bedeutet, dieselbe Lifecycle-Tracking-Logik in jeder Integration neu aufzubauen.

Fehler 4: Alles als Text zurückgeben

A2A unterstützt strukturierte und multimodale Inhalte. Nutzen Sie es.

Wenn die Ausgabe ein Bericht ist, geben Sie ein Bericht-Artefakt zurück.

Wenn die Ausgabe JSON ist, geben Sie strukturierte Daten zurück.

Wenn die Ausgabe eine Datei ist, geben Sie eine Datei zurück.

Flachen Sie nicht alles auf reinen Text, es sei denn, reiner Text ist die richtige Ausgabe.

Fehler 5: Kein Berechtigungsmodell

Agenten-Netzwerke ohne Berechtigungsgrenzen sind riskant.

Nicht jeder Agent darf jeden anderen Agenten mit jeder Art von Daten aufrufen – verwenden Sie Authentifizierung, Autorisierung und Audit-Trails, um das Prinzip des geringsten Privilegs über das Agenten-Netzwerk durchzusetzen.

Wann sollten Sie A2A verwenden?

Verwenden Sie A2A, wenn Sie echte Agent-Grenzen haben.

Gute Gründe sind:

• Agenten werden von verschiedenen Teams betrieben
• Agenten werden als separate Dienste bereitgestellt
• Agenten werden mit verschiedenen Frameworks gebaut
• Agenten müssen sich gegenseitig entdecken
• Agenten müssen Tasks delegieren
• Tasks können lang laufen
• Ergebnisse können Artifacts enthalten
• Clients sollten interne Tools nicht kennen
• Agent-Fähigkeitsmetadaten sind wichtig

Schwache Gründe sind:

• es klingt modern
• Sie möchten eine Funktion aufrufen
• Sie haben eine Single-Agent-App
• eine normale API würde funktionieren
• MCP löst bereits Ihr Tool-Integrationsproblem

A2A ist mächtig, wenn das System tatsächlich Multi-Agent ist; es ist unnötige Zeremonie, wenn das System es nicht ist, und die Kosten dieser Zeremonie – zusätzliche Konzepte, Infrastruktur, Debugging-Oberfläche und Sicherheitsanforderungen – sind real.

Ein minimales mentales Modell

Wenn Sie nur eine Sache im Gedächtnis behalten, behalten Sie Folgendes im Gedächtnis:

Agent Card: was der Agent können kann.
Message: was Agenten einander sagen.
Part: typisierter Inhalt innerhalb einer Message oder eines Artefakts.
Task: Arbeit, die der Agent besitzt.
Artifact: Ausgabe, die der Task erzeugt hat.

Das ist der Kern von A2A – der Rest bezieht sich größtenteils darauf, diese fünf Konzepte zuverlässig, observierbar und sicher genug zu machen, um sie in echten Produktionssystemen zu verwenden.

Abschließende Gedanken

A2A ist nicht nur ein weiteres KI-Akronym – es ist Teil eines größeren Wandels von isolierten Assistenten zu interoperablen Agent-Systemen. Dieser Wandel wird nicht überall auf einmal geschehen, und viele Anwendungen werden Single-Agent-Systeme mit gutem Tool-Zugriff bleiben, wo MCP und normale APIs völlig ausreichend sind.

Aber sobald Agenten zu separat bereitgestellten Peers werden, benötigen Sie stärkere Grenzen: Entdeckung, Task-Eigentum, Messages, die mehr als Text tragen, Artifacts als Outputs erster Klasse, und Sicherheit, Status und Observability, die Agent-Grenzen überschreiten. Das ist der Raum, den A2A zu besetzen versucht, und es ist ein genuinely anderes Problem als das Tool-Integrationsproblem, das MCP löst.

Für eine praktische Einschätzung, wo A2A tatsächlich Produktionsfußboden in 2026 hat – einschließlich Adoption-Stufen, Sicherheitsbedenken, dem Enterprise-Use-Case und einem Entscheidungsframework – siehe Google A2A-Protokoll in 2026: Adoption, Hype und Realität.

Meine Meinung: Beginnen Sie nicht mit A2A für kleine Projekte. Beginnen Sie mit einem nützlichen Agenten, guten Tools und klarer Architektur – der KI-Systeme-Cluster behandelt selbst gehostete Assistenten, MCP-Server und Agent-Speicher als verbundene Menge, wenn Sie den breiteren Kontext wünschen. Aber wenn Ihr „Tool“ beginnt, wie ein anderer autonomer Spezialist mit eigenem Task-Lebenszyklus auszusehen, ist es wahrscheinlich nicht mehr nur ein Tool – und dann wird A2A interessant.

Quellen

• A2A-Protokoll-Spezifikation: https://a2a-protocol.org/latest/specification/
• A2A-Schlüsselkonzepte: https://a2a-protocol.org/latest/topics/key-concepts/
• A2A-Lebenslauf eines Tasks: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2A-Agent-Entdeckung: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A-Streaming und asynchrone Operationen: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A und MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/