← Wissensdatenbank

A2A — Agent-to-Agent-Protokoll

Was ist A2A?

A2A (Agent-to-Agent) ist ein offenes Protokoll, mit dem KI-Agenten einander entdecken, sich gegenseitig authentifizieren und miteinander kommunizieren. Eine Site, die einen Agenten hostet, veröffentlicht eine Agent Card — ein JSON-Manifest unter /.well-known/agent-card.json — die Identität, Capabilities, Skills des Agenten und die URL deklariert, unter der andere Agenten ihn erreichen. Das Protokoll wurde im April 2025 von Google vorgestellt und später im selben Jahr an die Linux Foundation übergeben — Teil eines Branchenvorstoßes für eine offene Agent-Interoperabilitätsschicht.

A2A sitzt auf einer anderen Ebene als MCP. MCP definiert, wie ein Agent ein Tool aufruft; A2A definiert, wie ein Agent einen anderen Agenten aufruft. Beide lassen sich kombinieren: Ein MCP-Server exponiert Tools für einen einzelnen Agenten; ein A2A-Endpoint exponiert einen ganzen Agenten für das weitere Agent-Netzwerk.

Warum A2A wichtig ist

Das Agent-Ökosystem konvergiert 2025-2026 auf ein Multi-Agent-Muster: Ein nutzerseitiger Agent (Claude, ChatGPT, Gemini) koordiniert sich mit Spezialisten-Agenten, die andere Services hosten. Der Buchungs-Agent einer Reise-Site ist ein Spezialist; der Erstattungs-Agent einer E-Commerce-Site ein anderer. Der nutzerseitige Agent braucht einen Weg, diese Spezialisten zu entdecken, ihre Fähigkeiten zu erfahren und sie aufzurufen — ohne SDK-Integration pro Anbieter.

A2A ist das Protokoll für diese Discovery- und Routing-Schicht. Eine Agent Card sagt dem aufrufenden Agenten:

• Wer du bist — Name, Beschreibung, Version, Anbieter.
• Was du kannst — eine Liste benannter Skills, jeder mit eigener Beschreibung.
• Wie man dich erreicht — die URL deines Agent-Endpoints und der unterstützte Transport (HTTP, SSE, WebSocket).
• Wie man sich authentifiziert — das Auth-Schema, inklusive OAuth-Flows oder API-Key-Übergabe.

Ohne A2A hat ein Agent, der deine Site findet, keinen Weg von „diese Site existiert“ zu „diese Site kann mir bei Erstattungen helfen, über genau diesen Endpoint mit genau dieser Auth“. A2A ist diese Brücke.

So funktioniert A2A

Es gibt zwei Teile: die Agent Card (Discovery) und den A2A-Endpoint (Ausführung).

1. Die Agent Card ist eine statische JSON-Datei unter /.well-known/agent-card.json. Andere Agenten rufen sie ab wie jede Well-Known-Datei. Eine minimale gültige Agent Card:

{
  "name": "Acme Support Agent",
  "description": "Handles customer inquiries, refunds, and order status.",
  "version": "1.0.0",
  "url": "https://acme.example.com/agent",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "process-refund",
      "name": "Process Refund",
      "description": "Issue a refund for a given order ID."
    },
    {
      "id": "order-status",
      "name": "Order Status",
      "description": "Look up the status of an order by order ID."
    }
  ]
}

2. Der A2A-Endpoint unter der in der Card deklarierten URL nimmt Requests für diese Skills entgegen. Das Protokoll nutzt JSON-RPC-artige Nachrichten über HTTP (mit optionalem SSE für Streaming) und unterstützt ein strukturiertes Nachrichtenformat mit Text-, Datei- und Strukturdaten-Teilen.

Der aufrufende Agent liest die Card, wählt einen passenden Skill, authentifiziert sich bei Bedarf und sendet per POST eine Nachricht an den Endpoint. Der empfangende Agent verarbeitet sie und antwortet — gegebenenfalls per Streaming, falls die Card Streaming-Support deklariert hat.

A2A vs. andere Agent-Interop-Protokolle

Protokoll	Zweck	Transport	Was exponiert wird
A2A	Agent ruft anderen Agenten auf	HTTP/SSE	Ein ganzer Agent mit benannten Skills
MCP	Agent ruft ein Tool auf	JSON-RPC über HTTP/SSE	Einzelne Tools auf einem Server
OpenAPI	Agent ruft eine REST-API auf	HTTP	API-Endpoints mit Schemas
SKILL.md	Erklärt dem Agenten die Nutzung eines Service	Statisches Markdown	Prosa-Playbook für einen HTTP-Service
WebMCP	Agent ruft eine Website über den Browser auf	Browser-API	Annotierte HTML-Formulare

A2A ist das einzige dieser Protokolle, bei dem der Aufgerufene selbst ein Agent ist, kein Tool und keine statische API. Der Unterschied zählt: A2A-Endpoints können schlussfolgern, planen und weiterdelegieren. Sie sind Peers, keine Funktionen.

Felder der Agent Card

Die vollständige Agent-Card-Spezifikation umfasst:

• name — menschenlesbarer Agent-Name. Pflicht.
• description — was der Agent tut, in Prosa. Pflicht.
• url — wo der A2A-Endpoint liegt. Pflicht.
• version — Versionsstring des Agenten. Empfohlen.
• provider — Anbieterinfos: Organisationsname, URL.
• capabilities — Feature-Flags: streaming, pushNotifications, stateTransitionHistory.
• skills — Array von Skill-Objekten mit id, name, description und optionalen inputModes / outputModes.
• authentication — Details zum Auth-Schema: Typ (bearer, oauth2, apiKey) und schema-spezifische Felder.
• defaultInputModes / defaultOutputModes — unterstützte Content-Types für Skill-Aufrufe (text, file, data).

AgentGrades A2A-Check validiert, dass die Card existiert, als JSON parst und mindestens name und url enthält. Reichhaltigere Cards punkten beim binären Check gleich, signalisieren konsumierenden Agenten aber, dass der Service gut integriert ist.

Wer A2A nutzt

A2A startete mit Rückhalt von Google und einer Koalition von Partnern. Öffentliche Adopter und Integratoren 2025-2026:

• Google — der ursprüngliche Autor; A2A ist in den Vertex AI Agent Builder integriert.
• Linux Foundation — A2A wurde an die LF übergeben, um neutrale Governance zu sichern.
• Atlassian — hat Agent Cards für Jira- und Confluence-Agenten veröffentlicht.
• Box, MongoDB, PayPal, SAP, ServiceNow, Workday — frühe Ökosystem-Partner, die beim Launch gelistet wurden.

Das Adoptionsmuster spiegelt die frühen Jahre von OpenAPI: eine Google-geführte Spezifikation, die zuerst von Enterprise-SaaS übernommen wird, mit breiterer Verbreitung, sobald Multi-Agent-Orchestrierung von Forschungs-Demos in die Produktion wandert.

So fügst du A2A zu deinem Service hinzu

1. Entscheide, ob du einen Agenten zu exponieren hast. A2A ist für Agenten, nicht für statische APIs. Ist dein Service eine REST-API, liefere OpenAPI; ist er ein MCP-Tool-Server, liefere MCP. Hast du einen Service, der plant, schlussfolgert oder Konversationszustand hält, ist A2A die richtige Schicht.
2. Schreibe die Agent Card unter /.well-known/agent-card.json. Beginne mit den Minimalfeldern (name, description, url, skills). Ergänze capabilities und authentication, sobald du sie implementierst.
3. Stelle den A2A-Endpoint unter der URL in der Card bereit. Das Python-SDK unter github.com/a2aproject/A2A ist die Referenzimplementierung; JavaScript- und andere Ports existieren.
4. Implementiere mindestens einen Skill. Liefere keine Agent Card mit Skills aus, die du nicht gebaut hast — Agenten, die dich aufrufen und Fehler bekommen, stufen dich herab.
5. Teste mit einem Aufrufer. Nutze einen generischen A2A-Client, um zu prüfen, dass die Card parst und der Endpoint auf eine echte Nachricht antwortet.
6. Verlinke aus llms.txt oder SKILL.md, damit auch Discovery-Pfade ohne native A2A-Unterstützung deine Card finden.

Häufige Fehler, die Scanner melden

• Keine Agent Card — /.well-known/agent-card.json liefert 404. AgentGrades A2A-Check ist informativ; das ist kein Score-Abzug, aber eine verpasste Chance für Services, die tatsächlich einen Agenten hosten.
• Card liefert HTML statt JSON — Catch-all-Routen von Single-Page-Apps geben für jeden Pfad das Homepage-HTML zurück. Liefere rohes JSON aus einer statischen Datei oder einer Framework-Route, die den SPA-Fallback umgeht.
• Fehlendes name oder url — die minimalen Pflichtfelder der Spezifikation. Cards ohne sie sind nicht aufrufbar.
• url zeigt auf einen 404 — die Card deklariert einen Endpoint, der nicht existiert.
• Skills-Array leer oder fehlend — die Card validiert, aber es gibt nichts, was ein Agent aufrufen könnte.
• CORS blockiert den Fetch — Agenten, die die Card aus einem Browser-Kontext lesen, brauchen Access-Control-Allow-Origin: * oder eine permissive Policy.

Häufig gestellte Fragen

Ist A2A ein Ersatz für MCP?

Nein. Sie lösen verschiedene Probleme. MCP ist für einen Agenten, der ein Tool aufruft; A2A für einen Agenten, der einen anderen Agenten aufruft. Eine Site mit einem Tool-Server veröffentlicht MCP; eine Site mit einem ganzen Agenten veröffentlicht A2A. Manche Sites machen beides.

Brauche ich A2A, wenn ich OpenAPI habe?

Nur wenn dein Service ein Agent ist (schlussfolgert, plant, Zustand über mehrere Turns hält). REST-APIs liefern OpenAPI; Agenten liefern A2A. Beides koexistiert — ein A2A-Agent ruft in seiner Implementierung oft REST-APIs auf, die in OpenAPI dokumentiert sind.

Ist A2A für das AgentGrade-Scoring erforderlich?

A2A ist ein informativer Check, kein gewerteter. AgentGrade zeigt das Vorhandensein einer Agent Card an, bestraft ihr Fehlen aber nicht bei Sites, die keine Agenten sind. Sites mit statischem Content sollten keine leeren Agent Cards veröffentlichen.

Was passiert, wenn meine Agent Card bei den Capabilities lügt?

Die Card deklariert, was der Agent behauptet; der aufrufende Agent merkt es irgendwann über fehlgeschlagene Requests. Wie bei jedem Deklariert-vs-Verifiziert-Signal untergräbt Lügen mit der Zeit das Vertrauen. AgentGrades Check prüft derzeit nur das Vorhandensein und testet deklarierte Skills nicht.

Kann ich mehrere Agent Cards veröffentlichen?

Die Spezifikation sieht eine Card pro Origin vor. Services mit mehreren eigenständigen Agenten teilen sie üblicherweise auf Subdomains auf.

Wie hängen A2A und Googles Vertex AI Agent Builder zusammen?

Vertex AI Agent Builder ist Googles gehostete Agent-Runtime; sie produziert und konsumiert A2A. A2A selbst ist das offene, an die Linux Foundation übergebene Protokoll, das Vertex und jede andere Agent-Runtime sprechen kann.

Wie entdecken Agenten Agent Cards?

Genauso, wie sie jede Well-Known-Datei entdecken: ein direkter Fetch von /.well-known/agent-card.json oder über einen Link aus /llms.txt. Agent-Indizes und -Verzeichnisse beginnen, Agent Cards so zu crawlen, wie Suchmaschinen Sitemaps crawlen.

Unterstützt A2A Zahlungen?

Die Spezifikation enthält Capability-Deklarationen, aber die Zahlung wird an das darunterliegende Auth-Schema delegiert. Sites, die A2A mit x402 kombinieren, deklarieren die Zahlungspflicht typischerweise in der Skill-Beschreibung und sichern den Endpoint mit einer 402-Challenge ab.

Reifegrad der Spezifikation

Offener Standard, frühe Adoption. A2A wird von der Linux Foundation verwaltet. Das Python-SDK ist die Referenzimplementierung. Frühe Adopter sind Enterprise-SaaS; breitere Verbreitung folgt, während Multi-Agent-Orchestrierung in die Produktion wandert.

Mehr erfahren

• A2A Protocol Specification — offizielle Doku
• A2A GitHub repository — Referenzimplementierungen
• MCP — Begleitprotokoll für Tool-Aufrufe
• Agent Readiness — wie A2A ins größere Bild passt

A2A im Jahr 2026

A2A erreichte v1.0.0 am 12. März 2026 — das Projekt nennt sie die erste stabile, produktionsreife Version. Die wichtigste Neuerung sind signierte Agent Cards: Ein signatures-Feld auf der Card lässt andere Agenten kryptografisch verifizieren, wer sie veröffentlicht hat. v1.0.1 folgte im Mai 2026.

Der Pfad der Agent Card ist jetzt formal festgelegt: /.well-known/agent-card.json ist in der IANA-Registry für Well-Known-URIs registriert (permanenter Status, registriert im August 2025, Änderungskontrolle bei der Linux Foundation). Spezifikationsversionen vor v0.3.0 nutzten /.well-known/agent.json — hast du den alten Pfad veröffentlicht, liefere den neuen aus und behalte eine Weiterleitung. AgentGrades Scanner prüft zuerst den aktuellen Pfad und fällt auf den alten zurück.

Die Linux Foundation berichtete im April 2026, dass mehr als 150 Organisationen den Standard unterstützen, mit Produktionseinsätzen in mehreren Branchen.

Verwandt: Was ist KI-Agent-Readiness?