A2A-Protokoll: Wie KI-Agenten untereinander kommunizieren lernen

Stell dir vor, du hast einen KI-Agenten für deine Buchhaltung, einen für dein E-Mail-Marketing und einen dritten für deinen Kundensupport. Alle drei sind brilliant in dem, was sie tun. Aber sie können nicht miteinander reden. Dein Buchhaltungs-Agent weiß nicht, dass der Support-Agent gerade einem Kunden eine Gutschrift versprochen hat. Dein Marketing-Agent schickt fröhlich Newsletter an Kunden, die sich gerade beschwert haben.

Das ist der Zustand, in dem sich die KI-Agent-Landschaft bis vor Kurzem befand: brillante Einzelkämpfer, die in ihren eigenen Silos gefangen waren. Google hat mit dem A2A-Protokoll (Agent-to-Agent) einen offenen Standard geschaffen, der genau dieses Problem löst — und es könnte die wichtigste Infrastruktur-Entscheidung der nächsten Jahre werden.

Das Problem: Die Ära der Isolation

Wer schon einmal Multi-Agent-Systeme in der Praxis gebaut hat, kennt das Dilemma. Jeder Agent lebt in seinem eigenen Framework. LangChain-Agenten sprechen LangChain, Vertex-AI-Agenten sprechen Vertex, und dein selbstgebauter Agent spricht — naja, was auch immer du dir ausgedacht hast.

Die bisherige Lösung? Custom-Integrationen. Für jeden Agent-zu-Agent-Kanal schreibst du eigenen Code. Bei zwei Agenten ist das noch machbar. Bei fünf wird es unübersichtlich. Bei zwanzig ist es ein Albtraum, den kein Entwickler freiwillig pflegen will.

Das erinnert an die Frühzeit des Internets, als jedes Netzwerk sein eigenes Protokoll hatte. Erst TCP/IP hat das Web möglich gemacht — nicht weil es technisch revolutionär war, sondern weil sich alle darauf geeinigt haben. A2A will genau das für KI-Agenten sein.

Was ist das A2A-Protokoll?

A2A steht für Agent-to-Agent und ist ein offener, herstellerneutraler Standard, der von Google initiiert und an die Linux Foundation übergeben wurde. Das Protokoll definiert, wie KI-Agenten sich gegenseitig finden, ihre Fähigkeiten beschreiben und Aufgaben austauschen können — unabhängig davon, auf welchem Framework oder bei welchem Anbieter sie laufen.

Die Kernidee ist radikal einfach: Jeder Agent veröffentlicht eine Agent Card — eine standardisierte JSON-Datei unter /.well-known/agent-card.json, die beschreibt, was der Agent kann, welche Eingaben er akzeptiert und welche Ausgaben er liefert. Denk an eine Art digitale Visitenkarte, aber maschinenlesbar.

Ein orchestrierender Agent kann diese Cards entdecken, die Fähigkeiten auswerten und Teilaufgaben an den passenden Spezialisten routen. Alles über HTTP, alles standardisiert, keine proprietären Schnittstellen.

Die Architektur im Detail

A2A basiert auf einigen wenigen, aber durchdachten Konzepten:

Agent Cards sind das Herzstück. Sie enthalten den Namen des Agenten, eine Beschreibung, verfügbare Skills, unterstützte Input/Output-Formate und die URL, unter der der Agent erreichbar ist. Das Format ist JSON, gehostet unter einer Well-Known-URL — ein bewährtes Muster aus der Webentwicklung.

Discovery funktioniert über einen Matching-Mechanismus, der Language Models nutzt, um die Fähigkeiten eines Agenten anhand seiner Card zu bewerten. Statt eine hardcodierte Liste zu pflegen, fragt ein Client-Agent quasi: „Wer da draußen kann mir bei dieser Aufgabe helfen?” und bekommt dynamisch passende Agenten vorgeschlagen.

Task Lifecycle Management ist besonders für Enterprise-Szenarien relevant. Jede Aufgabe durchläuft definierte Zustände: queued, running, input-required, auth-required, completed, failed. Das ermöglicht lang laufende Prozesse, bei denen ein Agent stunden- oder tagelang an einer Aufgabe arbeiten kann, während der aufrufende Agent über Webhooks über Statusänderungen informiert wird.

Human-in-the-Loop ist eingebaut. Wenn ein Agent eine Entscheidung nicht selbst treffen kann oder darf, kann er über den input-required-Status eine menschliche Freigabe anfordern. Das ist kein Workaround, sondern ein First-Class-Konzept im Protokoll — und für regulierte Branchen absolut entscheidend.

A2A vs. MCP: Zwei Protokolle, ein Ökosystem

Wer meinen Artikel über das Model Context Protocol (MCP) gelesen hat, fragt sich jetzt vielleicht: Brauchen wir wirklich noch ein Protokoll? Die Antwort ist ein klares Ja, denn A2A und MCP lösen unterschiedliche Probleme.

MCP (von Anthropic) standardisiert, wie ein Agent mit Tools und Datenquellen interagiert. Es ist die Schnittstelle zwischen Agent und Welt: Dateisystem lesen, API aufrufen, Datenbank abfragen. MCP ist vertikal — es geht in die Tiefe.

A2A standardisiert, wie Agenten untereinander kommunizieren. Es ist die Schnittstelle zwischen Agent und Agent: Aufgaben delegieren, Ergebnisse austauschen, Fähigkeiten entdecken. A2A ist horizontal — es geht in die Breite.

In einem ausgereiften Multi-Agent-System brauchst du beides. Ein Booking-Agent nutzt A2A, um einen Flugsuche-Agenten zu beauftragen. Der Flugsuche-Agent nutzt MCP, um eine Flug-API anzubinden. Der Booking-Agent ruft dann per A2A einen Payment-Agenten auf, der wiederum per MCP die Zahlungsschnittstelle bedient.

Aspekt	MCP	A2A
Fokus	Agent ↔ Tools/Daten	Agent ↔ Agent
Initiator	Anthropic	Google
Kommunikation	Vertikal (Tiefe)	Horizontal (Breite)
Governance	Open Source	Linux Foundation
Anwendung	Tool-Integration	Cross-Vendor-Orchestrierung

Die beiden Protokolle sind nicht konkurrierend, sondern komplementär. Und das ist kein Marketing-Sprech — die Linux Foundation hat beide unter dem Dach der Agentic AI Foundation (AAIF) zusammengebracht.

Praxis-Beispiel: Agent-Orchestrierung mit A2A

Wie sieht das konkret aus? Nehmen wir ein realistisches Szenario aus meinem Arbeitsalltag als Webentwickler. Ich will ein automatisiertes System für Client-Onboarding bauen:

Schritt 1: Der Intake-Agent nimmt eine neue Kundenanfrage entgegen (per Mail, Formular oder Chat). Er extrahiert die relevanten Informationen: Name, Projekttyp, Budget, Zeitrahmen.

Schritt 2: Per A2A Discovery findet er den Projekt-Analyse-Agenten, dessen Agent Card Skills wie „Aufwandsschätzung”, „Technologie-Stack-Empfehlung” und „Ressourcenplanung” ausweist. Der Intake-Agent delegiert die Analyse als Task.

Schritt 3: Der Projekt-Analyse-Agent nutzt MCP-Tools, um ähnliche vergangene Projekte zu durchsuchen, aktuelle Auslastung zu prüfen und eine Schätzung zu erstellen. Er gibt das Ergebnis per A2A zurück.

Schritt 4: Der Intake-Agent leitet das Ergebnis an einen Angebots-Agenten weiter, der automatisch ein PDF-Angebot erstellt und es in den input-required-Status setzt — weil ein Mensch das Angebot vor dem Versand freigeben muss.

Das alles passiert automatisiert, aber mit klaren menschlichen Kontrollpunkten. Und das Beste: Jeder dieser Agenten kann von einem anderen Anbieter stammen, in einem anderen Framework gebaut sein und unabhängig weiterentwickelt werden.

Die Timeline: Von der Idee zum Standard

Die Entwicklung von A2A ging bemerkenswert schnell — ein Zeichen dafür, wie dringend die Branche diesen Standard brauchte:

• April 2025: Google veröffentlicht A2A mit über 50 Partnern, darunter Salesforce, SAP, ServiceNow, LangChain und PayPal.
• Juli 2025: Version 0.3 bringt gRPC-Support und signierte Security Cards.
• August 2025: IBMs Agent Communication Protocol (ACP) wird in A2A gemergt — ein klares Signal, dass die Branche sich auf einen Standard einigt statt Fragmentierung zu riskieren.
• Dezember 2025: Übergabe an die Linux Foundation und Gründung der Agentic AI Foundation mit über 100 Unterstützern.
• März 2026: A2A und MCP koexistieren als die zwei zentralen Standards für Agent-Ökosysteme.

Die Geschwindigkeit, mit der IBM sein eigenes Protokoll aufgegeben und A2A adoptiert hat, ist das vielleicht stärkste Signal. In der Tech-Welt passiert so etwas nur, wenn der Bedarf überwältigend ist.

Was bedeutet das für Entwickler?

Wenn du heute KI-Agenten baust oder planst, gibt es ein paar konkrete Takeaways:

1. Agent Cards jetzt schon einplanen

Auch wenn du noch kein vollständiges A2A-Setup brauchst — gewöhne dir an, die Fähigkeiten deiner Agenten strukturiert zu beschreiben. Eine Agent Card ist im Grunde eine maschinenlesbare API-Dokumentation. Das zwingt dich, sauber über die Schnittstellen deiner Agenten nachzudenken.

2. Monolithische Agenten aufbrechen

Der größte Fehler, den ich bei Agent-Projekten sehe: Ein Mega-Agent, der alles kann. A2A incentiviert spezialisierte Agenten mit klaren Zuständigkeiten. Ein Agent, der „alles ein bisschen” kann, hat eine schlechte Agent Card. Ein Agent, der „E-Commerce-Retouren für DACH-Region bearbeitet”, hat eine exzellente.

3. Function Calling bleibt relevant

A2A ersetzt nicht die Tool-Integration auf Agent-Ebene. Wenn dein Agent intern Tools über Function Calling oder MCP anbindet, ist das weiterhin der richtige Ansatz. A2A kommt obendrauf — für die Kommunikation zwischen Agenten.

4. Security von Anfang an mitdenken

A2A bringt signierte Security Cards und Authentifizierungsmechanismen mit. Wer schon bei der Sicherheit von KI-Agenten sauber aufgestellt ist, hat hier einen Vorsprung. In Enterprise-Szenarien mit Cross-Organisation-Kommunikation wird das Thema noch kritischer.

Die größere Perspektive: Warum das wichtig ist

A2A ist mehr als ein technisches Protokoll. Es ist ein Infrastruktur-Shift, der verändert, wie wir über KI-Systeme nachdenken. Bisher waren KI-Agenten im Wesentlichen bessere Chatbots mit Tool-Zugang. Mit A2A werden sie zu Teilnehmern in einem Netzwerk — vergleichbar mit Microservices, aber mit eigenem Urteilsvermögen.

Das hat Implikationen, die über die reine Technik hinausgehen. Wenn Agenten verschiedener Unternehmen standardisiert miteinander kommunizieren können, entsteht eine neue Art von B2B-Integration. Statt API-Verträge auszuhandeln und Custom-Integrationen zu bauen, lässt du deine Agenten einfach miteinander reden. Dein Logistik-Agent findet den Versand-Agenten deines Partners über dessen Agent Card und delegiert die Lieferung direkt.

Wer bereits über die Koordinationsschicht für KI-Agenten nachgedacht hat, erkennt das Muster: Wir bewegen uns von manueller Orchestrierung zu selbstorganisierenden Agent-Netzwerken. A2A liefert dafür die technische Grundlage.

Und für den E-Commerce-Bereich wird das besonders spannend. Stell dir Agenten vor, die über Unternehmensgrenzen hinweg Bestellungen, Retouren und Kundenkommunikation koordinieren — standardisiert, auditierbar, skalierbar.

Mein Fazit

A2A ist eines dieser Protokolle, die im Rückblick offensichtlich erscheinen werden. Natürlich brauchen KI-Agenten eine standardisierte Art, miteinander zu reden. Natürlich muss das herstellerneutral und offen sein. Natürlich gehört das unter das Dach einer neutralen Foundation.

Aber „offensichtlich im Rückblick” ist nicht dasselbe wie „offensichtlich im Moment”. Gerade jetzt, wo die meisten Entwickler noch damit beschäftigt sind, einzelne Agenten zum Laufen zu bringen, fühlt sich Agent-zu-Agent-Kommunikation wie ein Luxusproblem an. Das ist es nicht. Es ist die Infrastruktur, auf der die nächste Generation von KI-Anwendungen aufbauen wird.

Mein Rat: Beschäftige dich jetzt mit A2A und MCP. Nicht weil du beides morgen brauchst, sondern weil die Architektur-Entscheidungen, die du heute triffst, darüber bestimmen, wie leicht deine Agenten morgen miteinander sprechen können. Wer Agent Cards und standardisierte Schnittstellen von Anfang an einplant, spart sich später das große Refactoring.

Die Zukunft gehört nicht dem besten einzelnen Agenten. Sie gehört dem besten Agent-Netzwerk.