Google A2A-Protokoll 2026: Adoption, Hype und Realität

A2A ist nicht tot. Es ist nur nicht universell.

Inhaltsverzeichnis

Googles Agent2Agent-Protokoll, meist abgekürzt als A2A, hatte ein seltsames erstes Jahr.

Als Google A2A im April 2025 ankündigte, war die Botschaft klar: KI-Agenten, die von verschiedenen Anbietern, Frameworks und Teams entwickelt wurden, brauchten einen standardisierten Weg der Kommunikation. Das Protokoll versprach Agenten-Discovery, Task-Delegation, Nachrichtenaustausch, Streaming-Updates und das Teilen von Artefakten. Die Reaktion war jedoch considerably weniger klar als die Ankündigung selbst.

Einige Entwickler sahen in A2A die fehlende Schicht für die Kommunikation zwischen Agenten im aufstrebenden agentic Stack. Andere sahen darin nur ein weiteres Google-Protokoll, ein weiteres Akronym und einen weiteren Versuch, einen Markt zu definieren, bevor dieser echte produktive Bedürfnisse hatte. Die skeptische Sichtweise führte auf eine einzige Frage hinaus: „Wir haben doch schon MCP. Warum brauchen wir A2A?“ Das war 2025 eine berechtigte Frage, und sie bleibt es auch 2026 – obwohl sich die Antwort considerably verschoben hat.

Zwei KI-Agentensysteme, verbunden durch die A2A-Protokollbrücke

A2A ist nicht tot, aber es ist auch nicht universell nützlich. Die praktische Realität ist, dass A2A in einem spezifischen Kontext tatsächlich wertvoll wird: dort, wo Agenten unabhängige Systeme mit eigener Eigentümerschaft, Tools und Vertrauensgrenzen sind, anstatt nur interne Funktionen oder Tool-Wrapper zu sein. Diese Unterscheidung zwischen Tool-Integration und Agenten-Delegation ist genau das, was das Protokoll adressieren soll, und das Verständnis dafür ist der Schlüssel, um A2A ohne Hype in beide Richtungen zu bewerten.

Was ist Googles A2A-Protokoll?

A2A steht für Agent2Agent Protocol, und dieser Name fasst seinen Zweck präzise zusammen. Es handelt sich um einen offenen Standard für die Kommunikation und Interoperabilität zwischen unabhängigen KI-Agentensystemen – spezifisch also Agenten, die mit verschiedenen Frameworks, Sprachen oder Vendor-Stacks gebaut sein können.

A2A dreht sich nicht hauptsächlich darum, einen Agenten mit einer Datenbank, einem Dateisystem, einem Kalender, einer API oder einem Suchindex zu verbinden. Das ist eher die Aufgabe von MCP, dem Model Context Protocol. A2A geht um etwas anderes: Einen Agenten, der mit einem anderen Agenten kommuniziert und das Peer-System als Akteur mit eigenen Fähigkeiten behandelt, anstatt als passive Datenquelle.

Ein typischer A2A-Flow könnte Folgendes beinhalten:

Entdeckung eines Agenten über eine Agent Card
Lesen der Fähigkeiten und Kapazitäten des Agenten
Senden einer Aufgabe
Austausch von Nachrichten
Empfang von Statusupdates
Behandlung von Zuständen, in denen Eingaben erforderlich sind
Empfang von End-Artefakten
Verfolgung von Abschluss, Fehler oder Abbruch

Das wichtige Wort in dieser Liste ist „Aufgabe“ (Task). A2A ist nicht nur ein Funktionsaufruf mit einem anderen Wrapper – es ist ein Protokoll für den Lebenszyklus von Aufgaben zur Zusammenarbeit von Agenten, das den gesamten Bogen von der Entdeckung und Delegation über die Ausführung und Statusupdates bis hin zur Rückgabe von Artefakten abdeckt. Für eine tiefe technische Durcharbeitung jedes Konzepts – Agent Cards, Task-Lebenszyklus, Nachrichten, Parts und Artefakte – siehe Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt.

Warum A2A leicht zu verspotten war

A2A kam auf einen Markt, der bereits in Agenten-Akronymen ertrank.

Bis 2025 hatten es Entwickler bereits mit Folgendem zu tun:

LLM-APIs
Function Calling
Tool Calling
Agent-Frameworks
MCP-Server
RAG-Pipelines
Workflow-Engines
Multi-Agent-Orchestrierungs-Bibliotheken
Custom JSON-Protokolle
Interne Plugin-Systeme

Als Google also A2A ankündigte, war eine häufige Reaktion vorhersehbar:

„Brauchen wir wirklich noch einen Standard?“

Der Skeptizismus war nicht irrational und kam aus mehreren Richtungen gleichzeitig. A2A sah so aus, als würde es mit MCP überschneiden. Es kam von Google, was einige Entwickler über das langfristige Engagement sorgen ließ. Es kam, bevor die meisten Teams grundlegende Probleme wie Tool-Zugriff, Prompt-Injection, Observability, Kostenkontrolle und Sicherheit für Single-Agent-Systeme gelöst hatten.

In diesem Umfeld klang „Agent-to-Agent-Interoperabilität“ ambitioniert, aber auch etwas vorzeitig.

Und um ehrlich zu sein, brauchten viele KI-Agenten-Demos im Jahr 2025 A2A überhaupt nicht.

Sie brauchten bessere Prompts, bessere Tools, bessere Berechtigungen, bessere Retry-Logik und bessere Logs.

Das Update 2026: A2A ist nicht tot

Die große Veränderung in 2026 ist, dass A2A nicht mehr nur eine Google-Ankündigung ist.

Bis April 2026 meldete die Linux Foundation, dass das A2A-Projekt 150 unterstützende Organisationen überschritten hatte, große Cloud-Plattform-Integrationen erlangt hatte und Produktionsbereitstellungen in mehreren Branchen erreichte.

Das bedeutet nicht, dass jeder Anspruch ohne Skepsis schluckbar sein sollte. „Unterstützt von“ ist nicht dasselbe wie „tief in der Produktion von den meisten Entwicklern genutzt“. Protokoll-Ökosysteme sehen in Pressemitteilungen oft größer aus, als sie im täglichen Engineering-Alltag wirken.

Das Signal ist jedoch bedeutsam, weil es schwerer zu entkräften ist. A2A hat eine wichtige Linie überschritten: Es ist nicht mehr nur ein Google-Blogpost. Es hat eine formelle Spezifikation, Governance-Momentum, öffentliche Beispiele, SDK-Arbeit, Aufmerksamkeit von Cloud-Plattformen und ein wachsendes Ökosystem um Agenten-Interoperabilität. Das macht das Label „tot“ technisch und adoptionstechnisch schwer zu verteidigen.

Eine besser verteidigbare Kritik ist, dass A2A am Leben ist, aber sein nützlicher Anwendungsbereich enger ist, als der Hype suggeriert.

A2A vs. MCP: Die Verwirrung, die nicht aufhören wollte

Die meisten Verwirrungen rund um A2A stammen aus seiner Beziehung zu MCP.

MCP, erstellt von Anthropic, standardisiert, wie KI-Anwendungen mit externen Tools und Datenquellen verbunden werden. MCP-Server exponieren Tools, Ressourcen und Prompts. KI-Hosts und Clients konsumieren sie.

In einfachen Worten:

MCP verbindet Agenten mit Tools.
A2A verbindet Agenten mit anderen Agenten.

Das klingt sauber, aber die reale Welt ist considerably unordentlicher. Ein MCP-Server kann etwas exponieren, das sehr agentenhaft aussieht – zum Beispiel ein MCP-Tool namens research_company, das intern Suche, Retrieval, Zusammenfassung, Ranking und Berichtserstellung ausführt. Aus Sicht des MCP-Hosts ist es ein Tool. Aus Architektursicht verbirgt es einen agentenartigen Workflow hinter einer Funktionsaufruf-Grenze. Diese Ambiguität ist genau der Grund, warum einige Entwickler argumentierten, A2A sei unnötig: Wenn ein Agent als MCP-Tool dargestellt werden kann, warum ein separates Protokoll erstellen?

Die Antwort ist, dass A2A Dingen eine erstklassige Struktur gibt, die MCP eher umständlich behandelt:

Agenten-Discovery
Agenten-Fähigkeiten
Task-Lebenszyklus
Langlaufende Arbeiten
Multi-Turn-Task-Status
Agent-to-Agent-Nachrichten
Artefakte
Zusammenarbeit zwischen undurchsichtigen Agenten
Delegation über organisatorische Grenzen hinweg

MCP kann viel umfassen, aber alles als Tool zu wrappen wird irgendwann eine schlechte Abstraktion. Irgendwann hat ein Spezialsystem so viel eigenen Status, eigene Richtlinien, Lebenszyklus und Entscheidungsbefugnis, dass es als Tool zu modellieren die Architektur verschleiert, anstatt sie zu vereinfachen. Das ist der Wendepunkt, an dem es sich auszahlt, einen Peer-Agenten als Peer-Agenten – und nicht als Funktionsaufruf – zu behandeln. Für einen detaillierten Vergleich, wo die Grenze in der Praxis verläuft, siehe A2A vs. MCP: Brauchen KI-Agenten wirklich beide Protokolle?

Das beste mentale Modell: MCP unten, A2A oben

Die sauberste Architektur ist nicht „A2A vs. MCP“.

Die sauberste Architektur ist geschichtet:

flowchart TD U["Benutzer oder Anwendung"] O["Primärer Assistent / Orchestrierer"] S1["Spezialist-Agent A"] S2["Spezialist-Agent B"] T1["Tools, APIs, Dateien, Datenbanken"] T2["Weitere Tools und Datenquellen"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

In diesem Modell:

A2A ist die Agenten-Zusammenarbeitsschicht.
MCP ist die Tool-Integrationsschicht.

Das ist das Muster, das 2026 am meisten Sinn ergibt, und es ist das Framing, auf das sich die meisten ernsthaften Agenten-Architekten zubewegen. A2A sollte MCP nicht ersetzen, und MCP sollte nicht gezwungen werden, jede Agenten-Grenze darzustellen – sie lösen unterschiedliche Probleme auf verschiedenen Schichten des Stacks. Das Framing eines „Protokoll-Kriegs“ ist meist faule Analyse, die gute Schlagzeilen liefert, aber Ingenieuren bei der Gestaltung besserer Systeme nicht hilft.

Wo A2A tatsächlich nützlich ist

A2A wird nützlich, wenn ein Agent nicht mehr nur ein Bibliotheksaufruf innerhalb Ihrer Anwendung ist.

Es ist nützlich, wenn Agenten:

Unabhängig bereitgestellt werden
Von verschiedenen Teams besitzen werden
Mit verschiedenen Frameworks gebaut werden
Von Anbietern exponiert werden
Mit eigenen Tools und Berechtigungen laufen
Für langlaufende Tasks verantwortlich sind
Artefakte statt einfacher Werte zurückgeben
Teil eines breiteren Multi-Agent-Workflows sind

Stellen Sie sich zum Beispiel einen Enterprise-Assistenten vor, der einen Lieferanten-Risikobericht vorbereiten muss.

Er könnte Arbeit delegieren an:

Einen Beschaffungs-Agenten
Einen Rechtsüberprüfungs-Agenten
Einen Finanz-Agenten
Einen Compliance-Agenten
Einen Marktforschungs-Agenten
Einen Berichtsschreib-AGENTEN

Jeder Agent hat sein eigenes Domänenwissen, Tools, Regeln, Berechtigungen und Audit-Anforderungen.

Für ein solches System ist A2A nicht absurd. Es ist eine vernünftige Grenze.

Der primäre Assistent sollte keinen direkten Zugriff auf jede Beschaffungsdatenbank, jeden Rechtsrichtlinien-Store, jede Finanz-Tabelle und jeden Compliance-Workflow benötigen. Er sollte den zuständigen Agenten bitten, die Aufgabe auszuführen.

Das ist die wesentliche Unterscheidung: Tool-Zugriff ist eine vertikale Verbindung zwischen einem Agenten und seinen Ressourcen, während Domänen-Delegation ein horizontaler Übergang zwischen autonomen Agenten ist, jeder mit seiner eigenen Grenze von Autorität und Verantwortung. Das geschichtete Modell dafür, wie diese Komponenten kombiniert werden – LLM, Speicher, Tooling, Routing und Observability – wird in KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Observability behandelt.

Wo A2A immer noch überbewertet ist

A2A ist überbewertet, wenn es als Pflichtinfrastruktur für jedes KI-Projekt dargestellt wird.

Die meisten Projekte brauchen es nicht.

Wenn Sie einen lokalen Coding-Assistenten, einen Chatbot für Ihre Dokumentation, einen kleinen internen Automatisierungsagenten oder einen einzelnen Workflow bauen, der eine Handvoll Tools aufruft, ist A2A wahrscheinlich unnötig.

Sie benötigen möglicherweise:

MCP
Gute Tool-Schemas
Guardrails
Evaluation
Logging
Kostenkontrolle
Retry-Logik
Bessere Prompts
Besseres Retrieval

Sie brauchen wahrscheinlich kein volles Agent-to-Agent-Protokoll.

A2A kann ein Fehler sein, wenn:

Es nur einen Agenten gibt
Alle Komponenten in einer Codebasis leben
Workflows kurz und synchron sind
Agenten keine Discovery benötigen
Agenten keinen unabhängigen Task-Status benötigen
Es keine externen Agenten-Anbieter gibt
Eine API oder eine Queue einfacher wäre
Das Team die zusätzliche Komplexität nicht betreiben kann

Ein Protokoll ist nicht kostenlos. Es fügt Konzepte, Fehlermodi, Debugging-Overhead, Sicherheitsbedenken und operative Arbeit hinzu.

In vielen kleinen Systemen ist die Adoption von A2A Architektur-Cosplay – die Übernahme des Vokabulars verteilter Agentensysteme ohne die tatsächlichen Grenzprobleme, die das Protokoll wertvoll machen.

A2A und das Google-Problem

Ein Teil des A2A-Skeptizismus stammt von Google selbst.

Entwickler haben ein langes Gedächtnis. Wenn Google eine Plattform, ein Protokoll, ein Produkt oder ein Ökosystem startet, fragen sich viele Ingenieure sofort:

„Wird das in drei Jahren noch existieren?“

Diese Reaktion ist dem technischen Design von A2A nicht völlig gerecht, aber sie ist ein echter Adoptionsfaktor.

Die Hosting-Geschichte der Linux Foundation hilft hier. Dass A2A Teil eines breiteren offenen Governance-Umfelds wird, macht es weniger abhängig von Googles internen Prioritäten.

Das garantiert keinen Erfolg. Offene Governance schafft keine Entwickler-Adoption magisch. Aber sie reduziert eines der größten Bedenken: Dass A2A nur ein von Google kontrollierter strategischer Zug ist.

2026 sollte A2A weniger als „Googles Protokoll“ und mehr als ein aufstrebender Standard für Agenten-Interoperabilität betrachtet werden, den Google mitgestartet hat.

Das ist eine gesündere Brille, und sie macht es einfacher, die technischen Verdienste von A2A auf ihre eigenen Bedingungen zu bewerten, anstatt sie durch den Filter von Googles historischer Beziehung zu Entwickler-Ökosystemen zu sehen.

Adoption: Starkes Signal, aber nicht die ganze Geschichte

Die berichteten 150+ unterstützenden Organisationen sind bedeutsam, sollten aber nicht mit universeller Entwickler-Adoption verwechselt werden. „Unterstützt von“ ist ein Spektrum, kein Binärwert, und es hilft, Adoptionsansprüche mit diesem Hintergrund zu lesen.

Am schwächsten Ende steht die Logo-Adoption: Ein Unternehmen sagt, es unterstützt den Standard, was echte Implementierung, strategische Positionierung, einen Prototypen oder einfach nur geplante Unterstützung widerspiegeln kann, die sich noch nicht materialisiert hat. Etwas stärker ist die SDK-Adoption, wo Entwickler tatsächlich mit verfügbaren Bibliotheken, Beispielen und Dokumentation bauen können – das bedeutet, dass das Protokoll von Slideware in die funktionierende Implementierung gewechselt ist, und echte Ingenieure es für ihre Zeit wert befunden haben. Noch stärker ist die Plattform-Adoption, wo Clouds, Agent-Frameworks und Enterprise-Systeme echte native Unterstützung exponieren, was A2A zu einer plausiblen Standard-Architekturentscheidung macht, anstatt etwas, das Teams selbst zusammenflicken müssen.

Die einzige Adoptionsebene, die wirklich für die langfristige Ökosystemgesundheit zählt, ist die Produktionsbeibehaltung. Um ein Gefühl dafür zu bekommen, wie echte Adoptionskurven im KI-Agenten-Bereich aussehen – gemessen in GitHub-Stars, OpenRouter-Tokens und Download-Trends – zeigt die OpenClaw vs. Hermes Agent Popularitätsdaten, wie schnell Momentum aufbaut und plateau, sobald die Energie der Early Adopters nachlässt.: Teams, die das Protokoll für Live-Workflows jenseits der ersten 90-Tage-Honeymoon-Phase nutzen. Das Update der Linux Foundation von 2026 behauptet Produktionsnutzung in mehreren Branchen, was ein bedeutender Beweis ist. Aber die nützlichere Frage ist nicht „wer unterstützt A2A?“ – es ist „wer hält A2A in der Produktion, nachdem der erste echte operative Vorfall aufgetreten ist?“. Langfristige Beibehaltung unter Druck ist das Signal, das echte Infrastruktur von Protokoll-Theater trennt.

Der echte Test: Beibehaltung in der Produktion

Entwickler-Hype ist billig, und Produktionsbeibehaltung ist teuer. Die beiden sind selten proportional, weshalb die 90-Tage-Beibehaltungsfrage wichtiger ist als Begeisterung in der Launch-Woche.

A2A wird sich beweisen, wenn Teams es weiter nutzen, nachdem sie auf Folgendes stoßen:

Authentifizierungsprobleme
Autorisierungsprobleme
Agenten-Identitätsprobleme
Debugging-Probleme
Randfälle im Task-Lebenszyklus
Streaming-Fehler
Versionskompatibilität
Vendor-Unterschiede
Kostenüberraschungen
Sicherheitsüberprüfungen
Audit-Anforderungen
Menschliche Genehmigungsworkflows

Hier scheitern viele Agent-Frameworks und Protokolle. Sie sehen in Diagrammen elegant aus, werden dann aber in der Produktion schmerzhaft.

A2A hat einen guten Grund zu existieren, aber gute Gründe übersetzen sich nicht automatisch in Produktionsresilienz. Das Protokoll muss die operative Realität überleben, auf die es auf dem Weg von der Demo zur Bereitstellung trifft.

Das beste Zeichen für A2A in 2026 ist nicht, dass Leute Blogposts darüber schreiben. Das beste Zeichen ist, dass Enterprises damit beginnen, es für echte Multi-Agenten-Grenzen zu nutzen.

Das schlimmste Zeichen wäre, wenn Entwickler es nur in Demos nutzen, während Produktionssysteme auf Custom-APIs und Queues zurückgreifen.

Sicherheit ist die größte ungelöste Frage

A2As härteste Probleme sind keine Syntax- oder Spezifikationsprobleme. Sie sind Vertrauensprobleme, die entstehen, wenn man autonome Agenten tatsächlich über organisatorische oder Systemgrenzen hinweg bereitstellt.

Wenn ein Agent mit einem anderen Agenten spricht, werden mehrere Fragen dringlich:

Wer ist dieser Agent?
Wem gehört er?
Was darf er wissen?
Was darf er tun?
Kann er Arbeit weiter delegieren?
Kann er Tools im Namen eines Benutzers aufrufen?
Kann er die Benutzerabsicht bewahren?
Kann er beweisen, was geschehen ist?
Kann er nach Abschluss der Aufgabe auditiert werden?

Diese Fragen sind in Enterprise-Umgebungen nicht optional.

A2A macht die Agenten-Zusammenarbeit einfacher. Es schafft auch neue Stellen, an denen Vertrauen brechen kann.

Zum Beispiel:

Ein bösartiger Agent könnte seine Fähigkeiten falsch darstellen.
Ein kompromittierter Agent könnte sensiblen Kontext anfordern.
Eine delegierte Aufgabe könnte die Autorität des Benutzers überschreiten.
Ein Agent könnte vergiftete Artefakte zurückgeben.
Eine Kette von Agenten könnte die Verantwortlichkeit unklar machen.
Sensible Daten könnten über Grenzen hinweg fließen, ohne angemessenes Logging.

Aus diesem Grund brauchen ernsthafte A2A-Systeme mehr als nur Protokollkonformität.

Sie benötigen:

Starke Agenten-Identität
Gebietsweise Autorisierung
Audit-Logs auf Task-Ebene
Delegierungsverfolgung
Menschliche Genehmigung für riskante Aktionen
Artefakt-Provenienz
Rate Limits
Policy-Durchsetzung
Observability über Agenten-Grenzen hinweg

A2A ist an sich keine Sicherheitsarchitektur – es ist ein Kommunikationsprotokoll, das innerhalb einer solchen deployed werden muss, mit expliziten Entscheidungen über Identität, Autorisierung, Audit und Policy-Durchsetzung an jeder Grenze, die es überschreitet.

A2A und die Idee des Agenten-Marktplatzes

Einer der interessanteren langfristigen A2A-Anwendungsfälle sind Agenten-Marktplätze.

Wenn Agenten Fähigkeiten über Agent Cards werben können, dann können andere Agenten oder Plattformen sie entdecken, bewerten und Tasks senden.

Das schafft eine mögliche Zukunft, in der Agenten-Fähigkeiten modularer werden:

Ein Steuer-Agent
Ein Rechts-Agent
Ein Code-Review-Agent
Ein Reiseplanungs-Agent
Ein Sicherheitsanalyse-Agent
Ein Beschaffungs-Agent
Ein Datenqualitäts-Agent

Jeder könnte eine standardisierte Schnittstelle für aufgabenbasierte Zusammenarbeit exponieren.

Das klingt aufregend, aber genau hier wird Hype gefährlich.

Ein offener Agenten-Marktplatz benötigt mehr als Agent Cards. Er braucht Identität, Reputation, Abrechnung, Compliance, Sandboxing, Haftung, Versionierung und Streitbeilegung.

Ohne diese wird ein Agenten-Marktplatz zu einem Sicherheitsvorfall, der nur darauf wartet, zu passieren.

A2A ist ein nützlicher Baustein für diese Art von Zukunft, aber es ist nur ein Teil eines viel größeren Puzzles, das auch Identitätssysteme, Reputationsmechanismen, Abrechnungsinfrastruktur, Compliance-Kontrollen und Streitbeilegung erfordert, bevor es ein sicherer Markt ist, in dem man operieren kann.

A2A für interne Enterprise-Agenten

Der realistischere kurzfristige Anwendungsfall sind keine öffentlichen Agenten-Marktplätze.

Es sind interne Enterprise-Agenten-Netzwerke.

Große Organisationen haben bereits viele Grenzen:

Teams
Abteilungen
Systeme
Anbieter
Daten-Domänen
Compliance-Zonen
Sicherheitsrichtlinien
Genehmigungsprozesse

A2A passt natürlich auf diese Grenzen, weil das Protokoll um dasselbe grundlegende Bedürfnis herum designed ist: Strukturierte Kommunikation zwischen Systemen, die ihre eigene Eigentümerschaft haben und keine Codebasis teilen. Der breitere KI-Systeme Cluster behandelt, wie Spezialagenten wie Hermes und OpenClaw in dieser Art von geschichteter Architektur in der Praxis passen.

Anstatt einen riesigen Assistenten mit direktem Zugriff auf alles zu bauen, kann ein Enterprise Spezialagenten mit begrenzter Verantwortung bauen:

HR-Agent
Finanz-Agent
Support-Agent
DevOps-Agent
Sicherheits-Agent
Wissensmanagement-Agent
Datenplattform-Agent

Jeder Agent kann seine Tools und Richtlinien intern besitzen. Andere Agenten können über A2A mit ihm interagieren.

Dies ist ein viel besseres Modell als einem einzelnen Allzweck-Agenten direkten Zugriff auf jedes System in der Organisation zu geben, sowohl aus Sicherheits- als auch aus operativer Sicht. Jeder Spezialagent kann unabhängig besessen, betrieben, auditiert und gesichert werden, was das Gesamtsystem auch leichter verständlich macht, wenn etwas schiefgeht.

A2A für kleine Teams und Indie Hacker

Für kleine Teams, die Produkte mit einem oder zwei Agenten bauen, ist A2A genuinely weniger dringend – und oft eine Ablenkung von unmittelbareren Problemen. Sie brauchen wahrscheinlich noch kein Agent-to-Agent-Protokoll.

Verwenden Sie normalen Code. Verwenden Sie HTTP-APIs. Verwenden Sie Queues. Verwenden Sie MCP, wo Tool-Integration wichtig ist.

Fügen Sie A2A hinzu, wenn Sie tatsächlich Folgendes haben:

Mehrere unabhängige Agenten
Dritt-Agenten-Grenzen
Langlaufende delegierte Tasks
Agenten-Discovery-Anforderungen
Artefaktaustausch-Anforderungen
Interoperabilitätsanforderungen über Frameworks hinweg

Die Sequenz ist wichtiger als die Ambition. Beginnen Sie mit der einfachsten Architektur, die die echten Druckpunkte exponiert, und lassen Sie diese Druckpunkte Ihnen sagen, ob Sie tatsächlich A2A brauchen, bevor Sie sich auf die Komplexität einlassen, die es mit sich bringt. Für die meisten kleinen Builder ist MCP zuerst und A2A später der richtige Weg.

Ein praktisches Entscheidungsframework

Verwenden Sie dieses Framework, wenn Sie entscheiden, ob A2A in Ihr System gehört.

Kein A2A, wenn der Workflow lokal ist. Vermeiden Sie A2A, wenn alles innerhalb einer Anwendung läuft und die Komponenten nicht unabhängig bereitstellbar sind. Eine Python-Funktion, Klasse, Service, Queue oder Workflow-Engine reicht wahrscheinlich aus.

MCP, wenn der Agent Tools braucht. Verwenden Sie MCP, wenn Ihr Agent standardisierten Zugriff auf Dateien, Datenbanken, APIs, SaaS-Systeme, Suchindizes, Repositories, interne Dokumentation oder Observability-Systeme benötigt. MCP bietet unmittelbaren praktischen Wert und ist der richtige Startpunkt für die meisten Teams, die heute Agenten bauen.

A2A, wenn der Agent Peers braucht. Verwenden Sie A2A, wenn Ihr Agent mit anderen unabhängigen Agenten kommunizieren muss – insbesondere wenn diese Agenten eigene Fähigkeiten, Richtlinien, Status, Tools, Eigentümer, Bereitstellungslebenszyklus und Sicherheitsgrenzen haben.

Beide, wenn die Architektur Schichten hat. Verwenden Sie beide, wenn Spezialagenten miteinander zusammenarbeiten und jeder Spezialist auch Tools benötigt. Das Produktionsmuster ist A2A zwischen Agenten und MCP zwischen Agenten und Tools. Das ist die sinnvollste Version des 2026er Agenten-Protokoll-Stacks und die Architektur, die am saubersten darauf abbildet, wie Produktions-Multi-Agenten-Systeme tatsächlich gebaut werden.

Häufige Fehler mit A2A

A2A verwenden, weil es strategisch klingt. Das ist der klassische Enterprise-Architektur-Fallen. A2A sollte ein echtes Grenzproblem lösen, das in der Architektur existiert, nicht eines, das erfunden wird, um die Protokollwahl zu rechtfertigen. Wenn es keine echte Grenze gibt – keine unabhängige Bereitstellung, keine separate Eigentümerschaft, keine distincte Sicherheitsperimeter – gibt es wahrscheinlich keinen Bedarf an A2A.

MCP und A2A als Konkurrenten behandeln. MCP ist nicht veraltet, weil A2A existiert, und A2A ist nicht unnötig, weil MCP existiert. Sie adressieren unterschiedliche strukturelle Probleme und funktionieren am besten als ergänzende Schichten, nicht als konkurrierende Alternativen.

Jede Fähigkeit als Agenten exponieren. Ein Taschenrechner braucht keinen Agenten. Eine Wetter-API braucht keinen Agenten. Eine Datenbankabfrage braucht keinen Agenten. Viele Dinge sind straightforward Tools, und die Agenten-Abstraktion fügt Overhead hinzu, ohne Klarheit zu schaffen, wenn sie auf Komponenten angewendet wird, die keine bedeutende Autonomie, keinen Status oder keinen eigenen Lebenszyklus haben.

Einen vollständigen Agenten hinter einem Tool verstecken. Der entgegengesetzte Fehler ist auch häufig. Wenn ein „Tool“ seinen eigenen Task-Lebenszyklus, Speicher, Richtlinien, Artefakte und Delegationsverhalten hat, könnte es verdienen, als Agent modelliert zu werden, anstatt hinter einer Funktionsaufruf-Grenze zusammengedrückt zu werden.

Observability ignorieren. Multi-Agenten-Systeme ohne Traces sind schmerzhaft zu debuggen und unmöglich zu auditieren. Sie müssen wissen, welcher Agent die Aufgabe erhalten hat, welche Nachrichten ausgetauscht wurden, welche Tools aufgerufen wurden, welche Artefakte produziert wurden, welche Richtlinien angewendet wurden und welcher Agent die endgültige Entscheidung getroffen hat. Ohne diese Sichtbarkeit wird Debugging zur Archäologie – das Rekonstruieren dessen, was geschehen ist, durch Inferenz statt durch Beobachtung. Der vollständige Observability-Stack für KI- und LLM-gestützte Systeme, einschließlich Metriken, verteilter Traces und SLOs, die Agenten-Grenzen überschreiten, wird in Observability für LLM-Systeme: Metriken, Traces, Logs und Testing in der Produktion behandelt.

Ist A2A also überbewertet?

Ja, teilweise. A2A ist überbewertet, wenn es als unvermeidlicher Standard für alle KI-Agenten-Systeme dargestellt wird, wenn Leute implizieren, dass jeder Entwickler es sofort adoptieren muss, wenn Agenten-Demos A2A verwenden, um zu koordinieren, was drei Funktionsaufrufe sein könnten, oder wenn die Protokoll-Diskussion Identität, Autorisierung, Observability und Produktionsoperationen ignoriert. Das sind echte Beispiele für Hype, der A2A universeller erscheinen lässt, als es ist.

Aber überbewertet bedeutet nicht nutzlos. Viele wichtige Technologien sind überbewertet, bevor sie zur langweiligen Infrastruktur werden, und der Hype kommt oft lange bevor das Ökosystem reif genug ist, um sie zu unterstützen. Die echte Frage ist nicht, ob das Marketing übertrieben ist – es ist es manchmal klar. Die echte Frage ist, ob die zugrunde liegende Abstraktion nützlich ist, und für A2A ist die Antwort ja, wenn Agenten genuinely unabhängige Akteure in einem System mit echten Grenzen, echter Eigentümerschaft und echten Einsatz werden.

Ist A2A also tot?

Nein.

Das Argument „A2A ist tot“ machte mehr Sinn während der frühen Skepsis-Phase, als das Protokoll wie eine Google-geführte Reaktion auf den MCP-Momentum aussah.

2026 ist dieses Argument schwächer.

A2A hat eine formelle Spezifikation, Ökosystem-Unterstützung, Linux Foundation-Momentum, große Cloud-Aufmerksamkeit und berichtete Produktionsbereitstellungen.

Keines davon macht A2A dominant, obligatorisch oder universell von der Entwickler-Community geliebt – aber es ist klar nicht tot. Eine bessere Aussage ist, dass A2A am Leben ist und seinen Produktionswert jenseits von Enterprise- und Plattform-Ökosystemen beweist, wo die meisten bestätigten Bereitstellungen derzeit leben.

Ist A2A 2026 endlich nützlich?

Ja, aber nur in der richtigen Architektur. A2A ist nützlich, wenn Ihr System echte Agenten-Grenzen hat – nicht nur, weil Ihr Code mehrere Prompts hat, oder weil Ihr System das Wort „Agent“ in Variablennamen verwendet. Es wird nützlich, wenn Agenten-Zusammenarbeit genuinely standardisierte Struktur benötigt:

Discovery
Fähigkeiten
Task-Lebenszyklus
Nachrichten
Artefakte
Langlaufende Arbeiten
Undurchsichtige Implementierungsgrenzen
Cross-Vendor-Interoperabilität

Dort verdient A2A seinen Platz, indem es einen gemeinsamen Vertrag für Zusammenarbeit bereitstellt, der andernfalls Custom-Protokoll-Arbeit an jeder Grenze erfordern würde.

Meine Meinung

A2A ist nicht das Protokoll, mit dem die meisten Entwickler beginnen sollten – MCP ist es. MCP löst ein unmittelbareres und breiter anwendbares Problem: Agenten mit nützlichen Tools und Kontext zu verbinden. A2A löst ein Problem einer späteren Stufe: Unabhängige Agenten miteinander über echte Bereitstellungs- und Eigentümerschaftsgrenzen hinweg zu verbinden. Das macht MCP heute nützlicher für die überwiegende Mehrheit der einzelnen Entwickler und kleinen Teams.

A2A kann wichtiger werden, wenn Agenten-Systeme von Demos zu Enterprise-Workflows reifen. Sobald Organisationen mehrere Spezialagenten haben, die von verschiedenen Teams besitzen werden, wird der Bedarf an einer standardisierten Agent-to-Agent-Grenze offensichtlich, und der Overhead des Protokolls beginnt, sich auszuzahlen.

Meine praktische Empfehlung ist, mit MCP zu beginnen, saubere Agenten-Grenzen von Anfang an zu designen und A2A nur hinzuzufügen, wenn diese Grenzen zu echten Bereitstellungs-, Eigentümerschafts- oder Interoperabilitätsbeschränkungen werden. Adoptieren Sie A2A nicht wegen des Vibes. Adoptieren Sie es, wenn die Architektur es verlangt.

Fazit

Googles A2A-Protokoll ist nicht tot.

Es ist auch nicht die universelle Zukunft jedes KI-Agenten-Projekts.

Es ist ein nützliches, noch reifendes Protokoll für ein spezifisches Problem: Kommunikation zwischen unabhängigen KI-Agenten.

Wenn Sie einen einfachen Assistenten bauen, ist A2A wahrscheinlich unnötig.

Wenn Sie ein Multi-Agenten-Enterprise-System, einen Agenten-Marktplatz, ein vendor-neutrales Agenten-Netzwerk oder eine Reihe unabhängig bereitgestellter Spezialagenten bauen, verdient A2A ernsthafte Aufmerksamkeit.

Das beste 2026er Framing ist nicht:

A2A vs. MCP

Es ist:

MCP für Tools.
A2A für Agenten.
Beide für ernsthafte Multi-Agenten-Systeme.

Das ist weniger dramatisch als ein Protokoll-Krieg-Narrativ, aber es ist auch genauer und nützlicher für Ingenieure, die echte Architekturentscheidungen treffen müssen.