Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt

Das A2A-Protokoll (Agent2Agent Protocol) ist ein offener Standard für die Kommunikation zwischen unabhängigen KI-Agenten-Systemen.

Dieser Satz klingt simpel, impliziert aber etwas, was die meisten KI-Agenten-Demos komplett ignorieren. Die meisten Demos gehen immer noch von einem Assistenten, einer Laufzeitumgebung, einem Tool-Loop und einem Besitzer 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, in der Agenten von verschiedenen Teams, Frameworks, Anbietern, Sprachen oder Organisationen erstellt werden können. Es geht davon aus, dass ein Agent möglicherweise einen anderen Agenten entdecken muss, verstehen, was dieser leisten kann, ihm Arbeit übergeben, Nachrichten austauschen, Dateien oder strukturierte Ausgaben empfangen und eine Aufgabe bis zu deren Abschluss verfolgen kann. Damit ist es nicht nur ein weiteres Format für Tool-Aufrufe, sondern ein ernsthafter Versuch, KI-Agenten als gleichberechtigte Partner interoperabel zu machen.

Die Kernkonzepte sind:

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

Dieser Artikel erklärt diese Konzepte in einfachen technischen Begriffen und geht detailliert genug auf sie ein, um zu verstehen, wo A2A in echten Multi-Agenten-Systemen seinen Platz findet.

Die kurze Definition

A2A ist ein Protokoll für die Kommunikation zwischen Agenten.

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

Das Ziel ist nicht, zu standardisieren, wie ein Agent intern denkt, sondern zu standardisieren, wie Agenten an ihren Grenzen miteinander kommunizieren.

Ein A2A-Agent kann intern Folgendes verwenden:

• 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, sind folgende Punkte:

• Was kann dieser Agent?
• Wie kommuniziere ich mit ihm?
• Welche Eingaben akzeptiert er?
• Welche Ausgaben 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 hin zu Netzwerken spezialisierter Agenten.

Ein Unternehmen könnte über folgende Agenten verfügen:

• Einen Support-Agenten
• Einen Abrechnungs-Agenten
• Einen Agenten für Rechtsprüfungen
• Einen DevOps-Agenten
• Einen Datenanalyse-Agenten
• Einen Forschungs-Agenten
• Einen Dokumentations-Agenten
• 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 Verbindung zum Abrechnungs-Agenten, der Abrechnungs-Agent benötigt eine eigene Verbindung zum Rechts-Agenten und der Forschungs-Agent benötigt eine weitere Verbindung zum Dokumentations-Agenten. Dieser kombinatorische Aufwand skaliert nicht gut, wenn das Agenten-Netzwerk wächst.

A2A bietet 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 (Model Context Protocol) befasst sich hauptsächlich mit der Verbindung einer KI-App oder eines Agents 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

Beispielsweise kann ein Agent MCP verwenden, um auf Folgendes zuzugreifen:

• GitHub
• ein Dateisystem
• eine Datenbank
• Slack
• ein Dokumentationssuchsystem
• eine Cloud-API

Praktische Anleitungen zum Aufbau dieser MCP-Server sind verfügbar für Go und Python.

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

• einen Sicherheits-Review-Agenten
• einen Forschungs-Agenten
• einen Planungs-Agenten
• einen Compliance-Agenten
• einen Coding-Agenten

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

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

Das bedeutet, dass andere Agenten mit Ihrem Agenten über A2A kommunizieren, während Ihr Agent intern MCP verwendet, um auf Tools zuzugreifen – eine klare Trennung der Zuständigkeiten, die die externe Schnittstelle stabil hält, unabhängig von internen Änderungen. Für einen detaillierten Vergleich, wie die beiden Protokolle die architektonische Verantwortung aufteilen und wann Sie tatsächlich beide benötigen, siehe A2A vs MCP: Do AI Agents Really Need Both Protocols?

Kernrollen in A2A

A2A verwendet ein einfaches Rollenmodell, das um zwei Parteien herum aufgebaut ist: einen Agenten, der Fähigkeiten bereitstellt, 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 Test-Setup
• eine anwenderorientierte App

Der Agent kann sein:

• ein spezialisierter KI-Service
• ein Domänen-Assistent
• ein workflowbesitzender Agent
• ein externer Vendor-Agent
• ein internes Unternehmensagent

Wichtig ist, dass der Agent nicht nur eine Funktion ist. Er besitzt eine bestimmte Fähigkeit und stellt sie über eine Agenten-Schnittstelle bereit.

Agent Cards (Agentenkarten)

Die Agent Card ist eines der wichtigsten Konzepte in A2A.

Eine Agent Card beschreibt einen Agenten – sie ist das Entdeckungs-Dokument, das Clients mitteilt, was der Agent ist, was er leisten 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-Entdeckungsdokument
• Agenten-Profil
• Vertragsfläche

Eine typische Agent Card kann Dinge beschreiben wie:

• Agentenname
• Beschreibung
• Service-Endpunkt
• unterstützte Protokollfunktionen
• unterstützte Eingabe- und Ausgabeformate
• verfügbare Fähigkeiten (Skills)
• Authentifizierungsanforderungen
• Anbieterinformationen
• Versionsinformationen
• Dokumentationslinks
• optionale Metadaten

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

Ein Client kann die Karte inspizieren und entscheiden:

• Ist dies der richtige Agent für die Aufgabe?
• Unterstützt er den Inhaltstyp, den ich benötige?
• Unterstützt er Streaming?
• Erfordert er Authentifizierung?
• Welche Fähigkeiten wirbt er an?
• Kann er die Art von Artefakt zurückgeben, die ich benötige?

In praktischen Systemen werden Agent Cards zur Grundlage für Agenten-Register, Entwicklerportale und interne Agenten-Kataloge – das maschinenlesbare Äquivalent eines Service-Verzeichnisses, in dem Clients nachschauen 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 andere Systeme zur Laufzeit vertrauen.

Wenn Ihre Agentenkarte angibt, dass Ihr Agent Finanzanalysen durchführen kann, werden Clients möglicherweise Finanzanalyse-Arbeit an ihn delegieren. Wenn sie angibt, dass der Agent Dateien akzeptiert, werden Clients Dateien senden. Wenn sie angibt, dass der Agent Streaming unterstützt, werden Clients Fortschrittsereignisse erwarten.

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 Fähigkeit wie „erledigt Geschäftsaufgaben“ ist nicht hilfreich.

Eine bessere Fähigkeit ist:

Analyse von SaaS-Rechnungsdaten und Erstellung einer monatlichen Ausgabenübersicht.

Noch besser ist es, erwartete Eingabe- und Ausgabeformate einzuschließen.

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

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

Agent-Discovery (Agenten-Entdeckung)

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

Bei einfachen Bereitstellungen kann die Entdeckung statisch sein. Ein Client kennt bereits die URL eines bestimmten Agents.

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

• ein Register
• ein Entwicklerportal
• einen internen Katalog
• DNS-basierte Entdeckung
• Konfigurationsmanagement
• umgebungsspezifisches Routing
• tenantbewusste 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 Personalverwaltungs-Agent sollte nicht dieselbe Agent Card für jeden Aufrufer freigegeben, und ein Partner-Agent sollte möglicherweise nur partnersichere Fähigkeiten sehen. Agent-Discovery ist nicht nur eine Komfortfunktion; sie ist Teil Ihres Sicherheits- und Governance-Modells, und die Begrenzung der Sichtbarkeit ist eine Designentscheidung erster Ordnung.

Tasks (Aufgaben)

Ein Task stellt Arbeit dar, die von einem Agenten ausgeführt wird.

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

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

Aber viele echte Agenten-Workflows sind nicht sofort erledigt.

Eine Aufgabe kann Folgendes umfassen:

• Suche in mehreren Quellen
• Anfrage nach Klarstellung
• Aufruf von Tools
• Delegation von Arbeit
• Warten auf Genehmigung
• Generierung eines Berichts
• Erzeugung von Dateien
• Streaming des Fortschritts
• Behandlung von Wiederholungen
• Rückgabe mehrerer Artefakte

A2A modelliert diese Art von Arbeit als Task – es verleiht der Arbeit eine Identität und einen Lebenszyklus, was wichtig ist, weil lang laufende Agentenarbeit verfolgt, inspiziert und potenziell abgebrochen oder wiederholt werden muss.

Task-Lebenszyklus

Ein Task kann verschiedene Zustände durchlaufen.

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

• eingereicht (submitted)
• in Bearbeitung (working)
• Eingabe erforderlich (input required)
• abgeschlossen (completed)
• fehlgeschlagen (failed)
• abgebrochen (canceled)
• abgelehnt (rejected)

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

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

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

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

Stateful 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 zu vollständigen 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 straightforward: 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 Nachricht kann einen oder mehrere Parts enthalten.

Eine Nachricht kann darstellen:

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

Messages sind nicht nur Strings – Agenten-Kommunikation muss oft viel mehr als reinen Text transportieren, und die Nachrichtenstruktur ist darauf ausgelegt, dies zu berücksichtigen.

Eine Nachricht kann Folgendes enthalten:

• Text
• Dateien
• strukturiertes JSON
• Bilder
• Referenzen
• Metadaten

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

Parts (Teile)

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

So unterstützt A2A multimodale und strukturierte Kommunikation.

Ein Part kann verschiedene Inhaltstypen enthalten, wie:

• Text
• Filedaten
• strukturierte Daten
• Binärinhalt per Referenz
• JSON-ähnliche Daten

Ein Part kann auch Metadaten wie Folgende enthalten:

• Medientyp
• Dateiname
• zusätzlicher Kontext

Der Medientyp ist wichtig, weil er dem empfangenden Agenten mitteilt, wie der Inhalt zu interpretieren ist.

Zum Beispiel:

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

Dies ist einer der unterschätzten Aspekte von A2A. Agenten-Kommunikation sollte nicht alles in reinen Text verwandeln – wenn ein nachgelagerter Agent eine Tabelle, ein Bild, eine JSON-Payload, eine Protokolldatei oder ein PDF benötigt, sollte das Protokoll diesen Inhalt als solchen erhalten und ihn nicht in einen Absatz verwandeln. Gute Agenten-Systeme vermeiden diese unnötigen Text-Engpä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 Nachricht: Eine Nachricht ist Kommunikation zwischen Agenten, wohingegen ein Artifact ein konkretes Lieferziel 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 Forschungs-Agent sagt: „Ich habe die Antwort gefunden“, ist das eine Nachricht. 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 zusammensetzbar machen. Das Artifact eines Agents wird zum Input eines anderen Agents ohne Verlust der Struktur.

Messages vs Artifacts

Ein einfacher Weg, darüber nachzudenken:

Messages sind Konversation.
Artifacts sind Ausgabe.

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

Zum Beispiel in einem Softwareentwicklungs-Workflow:

• Der Client sendet eine Nachricht mit der Anfrage nach einem Bugfix.
• Der Coding-Agent sendet Nachrichten mit Klärungsfragen.
• Der Coding-Agent arbeitet an der Aufgabe.
• Der Agent gibt Artifacts wie eine Patch-Datei, Testausgabe und Erklärung zurück.

Diese Trennung ist hilfreich, weil sie das Vermischen von Task-Koordination mit Lieferzielen vermeidet und es viel einfacher macht, Outputs zu protokollieren, zu auditieren und an nachgelagerte Verbraucher weiterzugeben.

Ein praktisches Beispiel

Stellen Sie sich vor, ein primärer Assistent benötigt die Hilfe eines Dokumentations-Agenten.

Der Benutzer fragt:

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

Der primäre Assistent überprüft ein Agenten-Register und findet einen Dokumentations-Agenten.

Der Dokumentations-Agent hat eine Agent Card, die besagt, dass er Folgendes kann:

• API-Dokumentation schreiben
• OpenAPI-Specs akzeptieren
• Markdown-Styleguides akzeptieren
• Markdown-Docs erzeugen
• Beispiele in Python und JavaScript erzeugen
• lang laufende Tasks unterstützen
• Artifacts zurückgeben

Der primäre Assistent sendet eine Nachricht mit:

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

Der Dokumentations-Agent erstellt einen Task.

Der Task wechselt in den Zustand „in Bearbeitung“.

Der Dokumentations-Agent kann Nachrichten wie Folgende senden:

Ich extrahiere Endpunkt-Beschreibungen.

Dann:

Ich benötige Klarstellung bezüglich Authentifizierungsbeispielen.

Der primäre Assistent stellt die fehlenden Eingaben bereit.

Der Task setzt fort.

Schließlich gibt der Dokumentations-Agent 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 diese Aufgabe an einen anderen Agenten, kommuniziere bei Bedarf und verfolge das Ergebnis bis zum Abschluss“.

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 Agentenarbeit. Agenten-Tasks können Unsicherheit, mehrere Schritte, Zwischenergebnisse und Nachfolgefragen beinhalten.

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

• Status
• Historie
• Nachrichten
• Artifacts
• Fehler
• Metadaten
• Fortschritt
• Abbruch
• Audit-Informationen

Dies ist nützlich für:

• Forschungs-Workflows
• Code-Generierung
• Datenanalyse
• Compliance-Review
• Dokumentenerstellung
• Incident-Investigation
• 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 auf – A2A versucht, die agentenspezifische Version dieses Musters zu standardisieren, damit Sie es nicht für jede neue Agenten-Integration neu erfinden müssen.

Streaming und Async Work

A2A unterstützt die Idee, dass Agentenarbeit 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

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

Zum Beispiel:

• Hintergrundforschung
• Generierung großer Dokumente
• Multi-Agenten-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. Für SSE, Push-Webhooks, Resubscription, HITL via input_required, Fehlerbehandlung und Produktions-Checklisten, siehe A2A Streaming and Async Tasks for Long-Running Agent Workflows.

Agent Cards und Streaming-Support

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 können nur einfache Request-Response unterstützen, einige können Task-Polling unterstützen, und andere können Push-Benachrichtigungen oder Server-Sent Events unterstützen. Ein guter Client inspiziert die Agent Card, bevor er ein Interaktionsmuster wählt, weshalb Agent Cards nicht nur Dokumentation sind: Sie prägen das Laufzeitverhalten direkt.

A2A und Multimodale Agenten

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

Das ist wichtig, weil echte Agenten-Systeme zunehmend gemischte Inputs und Outputs verarbeiten:

• Text
• Bilder
• Audio
• Video
• PDFs
• Tabellenkalkulationen
• strukturiertes JSON
• Logs
• Code
• Diagramme

Wenn jede Agenten-Grenze alles in Text umwandelt, können wichtige Informationen verloren gehen.

Zum Beispiel sollte ein visueller Troubleshooting-Agent ein Bild als Bild erhalten, nicht als schwache Textbeschreibung. Ein Finanz-Agent 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 Agenten-Grenzen hinweg erhält – und dies ist einer der Orte, an denen das Protokoll wichtiger ist, als es zunächst erscheint, weil Informationsverlust an der Grenze bei jedem Hop in einer Multi-Agenten-Kette kumuliert.

A2A ist kein Agenten-Framework

A2A teilt Ihnen nicht mit, wie Sie einen Agenten bauen.

Es definiert nicht:

• Reasoning-Strategie
• Planungsalgorithmus
• Speichersystem
• Vektordatenbank
• Prompt-Vorlage
• Modell-Anbieter
• Tool-Framework
• Orchestrierungs-Laufzeit
• Evaluierungsmethode

Das ist ein Feature, kein Bug. A2A ist ein Grenzprotokoll, das verschiedenen Agenten-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 Service mit einem stabilen Request-Response-Vertrag haben, kann eine normale API besser sein.

Zum Beispiel:

• Währungsumrechnung
• Adressvalidierung
• Rechnungsverwaltung
• Bildverkleinerung
• Suchendpunkt
• Feature-Flag-Lookup
• interner CRUD-Service

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 agiert:

• es besitzt eine Aufgabe
• es kann nach weiteren Eingaben fragen
• es kann intern Tools verwenden
• es kann Zeit benötigen
• es kann Artifacts erzeugen
• es hat Fähigkeiten, die wertvoll für die Entdeckung sind
• 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-System-Architektur passt

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

Eine nützliche Architektur könnte so aussehen:

Benutzer
  |
  v
Primärer Assistent
  |
  |-- A2A --> Forschungs-Agent
  |-- A2A --> Coding-Agent
  |-- A2A --> Compliance-Agent
  |-- A2A --> Dokumentations-Agent

Jeder spezialisierte Agent kann intern Tools verwenden:

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

Dies gibt Ihnen separate Schichten:

Benutzeroberflächenschicht
Agenten-Koordinationsschicht
Tool-Integrationsschicht
Daten- und Ausführungsschicht

A2A lebt in der Agenten-Koordinationsschicht, MCP lebt oft in der Tool-Integrationsschicht, und normale APIs, Warteschlangen, Datenbanken und Speichersysteme leben darunter – jede Schicht mit ihrer eigenen Abstraktion und ihren eigenen Fehlermodi. Für eine übergreifende Karte, wie LLM-Inferenz, Speicher, Routing, Tooling und Observability in Produktions-Assistenten zusammenpassen, siehe AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

Architektur-Muster: 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 --> Rechts-Agent
  |-- A2A --> Finanz-Agent
  |-- A2A --> Forschungs-Agent
  |-- A2A --> Schreib-Agent

Dieses Muster ist leicht zu verstehen: Der Orchestrator besitzt den gesamten Workflow, und spezialisierte Agenten besitzen domänenspezifische Arbeit. Der Nachteil ist, dass der Orchestrator zu einem Engpass werden kann und eine solide Routing-Strategie benötigt, um effektiv zu delegieren – die zugrunde liegenden Modellselektions- und Orchestrierungs-Trade-offs werden in Multi-Model System Design: When One Model Isn’t Enough behandelt. Dennoch ist dies für die meisten Teams die beste erste Multi-Agenten-Architektur, bevor komplexere Topologien erkundet werden.

Architektur-Muster: Peer-Agenten

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

Zum Beispiel:

Forschungs-Agent --> Daten-Agent --> Charting-Agent --> Schreib-Agent

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

Sie benötigen starke Regeln für:

• wer wen aufrufen darf
• welcher Kontext geteilt werden kann
• wie Schleifen verhindert werden
• wer den finalen Output besitzt
• wie Kosten kontrolliert werden
• wie Delegation auditiert wird

Peer-Agenten-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.

Architektur-Muster: A2A Gateway

Ein produktionsfreundlicheres Muster ist ein A2A-Gateway.

Statt 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
• Rate Limits
• Policy-Checks
• Protokollversions-Handling
• Observability
• Audit-Trails

Dies ist besonders in Unternehmensumgebungen nützlich, wo das Gateway zur Control-Plane für die Agenten-Kommunikation wird – es erzwingt Policy an einem Ort, anstatt sie über jeden Agenten neu zu implementieren. In kleineren Systemen kann dies Overkill 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-to-Agent-Kommunikation kann sensiblen Kontext über Grenzen hinweg bewegen. Sie kann auch Arbeit an Systeme delegieren, die eigene 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 dem Aufrufer angehängt?
• Kann ein Agent Benutzerbefugnisse an einen anderen delegieren?
• Welche Daten können in Nachrichten enthalten sein?
• Welche Artifacts können zurückgegeben werden?
• Wie wird der Task auditiert?
• 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 öffentlich veröffentlicht zu werden. Verschiedene Clients benötigen oft unterschiedliche Ansichten desselben Agents – ein interner Aufrufer kann mehr Fähigkeiten sehen als ein externer Partner, während ein öffentlicher Client möglicherweise nur einen begrenzten Satz sicherer Fähigkeiten sieht.

Sicherheit sollte nicht hinzugefügt werden, nachdem das Agenten-Netzwerk gebaut ist; sie sollte das Netzwerk von Anfang an formen, da das Nachrüsten von Auth- und Berechtigungsgrenzen über eine live Agenten-Topologie erheblich schwieriger ist als das Design von Beginn an. Für die vollständige Behandlung – Threat-Model, Identitätsschichten, Gateway-Control-Plane, Delegationsumfang und Audit-Trails – siehe A2A and MCP Agent Security: Identity, Delegation, and Audit Trails.

Überlegungen zur Observability

A2A-Systeme benötigen starke Observability.

Wenn ein Task Agenten-Grenzen überschreitet, wird das Debugging erheblich schwieriger, da 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 Nachrichten 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 gesamte Kette hinweg verfolgen.

Zum Beispiel:

Benutzeranfrage
  -> Task des primären Assistenten
  -> Task des Forschungs-Agenten
  -> Aufruf des Dokumentensuch-Tools
  -> Zusammenfassungs-Artefakt
  -> finale Antwort

Ohne diesen End-to-End-Trace werden Multi-Agenten-Systeme in der Produktion sehr schwer vertrauenswürdig – Sie können nicht mit Sicherheit beantworten, warum das System eine gegebene Ausgabe produziert hat, geschweige denn identifizieren, wo es schiefgelaufen ist. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production behandelt die Instrumentierungs- und Tooling-Seite dieses Problems im Detail.

Häufige Fehler

Fehler 1: Jedes Tool als Agent zu bezeichnen

Nicht jedes Tool ist ein Agent.

Ein Taschenrechner ist ein Tool. Ein Dateileser ist ein Tool. Ein Datenbankabfrage-Endpunkt ist ein Tool.

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

Fehler 2: Agent Cards zu vage zu gestalten

Eine Agent Card sollte nicht sagen:

Dieser Agent hilft bei Geschäftsaufgaben.

Das ist für jeden Agenten, der versuchen würde, Arbeit intelligent zu routen, nutzlos. Eine gute Karte 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-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 – es zu überspringen bedeutet, dieselbe Lifecycle-Tracking-Logik in jeder Integration neu aufzubauen.

Fehler 4: Alles als Text zurückzugeben

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 in reinen Text ab, es sei denn, reiner Text ist die richtige Ausgabe.

Fehler 5: Kein Berechtigungsmodell

Agenten-Netzwerke ohne Berechtigungsgrenzen sind riskant.

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

Wann sollten Sie A2A verwenden?

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

Gute Gründe sind:

• Agenten werden von verschiedenen Teams betreut
• Agenten werden als separate Services bereitgestellt
• Agenten werden mit verschiedenen Frameworks erstellt
• 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
• Agenten-Fähigkeits-Metadaten 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ötiger Zirkel, wenn das System es nicht ist, und die Kosten dieses Zirkels – hinzugefügte Konzepte, Infrastruktur, Debugging-Oberfläche und Sicherheitsanforderungen – sind real.

Ein minimales mentales Modell

Wenn Sie nur eine Sache merken, merken Sie sich dies:

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

Das ist der Kern von A2A – der Rest handelt hauptsächlich davon, diese fünf Konzepte zuverlässig, beobachtbar und sicher genug zu machen, um sie in echten Produktionssystemen zu verwenden.

Abschließende Gedanken

A2A ist nicht nur ein weiterer KI-Akronym – es ist Teil eines größeren Wandels von isolierten Assistenten hin zu interoperablen Agenten-Systemen. Dieser Wandel wird nicht überall auf einmal geschehen, und viele Anwendungen werden Single-Agenten-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, Nachrichten, die mehr als Text tragen, Artifacts als Outputs erster Klasse sowie Sicherheit, Status und Observability, die Agenten-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 Ansicht, wo A2A in 2026 tatsächlich Produktions-Traction hat – einschließlich Adoption-Tiers, Sicherheitsbedenken, dem Enterprise-Use-Case und einem Entscheidungsframework – siehe Google A2A Protocol in 2026: Adoption, Hype, and Reality.

Meine Meinung: Beginnen Sie nicht mit A2A für kleine Projekte. Beginnen Sie mit einem nützlichen Agenten, guten Tools und klarer Architektur – die AI Systems cluster behandelt selbstgehostete Assistenten, MCP-Server und Agenten-Speicher als zusammenhängendes Set, wenn Sie den breiteren Kontext wünschen. Aber wenn Ihr „Tool“ wie ein anderer autonomer Spezialist mit eigenem Task-Lebenszyklus aussieht, ist es wahrscheinlich nicht mehr nur ein Tool – und dann wird A2A interessant.

Quellen

• A2A Protocol Specification: https://a2a-protocol.org/latest/specification/
• A2A Key Concepts: https://a2a-protocol.org/latest/topics/key-concepts/
• A2A Life of a Task: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2A Agent Discovery: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming and Async Operations: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A and MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/