KI & AI

Agent2Agent-Protokoll (A2A)

Overview

Das Agent2Agent-Protokoll (A2A) ist ein offener Standard für die Kommunikation zwischen KI-Agenten. Ein Agent kann damit einen anderen Agenten finden, ihm eine Aufgabe übertragen und das Ergebnis abholen, auch über Hersteller- und Organisationsgrenzen hinweg. Der aufgerufene Agent bleibt dabei eine Blackbox: Der Client sieht dessen Beschreibung, die Aufgabe und ihren Status, aber nicht die internen Tools, den Speicher oder das Modell.

Google hat A2A im April 2025 veröffentlicht und im Juni 2025 an die Linux Foundation übergeben, Gründungsmitglieder waren unter anderem AWS, Cisco, Microsoft, Salesforce, SAP und ServiceNow. Im August 2025 floss das Agent Communication Protocol (ACP) von IBM ein. Die erste stabile Version 1.0 wurde am 12. März 2026 festgeschrieben und bringt unter anderem signierte Agent Cards, Multi-Tenancy und mehrere Transportbindungen. Seit dem 17. August 2026 gehört A2A zur Agentic AI Foundation (AAIF), zu der auch MCP zählt. Laut Linux Foundation unterstützten im April 2026 über 150 Organisationen das Protokoll.

Abgrenzung: MCP verbindet einen Agenten mit Werkzeugen und Datenquellen, A2A verbindet Agenten untereinander und regelt die Delegation von Arbeit. Beide ergänzen sich, ein Agent kann intern MCP-Tools nutzen und nach außen per A2A erreichbar sein. Im Microsoft-Umfeld unterstützt der Foundry Agent Service A2A 1.0 allgemein verfügbar (Version 0.3 als Preview), laut Linux Foundation ist A2A auch in Copilot Studio integriert. Das übergeordnete Konzept beschreibt der Eintrag KI-Agenten.

How it works

A2A standardisiert vier Kernobjekte (Agent Card, Task, Message, Artifact) und einen festen Ablauf:

  1. Discovery: Jeder A2A-Server veröffentlicht eine Agent Card, ein JSON-Dokument unter /.well-known/agent-card.json mit Identität, Fähigkeiten (Skills), Endpunkten und Authentifizierungsanforderungen. Alternativ kommt die Karte aus einer Registry oder einer statischen Konfiguration.
  2. Auftrag: Der Client sendet eine Message aus einem oder mehreren Parts (Text, Datei, strukturierte Daten). Daraus entsteht ein Task mit eigener ID und Kontext.
  3. Bearbeitung: Der Task durchläuft definierte Zustände wie SUBMITTED, WORKING, INPUT_REQUIRED oder AUTH_REQUIRED bis zu einem Endzustand wie COMPLETED, FAILED, CANCELED oder REJECTED.
  4. Ergebnis: Der Agent liefert Artifacts zurück, als direkte Antwort, per Streaming über Server-Sent Events oder per Push-Benachrichtigung an einen Webhook.

Die Operationen sind an JSON-RPC, gRPC und HTTP+JSON (REST) gebunden, alle drei sind funktional gleichwertig. Der Client nennt die Protokollversion im Header A2A-Version. Für die Authentifizierung sieht die Spezifikation API-Schlüssel, HTTP-Authentifizierung, OAuth 2.0, OpenID Connect und Mutual TLS vor.

Benefits

  • Herstellerunabhängige Zusammenarbeit: Ein Agent in Microsoft Foundry kann einen Agenten auf einer anderen Plattform beauftragen, ohne individuelle Schnittstelle
  • Kapselung: Der aufgerufene Agent legt weder Tools noch Daten noch Modell offen, das schützt Know-how und verkleinert die Angriffsfläche
  • Lang laufende Aufgaben mit Rückfragen sind vorgesehen (INPUT_REQUIRED, AUTH_REQUIRED, Streaming, Push), statt nur einfacher Anfrage-Antwort-Aufrufe
  • Bekannte Web-Sicherheitsmechanismen wie OAuth 2.0, OpenID Connect und mTLS sowie signierte Agent Cards erleichtern die Einbindung in bestehende Identitätsinfrastruktur
  • Offene Governance unter der Linux Foundation bzw. AAIF verringert die Abhängigkeit von einem einzelnen Anbieter

Practical example

Ein Automobilzulieferer mit 900 Beschäftigten betreibt einen Einkaufsagenten in Microsoft Foundry. Für Verfügbarkeitsanfragen soll er direkt mit dem Agenten eines Logistikpartners sprechen, der auf einer anderen Cloud-Plattform läuft. Der Partner veröffentlicht eine Agent Card mit OAuth-2.0-Anforderung, der Einkaufsagent bindet ihn als A2A-Tool im Foundry Agent Service an und übergibt Anfragen als Task. Braucht der Logistikagent eine Entscheidung, meldet er INPUT_REQUIRED, und der zuständige Einkäufer bestätigt. Die internen Daten des Partners bleiben hinter dessen Agenten verborgen.

Things to keep in mind

  • Auf Version 1.0 setzen: Implementierungen nach 0.3 nutzen einen anderen Pfad für die Agent Card (agent.json), und fehlt der Header A2A-Version, gilt 0.3
  • Fremde Agenten wie externe Benutzer behandeln: Ihre Antworten können Prompt Injection enthalten, Ergebnisse deshalb validieren, bevor sie an Tools weitergehen
  • OAuth 2.0 oder mTLS statt statischer API-Schlüssel verwenden und signierte Agent Cards verifizieren
  • Webhook-Empfänger für Push-Benachrichtigungen absichern: Task-ID kontrollieren, doppelte Zustellungen einplanen und nur bei korrekter Verarbeitung mit 2xx antworten
  • Agenten-Identitäten minimal berechtigen, weil ein delegierter Auftrag mit den Rechten des aufgerufenen Agenten ausgeführt wird

Conclusion

A2A ist das Gegenstück zu MCP für die Zusammenarbeit zwischen Agenten und mit Version 1.0 stabil genug für produktive Szenarien. Relevant wird es für Dich, sobald Agenten über Plattform- oder Firmengrenzen hinweg Aufgaben austauschen sollen.

Further reading

Related articles