05.01.2026 AI Engineering5 Minuten Lesezeit

A2A auf dem Weg zur 1.0: Was Sie jetzt bauen sollten

A2A nähert sich seinem ersten produktionsreifen Release. Wir verfolgen den Weg von Googles Ankündigung im April 2025 bis zum v1.0 Release Candidate und trennen stabile Konzepte von beweglichen Wire-Formaten. Daraus leiten wir ab, was Sie heute auf v0.3.0 bauen und vor 1.0 bewusst kapseln sollten.

Agenten ohne gemeinsame Sprache

Jedes Agenten-Framework des Jahres 2025 bringt eine eigene Schnittstelle mit. LangGraph, CrewAI, Semantic Kernel und Googles ADK exponieren Agenten jeweils anders. Schon zwei Frameworks brauchen einen Adapter; bei n Frameworks wächst die Zahl auf n×(n−1). Das Model Context Protocol standardisiert zwar, wie ein Modell Werkzeuge aufruft, nicht aber, wie ein autonomer Agent einen anderen findet, authentifiziert und mit Arbeit beauftragt — über Prozess-, Hersteller- und Organisationsgrenzen hinweg.

Das Agent2Agent-Protokoll (A2A) setzt genau an dieser Schicht an. Agenten bleiben füreinander opak: Sie tauschen Nachrichten und Tasks aus, nicht internen Zustand, Gedächtnis oder Prompts. A2A definiert Discovery, Authentifizierungsschemata, Task-Delegation und Streaming. Wie ein Agent schlussfolgert, wie die Arbeit orchestriert wird und ob das Ergebnis korrekt ist, bleibt dagegen offen. Das sind weiterhin Engineering-Probleme auf beiden Seiten der Verbindung.

Ein Agent erreicht seine Tools über MCP — eine Standard-Schnittstelle. 1/4

Vom Google-Projekt zum Linux-Foundation-Standard

Google hat A2A am 9. April 2025 mit mehr als 50 Technologiepartnern angekündigt. Am 23. Juni 2025 wurde das Projekt auf dem Open Source Summit in Denver an die Linux Foundation übergeben. Zu den Gründungsmitgliedern zählen AWS, Cisco, Microsoft, Salesforce, SAP und ServiceNow; ein Technical Steering Committee steuert seitdem die Spezifikation. Herstellerneutralität war Voraussetzung für Enterprise-Adoption; sie ist jetzt organisatorisch abgesichert.

Der aktuelle Release ist v0.3.0 vom 30. Juli 2025; offizielle SDKs gibt es für Python, JavaScript, Java, Go und .NET. Seit November arbeitet das Projekt auf v1.0 zu, den ersten von den Maintainern als produktionsreif bezeichneten Release. Damit wird die praktische Frage konkret: Welche Konzepte sind bereits tragfähig, welche Formate werden brechen, und worauf können Sie heute bauen?

Signierte Agent Cards für verifizierbare Identität

Eine Agent Card ist ein JSON-Manifest unter /.well-known/agent-card.json. Sie deklariert Name, Skills, unterstützte Transporte und Sicherheitsanforderungen eines Agenten. Mit v0.3.0 wurde Identität verifizierbar: Die Card trägt ein signatures-Array mit JSON Web Signatures nach RFC 7515, und Mutual TLS wurde in die Security-Schemata aufgenommen. Ein Client kann vor der ersten Anfrage prüfen, dass eine Card von einem bestimmten Schlüsselinhaber publiziert wurde.

Die Signatur belegt die Herkunft der Metadaten. Sie belegt nicht, dass sich der Agent wie beworben verhält, und sie löst weder Schlüsselverteilung noch Revocation. Welche Signierer Sie akzeptieren, bleibt eine Policy-Entscheidung. Behandeln Sie eine signierte Agent Card wie ein signiertes Container-Image: notwendig für Supply-Chain-Hygiene, nicht hinreichend für Vertrauen.

Der Task-Lebenszyklus als Kernabstraktion

A2A unterscheidet zustandslose Nachrichten von zustandsbehafteten Tasks. Ein Task ist die Einheit delegierter Arbeit. Seine Kernzustände sind submitted, working, input-required und auth-required; terminale Zustände sind completed, canceled, failed und rejected. Updates fließen über Server-Sent Events oder gRPC-Streams; Push-Notifications decken langlaufende Arbeit ab, wenn keine Verbindung offen gehalten wird. Dieser Lebenszyklus ist der Vertrag, gegen den jede A2A-Integration gebaut wird.

Die Spezifikation definiert Zustandsübergänge und ihre Semantik, nicht jedoch deren Persistenz. Task-Speicherung, Retries, Idempotenz und Timeout-Budgets bleiben Verantwortung des Implementierers. In unseren Integrationsprojekten entfällt deshalb der größte Teil des Aufwands auf den Task-Store, nicht auf den Transport. Planen Sie diesen Baustein vor der ersten Demo ein; nachträglich wird er zum teuersten Teil der Integration.

Ein Protokoll mit drei Bindings

v0.3.0 definiert drei Transporte: JSON-RPC 2.0 über HTTP ist verpflichtend; gRPC über HTTP/2 und einfaches HTTP+JSON sind optional. Die Agent Card deklariert, welche Kombinationen aus URL und Transport ein Agent bedient. Funktionale Äquivalenz ist vorgeschrieben — jede Methode muss sich unabhängig vom Binding identisch verhalten. Die Wahl ist pragmatisch: JSON-RPC für Reichweite, gRPC für Performance und Streaming in kontrollierten Umgebungen.

Am 20. November 2025 hat das Steering Committee Pull Request #1160 gemergt, eine Neufassung der Spezifikation: 4.328 Zeilen hinzugefügt, 7.042 entfernt, verteilt über 32 Dateien. Sie trennt das abstrakte Protokoll — Operationen, Datenmodell, Semantik — von drei formalen Protocol Bindings, mit a2a.proto als normativer Quelle. Das TSC hat diesen Stand zur Basis des v1.0 Release Candidate erklärt.

Was der 1.0 Release Candidate ändert

Der Release-Pull-Request für 1.0.0 ist seit dem 21. November 2025 offen, und konkrete Änderungen sind bereits gelandet. Multi-Tenancy wurde am 4. Dezember 2025 gemergt: Jede Anfrage trägt ein optionales tenant-Routingfeld, sodass ein einzelner Endpunkt viele Agenten sicher bedienen kann. Die Transportfelder der Agent Card werden in eine supportedInterfaces-Liste konsolidiert, und jedes Interface deklariert seine eigene Protokollversion — das ermöglicht schrittweise Migration statt eines harten Umstiegs.

Zwei Breaking Changes sind beschlossen oder noch in Abstimmung. Künftig folgt die JSON-Serialisierung den ProtoJSON-Konventionen; aus Enum-Werten wie "input-required" wird damit TASK_STATE_INPUT_REQUIRED. Ein weiterer, am 11. Dezember 2025 eröffneter Vorschlag entfernt die OAuth-Flows Implicit und Password und ergänzt Device Code (RFC 8628) sowie PKCE; zum Zeitpunkt dieses Artikels läuft das TSC-Votum noch. Die belastbare Planungsannahme lautet daher: 1.0 stabilisiert die Konzepte, bricht aber Wire-Formate.

Was Sie jetzt bauen und was Sie kapseln sollten

Unsere Empfehlung folgt direkt aus dieser Trennung: Bauen Sie heute auf v0.3.0, aber behandeln Sie das Wire-Format als instabil. Mappen Sie A2A-Typen an der Systemgrenze in Ihr eigenes Domänenmodell; kodieren Sie Enum-Strings, Methodennamen und Card-Feldpfade nicht hart. Halten Sie den Transport austauschbar und prüfen Sie Card-Signaturen beim Einlesen statt bei jedem Aufruf. Eine zusätzliche Mapping-Schicht kostet wenig und hält die 1.0-Migration klein.

Bereich	Heute stabil (v0.3.0)	Änderungen Richtung 1.0
Agent Card	Discovery über Well-known-URI; Skills; JWS-Signaturen	Felder konsolidiert in supportedInterfaces
Task-Lebenszyklus	Zustandsmenge und Semantik	Enum-Schreibweise nach ProtoJSON (breaking)
Bindings	JSON-RPC 2.0 verpflichtend; gRPC und HTTP+JSON optional	Formale Bindings mit Äquivalenzgarantien; Umbenennungen
Security	mTLS-Schemata; signierte Cards	OAuth-Flows modernisiert (Device Code, PKCE) — im Votum
Tenancy	Nicht im Protokoll	tenant-Routingfeld (gemergt 4. Dez. 2025)

Ausblick: A2A 1.0 Anfang 2026

Wir erwarten A2A 1.0 im ersten Quartal 2026. Der Release-Pull-Request ist offen, die RC-Basis gemergt, und die verbleibenden Abstimmungen straffen den Umfang, statt neue Features hinzuzufügen. Die Maintainer wollen zunächst eine stabile, eindeutige und protokollübergreifende Spezifikation schaffen. Diese Reihenfolge ist richtig. Für Kundenprojekte kalkulieren wir mit einer Migration innerhalb des ersten Quartals nach dem Release.

Daraus leiten wir zwei Prognosen ab. Erstens macht Multi-Tenancy gehostete Agentenplattformen praktikabel: ein Endpunkt, viele Agenten, eine Betriebsoberfläche. Analog zu Container-Registries werden Registries und Gateways folgen, die signierte Agent Cards auflösen und verifizieren. Zweitens werden A2A und MCP komplementäre Rollen einnehmen: MCP verbindet ein Modell mit Werkzeugen, A2A verbindet Agenten miteinander. Offen bleibt, ob sich die Branche auf diesen einen Task-Lebenszyklus einigt oder mehrere etabliert. Unsere Architektur setzt darauf, dass dieser Bestand hat, kapselt aber sein Wire-Format.