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

A2A ist nicht tot. Es ist einfach nicht universell.

Inhaltsverzeichnis

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

Als Google A2A im April 2025 bekanntgab, war die Botschaft klar: KI-Agenten, die von verschiedenen Anbietern, Frameworks und Teams entwickelt wurden, benötigten einen standardisierten Weg der Kommunikation. Das Protokoll versprach Agenten-Entdeckung, Aufgabenübertragung, Nachrichtenaustausch, Streaming-Updates und das Teilen von Artefakten. Die Reaktion war jedoch weit weniger eindeutig als die Ankündigung.

Einige Entwickler sahen in A2A die fehlende Schicht für die Kommunikation zwischen Agenten im aufstrebenden agentic Stack. Andere sahen darin lediglich ein weiteres Google-Protokoll, einen weiteren 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 bereits MCP. Warum brauchen wir A2A?“ Das war 2025 eine berechtigte Frage und bleibt es auch 2026 – obwohl sich die Antwort erheblich gewandelt hat.

Zwei KI-Agentensysteme, verbunden durch die A2A-Protokoll-Brücke

A2A ist nicht tot, aber es ist auch nicht universell nützlich. Die praktische Realität ist, dass A2A in einem spezifischen Kontext zunehmend echten Wert bietet: dort, wo Agenten unabhängige Systeme mit eigener Eigentümerschaft, Tools und Vertrauensgrenzen sind, anstatt nur interne Funktionen oder Tool-Wrapper. Diese Unterscheidung zwischen Tool-Integration und Agenten-Delegation ist genau das, was das Protokoll zu adressieren versucht, und ihr Verständnis 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 ist ein offener Standard für die Kommunikation und Interoperabilität zwischen unabhängigen KI-Agentensystemen – insbesondere für Agenten, die mit unterschiedlichen Frameworks, Sprachen oder Vendor-Stacks entwickelt wurden.

A2A beschäftigt sich nicht primär damit, 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 beschäftigt sich mit etwas anderem: Ein Agent kommuniziert mit einem anderen Agenten und behandelt das Peersystem als Akteur mit eigenen Fähigkeiten, anstatt als passive Datenquelle.

Ein typischer A2A-Workflow könnte Folgendes umfassen:

Entdeckung eines Agenten über eine Agent Card
Lesen der Fähigkeiten und Kompetenzen des Agenten
Senden einer Aufgabe
Austausch von Nachrichten
Empfang von Statusupdates
Handhabung von Zuständen, die Eingaben erfordern
Empfang finaler Artefakte
Nachverfolgung 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 darauf ausgelegt ist, den gesamten Bogen von der Entdeckung und Delegation über die Ausführung und Statusupdates bis hin zur Rückgabe von Artefakten zu bewältigen. Für eine detaillierte technische Einführung in jedes Konzept – Agent Cards, Aufgaben-Lebenszyklus, Nachrichten, Teile und Artefakte – siehe Was ist das A2A-Protokoll? Agent Cards und Aufgaben erklärt. Für Informationen dazu, wie Streaming, Push-Benachrichtigungen und Human-in-the-Loop-Pausen in der Produktion funktionieren, siehe A2A Streaming und asynchrone Aufgaben für langlaufende Agenten-Workflows.

Warum A2A leicht zu verspotten war

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

Bis 2025 hatten Entwickler es bereits mit Folgendem zu tun:

LLM-APIs
Function Calling
Tool Calling
Agenten-Frameworks
MCP-Server
RAG-Pipelines
Workflow-Engines
Multi-Agent-Orchestrierungsbibliotheken
Custom JSON-Protokolle
Interne Plug-in-Systeme

Als Google also A2A bekanntgab, war eine häufige Reaktion vorhersehbar:

„Brauchen wir wirklich noch einen Standard?“

Die Skepsis 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 bezüglich des langfristigen Engagements skeptisch machte. 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 „Interoperabilität zwischen Agenten“ ambitioniert, aber auch etwas vorweggenommen.

Und um es direkt zu sagen: Viele KI-Agenten-Demos im Jahr 2025 brauchten A2A überhaupt nicht.

Sie brauchten bessere Prompts, bessere Tools, bessere Berechtigungen, bessere Wiederholungslogik und bessere Logs.

Das Update 2026: A2A ist nicht tot

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

Im April 2026 berichtete die Linux Foundation, dass das A2A-Projekt 150 unterstützende Organisationen überschritten hatte, wichtige Integrationen in Cloud-Plattformen erzielt und produktive Bereitstellungen in mehreren Branchen erreicht hatte.

Das bedeutet nicht, dass jeder Anspruch ohne Skepsis geschluckt werden sollte. „Unterstützt von“ ist nicht dasselbe wie „tiefgreifend in der Produktion von den meisten Entwicklern verwendet“. Protokoll-Ökosysteme wirken in Pressemitteilungen oft größer, als sie sich im täglichen Engineerings-Alltag anfühlen.

Das Signal ist jedoch bedeutsam, weil es schwerer zu ignorieren 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 Etikett „tot“ aus technischer oder Adoptionssicht schwer zu verteidigen.

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

A2A vs MCP: Die Verwirrung, die nicht sterben wollte

Der größte Teil der A2A-Verwirrung stammt aus seiner Beziehung zu MCP.

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

Vereinfacht ausgedrückt:

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

Das klingt klar, aber die reale Welt ist considerably unübersichtlicher. Ein MCP-Server kann etwas aussetzen, das sehr agentenhaft aussieht – beispielsweise ein MCP-Tool namens research_company, das intern Suche, Retrieval, Zusammenfassung, Ranking und Berichtsschreibung ausführt. Aus Sicht des MCP-Hosts ist es ein Tool. Aus Architektursicht verbirgt es einen agentenähnlichen 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 Struktur für Dinge bietet, die MCP eher umständlich behandelt:

Agenten-Entdeckung
Agenten-Fähigkeiten
Aufgaben-Lebenszyklus
Langlaufende Arbeit
Mehrstufiger Aufgabenstatus
Nachrichten zwischen Agenten
Artefakte
Zusammenarbeit zwischen undurchsichtigen Agenten
Delegation über Organisationsgrenzen hinweg

MCP kann viel verpacken, aber alles als Tool zu verpacken wird irgendwann zu einer schlechten 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 die Behandlung eines Peer-Agenten als Peer-Agent – statt als Funktionsaufruf – beginnt, sich auszuzahlen. 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 klarste Architektur ist nicht „A2A vs MCP“.

Die klarste 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 Schicht für die Agenten-Zusammenarbeit.
MCP ist die Schicht für die Tool-Integration.

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. Die Framing der „Protokoll-Krieg“-Debatte ist meist faule Analyse, die gute Schlagzeilen liefert, Ingenieuren aber nichts hilft, bessere Systeme zu entwerfen.

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 besessen werden
Mit unterschiedlichen Frameworks gebaut wurden
Von Anbietern ausgesetzt werden
Mit ihren eigenen Tools und Berechtigungen laufen
Für langlaufende Aufgaben verantwortlich sind
Artefakte anstatt einfacher Werte zurückgeben
Teil eines breiteren Multi-Agent-Workflows sind

Stellen Sie sich beispielsweise 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, eigene 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-Speicher, 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 eine horizontale Übergabe zwischen autonomen Agenten ist, jeder mit seiner eigenen Grenze der Autorität und Rechenschaftspflicht. 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 obligatorische Infrastruktur für jedes KI-Projekt dargestellt wird.

Die meisten Projekte benötigen es nicht.

Wenn Sie einen lokalen Coding-Assistenten, einen Chatbot für Ihre Dokumentation, einen kleinen internen Automatisierungs-Agenten 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
Evaluierung
Logging
Kostenkontrolle
Wiederholungslogik
Bessere Prompts
Besseres Retrieval

Sie benötigen wahrscheinlich kein volles Agent-zu-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 Entdeckung benötigen
Agenten keinen unabhängigen Aufgabenstatus benötigen
Es keine externen Agenten-Anbieter gibt
Eine API oder eine Warteschlange 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 operativen Aufwand hinzu.

In vielen kleinen Systemen ist die Adoption von A2A Architektur-Cosplay – die Vokabular von verteilten Agentensystemen zu leihen, ohne die tatsächlichen Grenzprobleme, die das Protokoll wertvoll machen.

A2A und das Google-Problem

Ein Teil der A2A-Skepsis stammt von Google selbst.

Entwickler haben lange Erinnerungen. 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 entirely gerecht, aber es ist ein echter Adoptionsfaktor.

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

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

In 2026 sollte A2A weniger als „Googles Protokoll“ und mehr als ein aufstrebender Standard für Agenten-Interoperabilität bewertet werden, den Google half zu starten.

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

Adoption: Starkes Signal, aber nicht die ganze Geschichte

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

Am schwächsten Ende ist 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 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 der Folienpräsentation in die funktionierende Implementierung gewechselt ist, und echte Ingenieure es für ihre Zeit wert fanden. Noch stärker ist die Plattform-Adoption, wo Clouds, Agenten-Frameworks und Enterprise-Systeme echte native Unterstützung aussetzen, was A2A zu einer plausiblen Standard-Architekturauswahl macht, anstatt etwas, das Teams selbst zusammenbauen müssen.

Die einzige Adoptionsebene, die wirklich für die langfristige Gesundheit des Ökosystems zählt, ist die Produktionsretention. Für einen Eindruck davon, wie echte Adoptionskurven im KI-Agenten-Bereich aussehen – gemessen in GitHub-Stars, OpenRouter-Token und Download-Trends – zeigt die OpenClaw vs Hermes Agent-Popularitätsdaten wie schnell sich Momentum aufbaut und plateauet, sobald die Energie der Early Adopters nachlässt.: Teams, die das Protokoll für Live-Workflows jenseits der ersten 90-tägigen Honigmond-Phase nutzen. Das Update der Linux Foundation 2026 behauptet Produktionsnutzung in mehreren Branchen, was ein bedeutender Beweis ist. Aber die nützlichere Frage ist nicht „wer unterstützt A2A?“ – sie ist „wer behält A2A in der Produktion nach dem ersten echten operativen Vorfall?“ Langfristige Retention unter Druck ist das Signal, das echte Infrastruktur von Protokoll-Theater trennt.

Der echte Test: Retention in der Produktion

Entwickler-Hype ist billig, und Produktionsretention ist teuer. Die beiden stehen selten im Verhältnis, weshalb die 90-Tage-Retention-Frage 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 Aufgaben-Lebenszyklus
Streaming-Ausfälle
Versionskompatibilität
Anbieterunterschiede
Kostenüberraschungen
Sicherheitsüberprüfungen
Audit-Anforderungen
Human-Approval-Workflows

Hier scheitern viele Agenten-Frameworks und Protokolle. Sie sehen elegant in Diagrammen aus, werden 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 Unternehmen es für echte Multi-Agenten-Grenzen zu nutzen beginnen.

Das schlimmste Zeichen wäre, wenn Entwickler es nur in Demos nutzen, während Produktionssysteme auf benutzerdefinierte APIs und Warteschlangen 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 Organisations- 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 passiert 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 Orte, 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 Rechenschaftspflicht unklar machen.
Sensible Daten könnten über Grenzen hinweg fließen, ohne ordnungsgemäßes Logging.

Das ist der Grund, warum ernsthafte A2A-Systeme mehr als nur Protokollkonformität benötigen.

Sie benötigen:

Starke Agenten-Identität
Scope-basierte Autorisierung
Audit-Logs auf Aufgabenebene
Delegations-Tracking
Human-Approval 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 MCP Agenten-Sicherheit: Identität, Delegation und Audit-Trails legt diese umgebende Architektur im Detail dar.

A2A und die Idee des Agenten-Marktplatzes

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

Wenn Agenten Fähigkeiten durch Agent Cards werben können, können andere Agenten oder Plattformen sie entdecken, evaluieren und Aufgaben 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 aussetzen.

Das klingt aufregend, aber es ist auch der Ort, an dem Hype gefährlich wird.

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

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

A2A ist ein nützlicher Baustein für eine solche Zukunft, aber es ist nur ein Teil eines viel größeren Puzzles, das auch Identitätssysteme, Reputationsmechanismen, Abrechnungsinfrastruktur, Compliance-Kontrollen und Streitbeilegung benötigt, bevor es ein sicherer Markt zum Betrieb wird.

A2A für interne Enterprise-Agenten

Der realistischerere 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 entworfen ist: Strukturierte Kommunikation zwischen Systemen, die ihre eigene Eigentümerschaft haben und keinen Codebase teilen. Der breitere KI-Systeme Cluster behandelt, wie Spezialagenten wie Hermes und OpenClaw in dieser Art von geschichteter Architektur in der Praxis passen.

Statt 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 mit ihm über A2A interagieren.

Dies ist ein viel besseres Modell, als einem einzigen 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 einfacher zu verstehen macht, wenn etwas schiefgeht.

A2A für kleine Teams und Indie Hacker

Für kleine Teams, die Produkte mit ein oder zwei Agenten bauen, ist A2A genuinely weniger dringend – und oft eine Ablenkung von dringenderen Problemen. Sie benötigen wahrscheinlich noch kein Agent-zu-Agent-Protokoll.

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

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

Multiple unabhängige Agenten
Drittanbieter-Agenten-Grenzen
Langlaufende delegierte Aufgaben
Anforderungen an die Agenten-Entdeckung
Anforderungen an den Artefakt-Austausch
Bedürfnisse an Framework-übergreifender Interoperabilität

Die Sequenz ist wichtiger als die Ambition. Beginnen Sie mit der einfachsten Architektur, die die echten Druckpunkte offenlegt, und lassen Sie diese Druckpunkte Ihnen sagen, ob Sie A2A tatsächlich benötigen, bevor Sie sich für die Komplexität entscheiden, 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 bereitgestellt werden. Eine Python-Funktion, Klasse, ein Service, eine Warteschlange oder ein Workflow-Engine sind wahrscheinlich ausreichend.

MCP, wenn der Agent Tools benötigt. 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 sofortigen praktischen Wert und ist der richtige Startpunkt für die meisten Teams, die heute Agenten bauen.

A2A, wenn der Agent Peers benötigt. Verwenden Sie A2A, wenn Ihr Agent mit anderen unabhängigen Agenten kommunizieren muss – insbesondere wenn diese Agenten eigene Fähigkeiten, Richtlinien, Status, Tools, Besitzer, Bereitstellungs-Lebenszyklus 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 Agenten-Protokoll-Stacks 2026 und die Architektur, die am saubersten auf abbildet, wie produktionsreife 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 wurde, 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 obsolet, weil A2A existiert, und A2A ist nicht unnötig, weil MCP existiert. Sie adressieren unterschiedliche Strukturprobleme und funktionieren am besten als ergänzende Schichten, nicht als konkurrierende Alternativen.

Jede Fähigkeit als Agenten aussetzen. Ein Taschenrechner muss kein Agent sein. Eine Wetter-API muss kein Agent sein. Eine Datenbankabfrage muss kein Agent sein. 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 sinnvolle Autonomie, keinen Status oder keinen eigenen Lebenszyklus haben.

Einen vollständigen Agenten hinter einem Tool verstecken. Der umgekehrte Fehler ist auch häufig. Wenn ein „Tool“ seinen eigenen Aufgaben-Lebenszyklus, Speicher, Richtlinien, Artefakte und Delegationsverhalten hat, verdient es vielleicht, als Agent modelliert zu werden, anstatt hinter einer Funktionsaufruf-Grenze eingezwängt zu werden.

Observability ignorieren. Multi-Agenten-Systeme ohne Traces sind schmerzhaft zu debuggen und unmöglich zu auditen. 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 zu Archäologie – das Rekonstruieren dessen, was passiert 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 unvermeidliches 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 hätten sein können, 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 langweilige Infrastruktur werden, und der Hype kommt oft lange bevor das Ökosystem reif genug ist, um es 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 MCP-Momentum aussah.

In 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 von der Entwickler-Community universell geliebt – aber es ist klar nicht tot. Eine bessere Aussage ist, dass A2A am Leben ist und weiterhin seinen Produktionswert jenseits von Enterprise- und Plattform-Ökosystemen beweist, wo die meisten bestätigten Bereitstellungen derzeit leben.

Ist A2A also endlich nützlich in 2026?

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

Entdeckung
Fähigkeiten
Aufgaben-Lebenszyklus
Nachrichten
Artefakte
Langlaufende Arbeit
Undurchsichtige Implementierungsgrenzen
Anbieter-übergreifende Interoperabilität

Das ist der Ort, an dem A2A seinen Platz verdient, indem es einen gemeinsamen Vertrag für Zusammenarbeit bietet, der sonst benutzerdefinierte Protokollarbeit an jeder Grenze erfordern würde.

Meine opinionierte Meinung

A2A ist nicht das Protokoll, mit dem die meisten Entwickler beginnen sollten – MCP ist. MCP löst ein dringenderes und breiter anwendbares Problem: Das Verbinden von Agenten mit nützlichen Tools und Kontext. A2A löst ein Problem einer späteren Stufe: Das Verbinden unabhängiger Agenten miteinander über echte Bereitstellungs- und Eigentümerschafts-Grenzen hinweg. 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 multiple Spezialagenten haben, die von verschiedenen Teams besessen werden, wird der Bedarf an einer standardisierten Agent-zu-Agent-Grenze offensichtlich und der Overhead des Protokolls beginnt, sich zu auszahlen.

Meine praktische Empfehlung ist, mit MCP zu beginnen, saubere Agenten-Grenzen von Anfang an zu gestalten und A2A nur hinzuzufügen, wenn diese Grenzen zu echten Bereitstellungs-, Eigentümerschafts- oder Interoperabilitäts-Einschränkungen werden. Adoptieren Sie A2A nicht wegen des Vibe. 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 anbieterneutrales Agenten-Netzwerk oder eine Reihe von unabhängig bereitgestellten Spezialagenten bauen, verdient A2A ernsthafte Aufmerksamkeit.

Das beste Framing 2026 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 eine Protokoll-Krieg-Narrative, aber es ist auch genauer und nützlicher für Ingenieure, die echte architektonische Entscheidungen treffen müssen.