A2A Protocol erklärt: Wann KI-Agenten Aufgaben delegieren

Das A2A Protocol kommt zum Einsatz, wenn ein Agent Aufgaben an einen unabhängig betriebenen Agenten delegieren soll. Model Context Protocol (MCP) ist die passende Wahl, wenn er auf Tools oder Daten zugreifen muss. A2A v1.0 verändert die Integrationsvorgaben. Entscheidend sind deshalb sowohl die Grenze zwischen den beteiligten Systemen als auch die Protokollversionen, die ihre Endpunkte unterstützen.

MCP vs A2A: Toolzugriff oder Aufgaben delegieren?

MCP verschafft einem Agenten Zugriff auf Funktionen. Mit A2A kann er einen anderen Agenten bitten, die Verantwortung für eine Aufgabe zu übernehmen. Beide Protokolle können im selben System sinnvoll sein.

Model Context Protocol (MCP) standardisiert die Anbindung einer KI-Anwendung an externe Systeme, darunter Tools und Datenquellen. Agent2Agent (A2A) standardisiert die Kommunikation zwischen unabhängigen Agenten. Die offizielle Dokumentation beschreibt die beiden Protokolle als Ergänzung zueinander. Einführung in MCP, A2A und MCP.

MCP in der Praxis: Eine Bestellung nachschlagen

Ein Kundenservice-Agent soll eine Frage zur Lieferung beantworten. Ein MCP-Server stellt dafür ein Tool zur Bestellabfrage bereit. Der Agent übergibt eine Bestellkennung, erhält die Bestelldaten und formuliert daraus die Antwort an den Kunden.

Der betriebliche Nutzen liegt in einer wiederverwendbaren Anbindung an das Bestellsystem. Für den Abruf eines Datensatzes braucht es keinen weiteren Agenten. Der Leitfaden zu MCP-Servern behandelt diese Seite der Entscheidung: die Anbindung von Tools.

A2A in der Praxis: Eine Lieferantenauswahl delegieren

Ein Einkaufsassistent benötigt eine Auswahlliste geeigneter Lieferanten. Ein separater Beschaffungsagent, den ein anderer Anbieter betreibt, verantwortet den Rechercheablauf. Der Einkaufsassistent übermittelt die Anforderungen, beantwortet eine Rückfrage zu den Lieferanforderungen und erhält eine strukturierte Auswahlliste.

Dabei muss der Einkaufsassistent weder wissen, wie der Beschaffungsagent recherchiert, noch welches Modell er verwendet oder wie seine internen Arbeitsschritte aufgebaut sind. Er braucht eine vereinbarte Anfrage und ein verwertbares Ergebnis. Genau für diese Schnittstelle ist A2A gedacht.

Der Beschaffungsagent könnte intern MCP nutzen, um Katalogdaten abzurufen. In diesem Aufbau gilt: A2A übermittelt den Arbeitsauftrag; MCP ermöglicht den Datenzugriff.

Entscheidend ist die benötigte Schnittstelle. Auch hinter einem MCP-Tool kann komplexe Implementierungslogik stecken. A2A ist dann sinnvoll, wenn das andere System als Agent mit auffindbaren Fähigkeiten und einem nachvollziehbaren Aufgabenlebenszyklus auftreten soll. Wie intelligent sein Innenleben wirkt, ist dafür kein brauchbares Entscheidungskriterium.

Was ist das A2A Protocol?

A2A legt gemeinsame Regeln für die Kommunikation zwischen Agenten unterschiedlicher Anbieter oder Frameworks fest. Das aufrufende System kann mit einem Agenten interagieren, ohne Zugriff auf dessen internen Speicher, Tools oder Entscheidungslogik zu benötigen. Die Protokollwebsite bezeichnet dieses Innenleben als opak, also von außen nicht einsehbar. A2A im Überblick.

Die aufrufende Seite ist der A2A-Client. Das System, das die Anfrage annimmt, ist der A2A-Server, auch entfernter Agent genannt. Wer als Gründer eine spezialisierte Funktion einkauft, kann die Integration damit auf die Schnittstelle zum Dienst konzentrieren, statt dessen Implementierung nachbauen zu müssen.

Wer hat A2A entwickelt, und wer betreut das Projekt?

Die offizielle Website formuliert es präzise: „A2A wurde ursprünglich von Google entwickelt und der Linux Foundation übergeben.“ Laut Website betreut ein Technical Steering Committee das Projekt. Die Projektführung geht damit über den ursprünglichen Entwickler hinaus. Projektführung und Open Source.

Das Repository a2aproject/A2A ist die zentrale Anlaufstelle für Spezifikation, SDK-Verweise und Beispiele. A2A selbst ist ein Protokoll. Die Software zum Entwickeln und Betreiben der Agenten muss weiterhin ausgewählt werden.

Die A2A-Spezifikation: Diese Begriffe sind entscheidend

Kommunikation, nachverfolgte Arbeit und Arbeitsergebnis sind unterschiedliche Dinge. Wer sie im Systementwurf trennt, kann das Protokoll leichter sinnvoll einsetzen.

Agent Card: Wie ein Client das Angebot eines Agenten erkennt

Eine Agent Card ist ein JSON-Metadatendokument. Sie beschreibt Identität, Fähigkeiten, unterstützte Funktionen, Verbindungsdaten und Authentifizierungsanforderungen eines Agenten. Damit kann ein Client entscheiden, ob und wie er diesen Agenten kontaktiert. Grundbegriffe.

Im Beschaffungsbeispiel könnte die Karte Fähigkeiten zur Lieferantenrecherche ausweisen. Sie ist der Ausgangspunkt für die Integration. Ob die spätere Auswahlliste die Einkaufskriterien erfüllt, belegt sie nicht.

Der dokumentierte Standardpfad zur Erkennung lautet /.well-known/agent-card.json. Karten lassen sich auch über eine direkte Konfiguration oder ein kuratiertes Verzeichnis beziehen. Für solche Verzeichnisse schreibt A2A keine standardisierte API vor. Agenten finden.

Tasks, Messages, Parts und Artifacts: Was gehört wohin?

Ein Task ist eine zustandsbehaftete Arbeitseinheit mit einer Kennung und einem Lebenszyklus. Eine Message ist ein einzelner Kommunikationsbeitrag. Ein Part enthält den eigentlichen Text, Dateiinhalt oder Dateiverweis oder strukturierte Daten. Ein Artifact ist ein konkretes Ergebnis, das während einer Aufgabe entsteht. Grundbegriffe.

Im Lieferantenbeispiel gehört „In welche Region soll geliefert werden?“ zur Kommunikation. Der nachverfolgte Rechercheauftrag ist der Task. Die fertige Auswahlliste ist ein Artifact. Der Einkaufsablauf sollte die Liste als Arbeitsergebnis übernehmen, statt im Gesprächsverlauf nach etwas zu suchen, das fertig aussieht.

Ein Agent kann eine in sich abgeschlossene Nachricht zurückgeben oder einen Task anlegen. Zusammengehörige Interaktionen werden über contextId gebündelt. Hat ein Task einen Endzustand erreicht, beginnt eine Nachbearbeitung als neuer Task; der alte wird nicht erneut gestartet. Lebenszyklus eines Tasks.

Diese Trennung wird wichtig, wenn der Einkauf nach der Lieferung seine Anforderungen ändert. Die ursprüngliche Auswahlliste sollte eindeutig identifizierbar bleiben, ihre Überarbeitung als neue Aufgabe gelten. So erkennen nachgelagerte Nutzer, welches Ergebnis sie freigegeben haben.

Transport und Bindings: Wie die Operationen übertragen werden

Ein Transport beziehungsweise Protokoll-Binding legt fest, wie die Operationen über die Verbindung übertragen werden. Die Spezifikation definiert Bindings für JSON-RPC, gRPC und HTTP+JSON/REST. Die Schnittstellenangaben in der Agent Card nennen jeweils Endpunkt, Binding und Protokollversion. A2A-Spezifikation.

Polling, Streaming und Push-Benachrichtigungen bestimmen dagegen, wie Aktualisierungen zu einem Task eintreffen. Diese Entscheidung ist vom Binding unabhängig. Für ein Einkaufsdashboard kann Polling genügen; bei einer interaktiven Anwendung können schrittweise eintreffende Aktualisierungen wichtig sein. Vor dem Entwurf der Benutzeroberfläche sollte feststehen, welche Funktionen der konkrete Endpunkt unterstützt.

Was ändert sich mit A2A v1.0?

Bestehende Integrationen brauchen eine Kompatibilitätsprüfung. Eine geänderte Versionsangabe genügt nicht. Die offizielle Seite zu den Neuerungen nennt im Vergleich von v0.3.0 zu v1.0 folgende Änderungen:

• Eine gemeinsame Definition: a2a.proto wird zur maßgeblichen Protokolldefinition, ergänzt um formale Spezifikationen für die Protokoll-Bindings.
• Geänderte Übertragungsformate: Ein einheitlicher Part ersetzt separate Inhaltstypen. Feldnamen ersetzen die kind-Diskriminatoren, und Aufzählungswerte verwenden SCREAMING_SNAKE_CASE.
• Neu strukturierte Agent Cards: supportedInterfaces bündelt die Verbindungsdetails. Die Protokollversion wird für jede Schnittstelle einzeln angegeben.
• Überarbeitete Operationen: Aus message/send wird SendMessage. ListTasks ergänzt gefilterte Listenabfragen mit Cursor-Paginierung.
• Änderungen für den Unternehmenseinsatz: Mandantenfelder, Regeln zur Signaturprüfung von Agent Cards und überarbeitete OAuth-Abläufe beeinflussen den Integrationsentwurf.

Diese Änderungen wurden am 12. Oktober 2026 anhand der Projektseite Neuerungen in v1.0 geprüft.

Bei einem bestehenden Konnektor sollten serialisierte Anfragen, das Einlesen der Antworten, die Erkennung von Agent Cards und die verwendeten Operationen gemeinsam geprüft werden. Eine funktionierende Verbindung allein belegt noch nicht, dass sich jede Interaktion weiterhin korrekt verhält.

Welche Frameworks und Plattformen unterstützen A2A?

Dokumentierte Implementierungen gibt es bereits. Bei unterstützten Versionen und Funktionen unterscheiden sie sich jedoch. Ausschlaggebend sollte das Verhalten sein, das der eigene Workflow benötigt. Die folgenden Angaben zu Unterstützung und Einschränkungen wurden am 12. Oktober 2026 anhand der öffentlich zugänglichen Herstellerdokumentation geprüft. Ein Produkttest mit angemeldetem Nutzerkonto fand nicht statt.

Google Agent Development Kit

Google Agent Development Kit (ADK) ist ein Framework zur Entwicklung von Agenten. Die Dokumentation beschreibt to_a2a, um einen Agenten bereitzustellen und seine Agent Card zu erzeugen. Die Python-Integration für A2A ist als experimentell gekennzeichnet. Laut Dokumentation werden a2a-sdk 0.3.x und 1.x.x unterstützt; für neue Integrationen wird auf 1.x.x verwiesen. ADK-Anleitung zum Bereitstellen eines Agenten.

Außerdem dokumentiert ADK RemoteA2aAgent für die Nutzung eines entfernten Agenten. Damit gibt es für beide Seiten einer Aufgabenübergabe dokumentierte Einstiegspunkte. Der experimentelle Status sollte auch dann in die Entscheidung über den Einsatz einfließen, wenn der Wrapper die Anbindung bequem macht. ADK-Anleitung zum Einbinden eines entfernten Agenten.

LangGraph über LangSmith Agent Server

LangSmith Agent Server, die dokumentierte Bereitstellungsschicht für LangGraph-Deployments, stellt unter /a2a/{assistant_id} einen A2A-Endpunkt bereit. Die Dokumentation nennt das JSON-RPC-Binding der Version v1.0 und die Annahme von Methodennamen aus v0.3. Das Zustandsobjekt des Graphen muss ein Feld namens messages enthalten. A2A-Dokumentation von LangSmith.

Dieselbe Seite nennt Grenzen: gRPC und HTTP+JSON sind nicht implementiert. SubscribeToTask und die Konfiguration von Push-Benachrichtigungen werden bislang ebenfalls nicht unterstützt. Nachrichten-Streaming ist möglich, daraus folgt aber keine Unterstützung sämtlicher Abonnement- oder Benachrichtigungsoperationen. Gerade für Hintergrundaufgaben sollte deshalb vorab geprüft werden, welche Operationen tatsächlich verfügbar sind.

CrewAI und CrewAI AMP

CrewAI, ein Framework zur Koordination von Agenten, dokumentiert A2AClientConfig für die Delegation an entfernte Agenten und A2AServerConfig für die Bereitstellung eigener Agenten. Ein Agent lässt sich für beide Rollen konfigurieren. CrewAI-Dokumentation zur Delegation.

Die Bereitstellungsplattform CrewAI AMP kennzeichnet A2A-Server-Agenten als Early Release und nennt die Protokollversionen 0.2 und 0.3. Sie beschreibt zudem einen persistenten, verteilten Speicher anstelle der Zustandsverwaltung im Arbeitsspeicher, die die Open-Source-Implementierung verwendet. Aus der A2A-Unterstützung von CrewAI lässt sich daher nicht ableiten, dass ein AMP-Endpunkt v1.0 unterstützt. A2A auf AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, eine verwaltete Agentenplattform, dokumentiert einen allgemein verfügbaren Tooltyp a2a für die Protokollversion 1.0. Der ältere Tooltyp a2a_preview unterstützt 0.3 und bleibt in der Vorschauphase. Microsoft empfiehlt für neue Integrationen den allgemein verfügbaren Typ. A2A-Dokumentation von Foundry.

Die Seite hält außerdem fest: Foundry-Agenten als Ziel unterstützen ausschließlich Text und keine Streaming-Antworten. Ein Workflow, der ein multimediales Ergebnis per Streaming benötigt, muss diese Einschränkung berücksichtigen. Die möglichen Inhaltstypen eines Protokolls sind keine Zusage, dass jede Hostingplattform sie implementiert.

Bei der übergeordneten Framework-Auswahl hilft der Vergleich von KI-Agenten-Frameworks. Die Integrationshinweise hier beantworten eine engere Frage: Welche A2A-Schnittstelle ist für das bereitstellende System dokumentiert?

Was bedeutet A2A für Entwicklung, Betrieb und Einkauf?

Der Nutzen liegt in einer besser wiederverwendbaren Integrationsschnittstelle — sofern sich der Betrieb des zusätzlichen Dienstes lohnt. Was daraus folgt, hängt von der jeweiligen Verantwortung ab.

Entwicklung: Vor der Wahl eines Transports muss feststehen, welche Aufgabe delegiert wird. „Eine Auswahlliste mit Quellen und Begründungen erstellen“ beschreibt die Zuständigkeit eines Dienstes. „Diese Datenbankabfrage ausführen“ beschreibt die Schnittstelle zu einem Tool. Diese Unterscheidung bleibt relevant, selbst wenn beide Wege letztlich Modellaufrufe auslösen.

Betrieb: Auch nach der Übergabe braucht die Aufgabe einen klaren Verantwortlichen. Im Einkaufsbeispiel muss jemand festlegen, was bei Rückfragen des Beschaffungsagenten, bei ausbleibenden Antworten oder bei einer Auswahlliste geschieht, die die Abnahmekriterien verfehlt. Ein gemeinsames Nachrichtenformat klärt diese Zuständigkeiten nicht.

Einkauf und Gründung: Gefragt sind die unterstützte Protokollversion, das Binding, die verfügbaren Operationen und Inhaltstypen sowie der Freigabestatus für den Betrieb. Diese Angaben müssen neben den Anforderungen des eigenen Workflows stehen. Eine pauschale Kompatibilitätszusage reicht nicht aus, um sich auf eine Integration festzulegen.

Wie lässt sich der A2A-Betrieb budgetieren?

Für A2A gibt es keine einheitliche Betriebskonfiguration, aus der sich eine Monatsrechnung ableiten ließe. Bei einem gehosteten Spezialisten fallen andere Kosten an als bei einem selbst betriebenen Dienst. Die Protokolldokumentation legt auch keinen allgemeingültigen Plattformpreis fest.

Für die Planung lässt sich über denselben Budgetzeitraum folgende Rechnung verwenden:

Nettonutzen der Integration = vermiedene Konnektorkosten abzüglich Migrationskosten, zusätzlicher Infrastrukturkosten und laufender Betriebskosten.

Zu den laufenden Kosten gehören Modellnutzung, Hosting, Speicherung der Tasks, Überwachung und die Zuständigkeit bei Störungen. Für jeden Posten zählen die eigenen Kosten. A2A lohnt sich, wenn es genügend wiederholte Integrationsarbeit einspart, um die Pflege der zusätzlichen Schnittstelle zu decken.

Was wird bei A2A überschätzt?

Ein gemeinsames Protokoll macht unbekannte Agenten weder vertrauenswürdig noch verteilte Arbeit automatisch zuverlässig. Trotz sinnvoller Standardisierung bleiben wichtige Entscheidungen bei der Anwendung.

Eine Agent Card beschreibt das Angebot eines Dienstes. Ob dessen Betreiber vertrauenswürdig ist und sein Ergebnis akzeptiert wird, muss weiterhin entschieden werden. Laut A2A-Leitfaden für den Unternehmenseinsatz muss die Implementierung Authentifizierung und Autorisierung durchsetzen. Das schließt Berechtigungen für die zugrunde liegenden Aktionen ein. Leitfaden zur Implementierung im Unternehmen.

Im Beschaffungsablauf sollte die Erlaubnis zur Recherche nicht stillschweigend eine Einkaufsbefugnis einschließen. Eine Empfehlung abzugeben und eine Bestellung auszulösen, sollten in der Anwendung getrennte Berechtigungen sein.

Ein zurückgegebenes Artefakt, der Status seines Tasks und der eigene Abnahmevermerk sollten getrennt verwaltet werden. Bevor ein delegierter Workflow Bestellungen auslösen darf, muss feststehen, wie die Anwendung wiederholte Geschäftsvorgänge erkennt und bei ungewissem Ausgang wieder einen eindeutigen Zustand herstellt.

Überzogen wäre auch, jeden internen Aufruf eines Unteragenten mit A2A abzuwickeln. Das Projekt schließt Vorgaben für interne Unteragenten- oder Toolaufrufe ausdrücklich aus seinem Geltungsbereich aus. Unterliegen die Komponenten bereits denselben anwendungsinternen Vereinbarungen, können die nativen Möglichkeiten des Frameworks zur Verknüpfung genügen. Geltungsbereich von A2A.

Wann braucht es A2A, MCP oder beides?

Ausgangspunkt ist die Systemgrenze, die im Produkt heute tatsächlich besteht.

MCP eignet sich, wenn ein Agent über wiederverwendbare Toolschnittstellen auf Geschäftssysteme, Dateien oder APIs zugreifen soll. Für das Bereitstellen einer eigenen Funktion hilft die Anleitung für einen MCP-Server mit Python. Geht es anschließend darum, den Zugriff über diese Verbindungen hinweg zu steuern, behandelt der Leitfaden zu MCP-Gateways diese Ebene.

A2A eignet sich, wenn ein anderer, unabhängig betriebener Agent eine eigenständige Aufgabe verantwortet und ein gemeinsamer Weg benötigt wird, um seine Schnittstelle zu finden, Anweisungen auszutauschen und den Arbeitsfortschritt zu verfolgen. Der Einstieg ist sinnvoll, sobald dieser Integrationsbedarf besteht und für die Endpunkte kompatible Funktionen dokumentiert sind.

Beide Protokolle passen, wenn ein Agent an einen Spezialisten delegiert, der seinerseits Tools und Daten benötigt. Das Beschaffungsbeispiel zeigt diesen Aufbau: A2A für den delegierten Rechercheauftrag, MCP für den Katalogzugriff innerhalb eines Agenten.

A2A kann warten, solange der externe Spezialist nur eine Idee ist. Ein Agent, der mit seinen vorhandenen Tools ausreichend gut arbeitet, braucht allein wegen eines neuen Protokolls für die Kommunikation zwischen Agenten keine Änderung. Ebenso wenig benötigt jeder interne Funktionsaufruf einen der beiden Standards. Sinnvoll ist das Verbindungsprotokoll, das ein konkretes Integrationsproblem löst.

Der nächste Schritt bei der Umsetzung

Zuerst wird die Übergabe für ein klar abgegrenztes Geschäftsergebnis festgelegt. Erst danach folgt die Migration des umgebenden Systems. Bei einem Einkaufsassistenten bietet sich eine Lieferantenauswahlliste als Anfang an. Das Ausführen von Bestellungen bleibt zunächst außerhalb des Umfangs.

1. 1

   Ein abnahmefähiges Artefakt definieren

   Festlegen, welche Informationen die Auswahlliste enthalten muss, welche Mängel zur Ablehnung führen und welche Anwendung das akzeptierte Ergebnis erfasst. Der entfernte Agent erhält eine klar begrenzte Verantwortung.

2. 2

   Die dokumentierten Schnittstellen abgleichen

   Protokollversionen von Client und Server, Binding, Authentifizierungsanforderungen und benötigte Operationen festhalten. Prüfen, ob der Workflow Streaming oder Push-Zustellung benötigt und ob beide Endpunkte dies unterstützen.

3. 3

   Den Umgang mit offenen Ergebnissen planen

   Klären, wer Rückfragen, Zeitüberschreitungen, Ablehnungen und eine unklare Antwort nach einem erneuten Versuch bearbeitet. Festlegen, was Nutzer während der Bearbeitung sehen und wie ein überarbeitetes Artefakt eine frühere Fassung ersetzt.

Diese Vereinbarung schafft eine konkrete Grundlage für den Einsatz von A2A. Zeigt sich dabei, dass der vermeintliche Spezialist lediglich einen Datensatz abruft, sollte zuerst die Toolanbindung umgesetzt werden.

Häufige Fragen vor dem Einsatz von A2A

Lässt sich A2A ohne MCP nutzen?

Ja. A2A schreibt nicht vor, wie der entfernte Agent auf seine eigenen Tools und Daten zugreift. MCP ist hilfreich, wenn zusätzlich standardisierte Toolanbindungen benötigt werden. So ergänzen sich die Protokolle.

Müssen beide Agenten dasselbe Framework verwenden?

Nein. Interoperabilität über Framework-Grenzen hinweg ist ein zentrales Ziel von A2A. Zusammenpassen müssen die bereitgestellte Schnittstelle und die für die Interaktion benötigten Funktionen. Die interne Implementierung der Agenten muss nicht übereinstimmen. A2A im Überblick.

Praktische Anleitungen für den Aufbau nützlicher Agentensysteme gibt es im Newsletter.