Das A2A-Protokoll erklärt: Agent Cards, Tasks und sein Platz neben MCP

Die meisten Agenten-Werkzeuge drehten sich bisher um einen Agenten und seine Tools. Das nächste Problem taucht auf, sobald zwei Agenten verschiedener Teams zusammenarbeiten müssen: ein Einkaufsagent in Ihrem Shop, der den Verfügbarkeitsagenten eines Lieferanten fragen will, oder ein interner Support-Agent, der einen Fall an den Agenten des Logistikteams übergibt. Jede Seite hat ihr eigenes Framework, Modell und Deployment. Ohne gemeinsames Protokoll ist jede solche Paarung eine Einzelintegration.

Agent2Agent (A2A) ist das offene Protokoll für dieses Problem. Dieser Artikel erklärt, was Version 1.0 der Spezifikation tatsächlich standardisiert, Agent Cards, Tasks, Nachrichten, Transporte und Sicherheit, wie es sich zu MCP verhält, welche Vertrauensprobleme es nicht für Sie löst und wann ich es einsetzen würde.

Was ist das A2A-Protokoll?

Google stellte A2A am 9. April 2025 mit mehr als 50 Technologiepartnern vor, aufgebaut auf bestehenden Standards wie HTTP, SSE und JSON-RPC. Die fünf Designprinzipien: agentische Fähigkeiten ernst nehmen, auf bestehenden Standards aufbauen, standardmäßig sicher sein, lang laufende Tasks unterstützen und modalitätsunabhängig sein. Am 23. Juni 2025 startete die Linux Foundation das Agent2Agent-Projekt auf dem Open Source Summit North America, unterstützt von mehr als 100 Unternehmen, womit die Steuerung nicht mehr bei einem einzelnen Anbieter liegt.

Die aktuelle Spezifikation ist Version 1.0.0, nach 0.1.0, 0.2.6 und 0.3.0. Kompatibilität wird über Major- und Minor-Version geführt, Clients senden einen A2A-Version-Header. In ihrem Update zum ersten Jahrestag am 9. April 2026 beschrieb die Linux Foundation 1.0 als erste stabile Spezifikation und meldete mehr als 150 unterstützende Organisationen, SDKs in fünf Sprachen (Python, JavaScript, Java, Go und .NET) sowie Unterstützung in Azure AI Foundry, Copilot Studio und Amazon Bedrock AgentCore Runtime.

Wie verhält sich A2A zu MCP?

Die A2A-Dokumentation beschreibt beide als komplementäre Schichten. MCP ist vertikal: Es gibt einem Agenten strukturierten Zugriff auf Tools und Ressourcen, die typischerweise klar definiert und oft zustandslos sind. A2A ist horizontal: Unabhängige, oft undurchsichtige Agenten arbeiten als Gleichrangige zusammen, mit Reasoning, Zustand und mehrstufigem Dialog auf beiden Seiten. In den Worten der Dokumentation: „A2A connects the agents to each other; MCP connects each agent to its own tools.“

Die Überschneidung ist real: Ein A2A-Agent mit wenigen zustandslosen Skills ließe sich als MCP-Server verpacken, das sagt auch die Dokumentation. Meine Faustregel: Verhält sich die Gegenseite wie eine Funktion, MCP nutzen; muss sie Rückfragen stellen, Minuten oder Stunden arbeiten oder ihr Reasoning für sich behalten, A2A nutzen. Zur MCP-Seite siehe die MCP-Sicherheits-Checkliste.

Was steht in einer Agent Card?

Eine Agent Card ist ein JSON-Dokument, in dem sich ein A2A-Server beschreibt. Das normative Datenmodell ist a2a.proto; Pflichtfelder von AgentCard sind Name, Beschreibung, unterstützte Schnittstellen, Version, Capabilities, Standard-Ein- und Ausgabemodi sowie Skills. Jede Schnittstelle nennt eine URL, ein Protokoll-Binding (JSONRPC, GRPC oder HTTP+JSON) und eine Protokollversion. Jeder Skill hat ID, Name, Beschreibung und Tags, dazu optional Beispiele, eigene Ein- und Ausgabemodi und Sicherheitsanforderungen.

// https://agents.supplier.example/.well-known/agent-card.json (illustrative)
{
  "name": "Parts Availability Agent",
  "description": "Answers stock and lead-time questions for industrial spare parts.",
  "version": "2.3.0",
  "provider": { "organization": "Example Supplier GmbH", "url": "https://supplier.example" },
  "supportedInterfaces": [
    { "url": "https://agents.supplier.example/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" },
    { "url": "https://agents.supplier.example/a2a/rest", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true },
  "securitySchemes": {
    "oidc": { "openIdConnectSecurityScheme": { "openIdConnectUrl": "https://login.supplier.example/.well-known/openid-configuration" } }
  },
  "securityRequirements": [ { "schemes": { "oidc": { "list": ["parts.read"] } } } ],
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "check-availability",
      "name": "Check availability",
      "description": "Stock level and lead time for a part number at a given warehouse.",
      "tags": ["inventory", "spare-parts"],
      "examples": ["Is ART-10001 in stock in Vienna?"]
    }
  ]
}

Für die Discovery nennt die Dokumentation drei Wege: die Well-known-URI https://{server_domain}/.well-known/agent-card.json, kuratierte Registries (für die die Spezifikation keine Standard-API definiert) und direkte Konfiguration. Der Card-Endpunkt sollte Cache-Control mit max-age und ein ETag senden, Clients sollten bedingte Anfragen nutzen. Karten können mit JSON Web Signature (RFC 7515) über eine nach JSON Canonicalization Scheme (RFC 8785) kanonisierte Form signiert werden, und Clients sollten mindestens eine Signatur prüfen, bevor sie einer signierten Karte vertrauen.

Eine öffentliche Karte sollte keine Interna preisgeben. Wer vertrauenswürdigen Partnern mehr Skills oder interne URLs zeigen will, setzt capabilities.extendedAgentCard und liefert die vollständige Karte über GetExtendedAgentCard aus, das eine Authentifizierung verlangen muss. Statische Geheimnisse gehören in keine Karte.

Skill-Beschreibungen für ein Modell schreiben, nicht für eine Marketingseite. Auf Client-Seite liest oft ein LLM die Karte, um zu entscheiden, welcher entfernte Agent und welcher Skill zu einer Anfrage passen; eine Beschreibung erfüllt also dieselbe Rolle wie eine Tool-Beschreibung in MCP: sagen, was der Skill tut, welche Eingabe er erwartet und was er nicht tut. version bei jeder Skill-Änderung erhöhen, damit gecachte Karten und ETags aussagekräftig bleiben.

Wie funktionieren Tasks, Nachrichten und Artefakte?

Eine Nachricht ist ein Kommunikationszug mit messageId, einer Rolle (ROLE_USER für den Client, ROLE_AGENT für den Server) und einer Liste von Parts. Ein Part ist die kleinste Inhaltseinheit: Text, Rohbytes, eine URL oder strukturierte Daten, optional mit mediaType und filename. Übernimmt der Server Arbeit, legt er einen Task an, mit vom Server vergebener id, einer contextId, die zusammengehörige Tasks und Nachrichten gruppiert, einem Status, einer Historie und Artefakten, den Ergebnissen wie Dokumenten oder strukturierten Daten, die wiederum aus Parts bestehen.

Bemerkenswert ist der Zustand TASK_STATE_AUTH_REQUIRED: Ein Agent kann mitten im Task pausieren, weil der Nutzer ihm Zugriff auf etwas gewähren muss, genau die Art Freigabeschritt, für die ich in Human in the Loop für KI-Agenten plädiere. Um einen mehrstufigen Austausch fortzusetzen, schickt der Client eine neue Nachricht mit derselben contextId und der taskId des bestehenden Tasks; nicht zusammenpassende IDs werden abgelehnt.

Welche Transporte und Update-Modi gibt es?

Version 1.0 definiert drei Standard-Bindings, JSON-RPC, gRPC und HTTP+JSON (REST), und erlaubt eigene. Alle Bindings müssen sich gleich verhalten, und die Proto-Datei ist die maßgebliche Quelle für die Datenobjekte. Die Kernoperationen bilden sich so ab:

SendMessage blockiert standardmäßig; mit returnImmediately kehrt es sofort zurück, und der Client verfolgt den Task auf einem von drei Wegen: Polling mit GetTask, Streaming mit SendStreamingMessage oder SubscribeToTask, oder Push-Benachrichtigungen, bei denen der Server Updates per POST an einen vom Client registrierten Webhook schickt. Push ist die richtige Wahl für Tasks, die Stunden dauern, denn so lange will niemand einen Stream offen halten. Ein JSON-RPC-Aufruf sieht so aus:

// POST https://agents.supplier.example/a2a  (JSON-RPC binding, illustrative)
{
  "jsonrpc": "2.0",
  "id": "req-42",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "9b0c7e7a-2f1d-4c55-9f0e-1f6a2d0c3e11",
      "role": "ROLE_USER",
      "parts": [{ "text": "Is ART-10001 in stock in Vienna, and what is the lead time for 40 units?" }]
    }
  }
}

Welches Binding man wählt, hängt vor allem davon ab, was die eigenen Dienste schon sprechen. JSON-RPC ist in Beispielen und SDKs am verbreitetsten, HTTP+JSON passt zu Teams mit REST-Gateways, die lesbare URLs in ihren Logs wollen, und gRPC zu internen Service-Meshes, die ohnehin Protobuf nutzen. Eine Karte kann mehrere Schnittstellen auflisten, ein Server kann also zwei Bindings anbieten, während Clients eines wählen.

Was gehört zur Sicherheit bei A2A?

Authentifizierung wird deklariert, nicht erfunden: Die Agent Card listet securitySchemes, das können API-Schlüssel, HTTP-Auth, OAuth 2.0 (Authorization Code, Client Credentials oder Device Code), OpenID Connect oder Mutual TLS sein, und gibt an, welche verlangt werden. Zugangsdaten laufen in der Transportschicht, wie bei jeder HTTP-API. Für Agent-zu-Agent-Aufrufe zwischen Unternehmen passen OAuth Client Credentials oder mTLS am besten, und der aufrufende Agent sollte eine eigene Identität mit engen Scopes haben, wie in KI-Agenten sind Identitäten beschrieben.

Der Sicherheitsteil der Spezifikation ergänzt Pflichten, die in der Praxis zählen:

• Autorisierung bei jeder Operation, mit auf den Aufrufer beschränkten Ergebnissen auch ohne Filter, und Prüfungen vor jedem Lookup, der die Existenz fremder Ressourcen verraten könnte.
• Webhook-Validierung gegen SSRF: private Bereiche wie 10.0.0.0/8 und 192.168.0.0/16, localhost und Link-Local-Adressen ablehnen und wo möglich Allowlists nutzen; Webhook-Anfragen nach 10 bis 30 Sekunden abbrechen.
• Eingabevalidierung und Limits für Nachrichtengrößen, Dateigrößen und Anfragekomplexität, dazu Rate Limiting für alle Operationen.
• Webhook-Empfänger prüfen, ob sich jede Benachrichtigung auf einen selbst gestarteten Task bezieht, und vertragen doppelte Zustellungen.

Warum ist ein entfernter Agent nicht vertrauenswürdige Eingabe?

Authentifizierung sagt Ihnen, wer der andere Agent ist, nicht, ob das, was er sagt, sicher ist. Am 31. Oktober 2025 veröffentlichte Unit 42 Agent Session Smuggling: Ein bösartiger entfernter Agent nutzt eine bestehende Session, um dem Client-Agenten verdeckte Anweisungen zu schicken. Im Proof of Concept, gebaut mit Googles Agent Development Kit, brachte der entfernte Agent einen Finanzassistenten dazu, seine Konfiguration und Session-Historie preiszugeben und ein buy_stock-Tool aufzurufen, das der Nutzer nicht verlangt hatte. Unit 42 stellt klar, dass dies keine Schwachstelle in A2A selbst ist; ausgenutzt wird das implizite Vertrauen zwischen Agenten in jedem zustandsbehafteten, mehrstufigen Protokoll.

Wann sollte man A2A nutzen, und wann nicht?

Ein Protokoll kostet etwas: eine Agent Card pflegen, einen Task-Speicher, Auth zwischen Diensten, Versionierung. Es lohnt sich an Grenzen, nicht innerhalb einer Codebasis. Meine Entscheidungshilfe:

Wer abwägt, ob er überhaupt mehrere Agenten braucht: Multi-Agenten-Systeme: wann sie sich lohnen behandelt Token-Kosten und Fehlermuster. Für den Handel gehört das Agent Payments Protocol (AP2) zum A2A-Ökosystem; ich vergleiche es mit UCP und ACP in Agentic-Commerce-Protokolle.

Wie fängt man mit A2A an?

1. Eine Grenze wählen, an der zwei Agenten schon über eine Einzelintegration sprechen, und den Austausch als Tasks mit expliziten Zuständen modellieren.
2. Zuerst die Agent Card schreiben: Skills mit klaren Beschreibungen und Beispielen, zum Start ein Binding und das Sicherheitsverfahren, das Sie wirklich durchsetzen.
3. Ein offizielles SDK nutzen statt das Protokoll von Hand zu schreiben, und die Protokollversion festlegen.
4. Tasks persistent speichern, in einem Speicher, der Neustarts übersteht, denn Tasks können einen Prozess überleben; für alles Langsame Push-Benachrichtigungen nutzen.
5. Über die Grenze hinweg tracen, mit Task-ID und Context-ID in jeder Logzeile, damit sich ein Fehler von einem Agenten in den anderen verfolgen lässt.

Quellen

1. A2A Protocol Specification (latest, v1.0)
2. A2A: a2a.proto, the normative data model (GitHub)
3. A2A docs: A2A and MCP
4. A2A docs: Agent discovery
5. Google Developers Blog: Announcing the Agent2Agent Protocol (Apr 2025)
6. Linux Foundation: Launch of the Agent2Agent Protocol Project (Jun 2025)
7. Linux Foundation: A2A surpasses 150 organizations in its first year (Apr 2026)
8. Unit 42: Agent Session Smuggling in Agent2Agent Systems (Oct 2025)