A2A Protokoll Google: Agenten standardisiert verbinden

Definition

Das A2A Protokoll (Agent2Agent) ist ein offenes Agent Protocol für standardisierte Kommunikation zwischen AI Agents über HTTP/HTTPS. Es ist kein Framework für Agent-Logik und kein Ersatz für Tool- oder Daten-Context-Protokolle wie MCP.

Einleitung

Wenn Agenten mehr als Demos sein sollen, müssen sie über System- und Teamgrenzen hinweg Aufgaben delegieren und Ergebnisse zuverlässig zurückgeben. Genau dafür ist das A2A Protokoll von Google gedacht: Agent Communication wird standardisiert, sodass remote Agents miteinander communicate können, ohne dass jede Integration neu erfunden wird.

Architektur: Welche Komponenten dazugehören

In A2A sprechen ein A2A Client (Client Agent) und ein A2A Server (Remote Agent) miteinander. Transport ist typischerweise HTTP/HTTPS, die Aufrufe folgen häufig JSON-RPC 2.0; für laufende Status-Updates kann Server-Sent Events (SSE) genutzt werden.

• Agent Card: beschreibt Endpoint, Identität und Capabilities für Discovery.

• A2A Task: eine Arbeitseinheit mit Task Lifecycle States (z. B. erstellt, laufend, fertig, fehlgeschlagen).

• Message, Part, Artifact: strukturieren Eingaben, Zwischenschritte und Ergebnisse für Interoperability.

So funktioniert A2A Schritt für Schritt (Discovery, Authentication, Communication)

1) Discovery

Der Client lädt die Agent Card eines Remote Agent. Damit wird sichtbar, welche Tasks der Agent übernehmen kann. Das ist entscheidend für Multi-Agent-Workflows: Orchestrierung wird planbar, statt auf impliziten Annahmen zu basieren.

2) Authentication

Bevor Agents collaborate, wird Authentifizierung und Autorisierung geklärt, z. B. über OAuth 2.0, OpenID Connect, JWT, mTLS oder API Keys (je nach Enterprise-Policy). Praktischer Nutzen: Du kannst Capabilities an Rollen koppeln und Agent-Zugriffe auditierbar machen.

3) Communication

Der Client sendet eine A2A Task mit einer Message (und ihren Parts). Der Server verarbeitet, aktualisiert die Task Lifecycle States und liefert ein Artifact zurück. Bei längeren Workflows kann der Server Fortschritt streamen (SSE), damit UIs, Logs oder ein Orchestrator nicht raten müssen, was gerade passiert.

Voraussetzungen und Setup: erster Server, erster Client

Für ein erstes Deployment braucht es weniger Technik als meist gedacht, aber klare Entscheidungen: Welche Tasks sollen standardisiert werden, und welche Agents sind dafür verantwortlich?

• Server: ein Remote Agent als A2A Server (z. B. auf Cloud Run), der Tasks annimmt und Artifacts zurückgibt.

• Client: ein Client Agent, der Agent Cards liest und Tasks erstellt.

• Security & Betrieb: Identity, Secrets, Logging und ein minimales Monitoring für Task-Zustände.

Wenn du schon Agent Frameworks nutzt (z. B. ADK oder andere), ist A2A die Schicht, die die Zusammenarbeit standardisiert, ohne das Framework zu ersetzen.

Implementierung: Pseudocode für Client und Server

Client (vereinfacht)

1) agentCard = GET /agent-card

2) validate(agentCard.capabilities)

3) token = getAuthToken()

4) taskId = jsonrpc("createTask", {messageParts, context}, token)

5) subscribeSSE(taskId) oder poll("getTask")

6) artifact = jsonrpc("getArtifact", {taskId}, token)

Server (vereinfacht)

1) verifyAuth(token)

2) task = createTask(message)

3) setState(task, "running")

4) result = runWorkflows(task.context)

5) setState(task, "completed"), storeArtifact(result)

6) return artifactRef

Use Case (Mini-Story): Purchasing Concierge

Ein „Purchasing Concierge“ besteht aus mehreren Agents: Ein Agent sammelt Bedarf und Kontext, ein remote Agent prüft Lieferanten/Policies, ein dritter fasst Optionen als Entscheidungsvorlage zusammen. Mit A2A wird daraus ein standardisierter Ablauf: Jeder Agent ist für seinen Task verantwortlich, Zustände sind sichtbar, und das Ergebnis kommt als Artifact strukturiert zurück. Der Nutzen für Anwender: weniger Ping-Pong, schnellere Freigaben, weniger manuelle Copy-Paste-Arbeit.

A2A vs. MCP: Ähnliche Idee, anderer Zweck

MCP (Model Context Protocol) adressiert vor allem Context- und Tool-Anbindung: wie ein Agent Datenquellen und Tools standardisiert nutzt. A2A adressiert Agent Interoperability: wie mehrere AI Agents über ein Agent Protocol Aufgaben koordinieren, auch across unterschiedliche Frameworks und vendor-Setups. In der Praxis ist die beste Architektur oft: MCP für Toolzugriff, A2A für Agent Coordination.

Sicherheit, Interoperabilität und Standards

Produktionsreife hängt an Governance, nicht an Demo-Code. Bewährt hat sich:

• Least Privilege pro Capability: Agents bekommen nur die Rechte für ihre Tasks.

• Auditierbarkeit: Task Lifecycle States, Auth-Claims und Artifacts werden nachvollziehbar geloggt.

• Interoperability-Tests: Message/Part/Artifact-Schemata als Contracts testen, bevor Partner-Agents dazukommen.

Wann externe Unterstützung sinnvoll wird

Spätestens wenn mehrere Agents, Teams oder Partner beteiligt sind, wird aus „läuft“ schnell „läuft stabil, sicher und messbar“. Dann lohnt sich Unterstützung bei Architektur (Client/Server-Schnitt), Authentication-Design, Observability und dem Weg von ersten Deployments zu wiederholbaren Workflows.

Wenn du A2A in Richtung produktive Multi-Agent-Orchestrierung bringen willst, ist der schnellste Einstieg ein kostenloses Erstgespräch und ein klar abgegrenzter Pilot mit messbaren Tasks.