05.01.2026 AI Engineering 5 Minuten Lesezeit

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

A2A steht vor dem ersten produktionsreifen Release. Wir zeichnen den Weg von Googles Ankündigung im April 2025 zum v1.0 Release Candidate nach: signierte Agent Cards, Task-Lebenszyklus, Multi-Tenancy sowie JSON-RPC- und gRPC-Bindings. Dazu konkrete Hinweise, was Sie heute auf v0.3.0 bauen und welche Wire-Format-Änderungen Sie vor 1.0 kapseln sollten.

Agenten ohne gemeinsame Sprache

Jedes Agenten-Framework des Jahres 2025 definiert seine eigene Schnittstelle. LangGraph, CrewAI, Semantic Kernel und Googles ADK exponieren Agenten jeweils anders. Zwei davon zu verbinden erfordert einen eigenen Adapter; n Frameworks erfordern n×(n−1) Adapter. Das Model Context Protocol hat standardisiert, wie ein Modell Werkzeuge aufruft. Es hat nicht standardisiert, wie ein autonomer Agent einen anderen findet, sich authentifiziert und Arbeit delegiert — über Prozess-, Hersteller- und Organisationsgrenzen hinweg.

Genau diese Schicht adressiert das Agent2Agent-Protokoll (A2A). Agenten bleiben opak: Sie tauschen Nachrichten und Tasks aus, nicht internen Zustand, Gedächtnis oder Prompts. A2A definiert Discovery, Authentifizierungsschemata, Task-Delegation und Streaming. Es definiert nicht, wie ein Agent schlussfolgert, wie Arbeit orchestriert wird oder ob das Ergebnis korrekt ist. Das bleiben Engineering-Probleme auf beiden Seiten der Leitung.

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 existieren für Python, JavaScript, Java, Go und .NET. Seit November 2025 arbeitet das Projekt auf v1.0 zu — den ersten Release, den die Maintainer als produktionsreif bezeichnen. Dieser Artikel beschreibt, was stabil ist, was brechen wird und was Sie jetzt bauen sollten.

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, aber keine Persistenz. Task-Speicherung, Retries, Idempotenz und Timeout-Budgets liegen beim Implementierer. In unseren Integrationsprojekten entsteht der größte Teil des Aufwands im Task-Store, nicht im Transport. Planen Sie diesen Baustein ein, bevor die erste Demo steht.

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 in Abstimmung. Die JSON-Serialisierung folgt künftig ProtoJSON-Konventionen, was Enum-Werte wie "input-required" zu TASK_STATE_INPUT_REQUIRED macht. Und ein am 11. Dezember 2025 eröffneter Vorschlag entfernt die OAuth-Flows Implicit und Password und ergänzt Device Code (RFC 8628) und PKCE; er steht zum Zeitpunkt dieses Artikels noch im TSC-Votum. Rechnen Sie damit, dass 1.0 Wire-Formate bricht und Konzepte stabil hält.

Was Sie jetzt bauen und was Sie kapseln sollten

Unsere Empfehlung: Bauen Sie heute auf v0.3.0 und 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. Prüfen Sie Card-Signaturen beim Einlesen, nicht beim Aufruf. Das kostet eine Mapping-Schicht und kauft eine günstige 1.0-Migration.

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 ist gemergt, und die verbleibenden Abstimmungen betreffen Straffungen des Umfangs, keine neuen Features. Erklärtes Ziel der Maintainer ist eine stabile, eindeutige, protokollübergreifende Spezifikation, bevor neue Fähigkeiten aufgenommen werden. Das ist die richtige Reihenfolge. Für Kundenprojekte kalkulieren wir mit einer Migration innerhalb eines Quartals nach Release.

Zwei Prognosen. Erstens: Multi-Tenancy macht gehostete Agentenplattformen praktikabel — ein Endpunkt, viele Agenten, eine Betriebsoberfläche. Registries und Gateways, die signierte Agent Cards auflösen und verifizieren, werden folgen, analog zu Container-Registries. Zweitens: A2A und MCP finden in komplementäre Rollen — MCP verbindet ein Modell mit Werkzeugen, A2A verbindet Agenten mit Agenten. Ob sich die Branche auf einen Task-Lebenszyklus einigt oder auf mehrere, bleibt offen. Wir bauen auf der Annahme, dass dieser hält.