Websites werden für zwei Leser geschrieben: Menschen und Suchmaschinen. Inzwischen ist ein dritter dazugekommen. KI-Agenten, die im Auftrag von jemandem Angebote vergleichen, nachfragen und Anfragen weitergeben. Seiten lesen können sie gut genug. Was sie nicht zuverlässig können: mit dem Betrieb hinter der Seite sprechen.
A2A ist das Protokoll für genau dieses Gespräch. Nicht zwischen Mensch und Website, sondern zwischen zwei Agenten: dem, der für die Kundschaft arbeitet, und dem, der für den Betrieb antwortet.
A2A ist inzwischen ein stabiler Standard#
A2A steht für Agent2Agent Protocol. Google hat es im April 2025 vorgestellt, im Juni 2025 hat die Linux Foundation es als offenes Projekt übernommen. Am 12. März 2026 erschien Version 1.0, die erste, die ihre Macher stabil und bereit für den Produktiveinsatz nennen. Im August 2026 ist A2A der Agentic AI Foundation beigetreten, dem Dach, das die Linux Foundation für offene Standards rund um Agenten betreibt. Dort liegt auch MCP.
Mehr als 150 Organisationen unterstützen das Protokoll. Zum Start von 1.0 lenkte es ein technisches Gremium mit Vertretern von acht Firmen: AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP und ServiceNow. In der Praxis betreiben Google Cloud, AWS mit Bedrock AgentCore und Microsoft mit Azure AI Foundry A2A-Agenten, und Frameworks wie LangGraph, CrewAI und Pydantic AI sprechen es. Offizielle SDKs gibt es für Python, JavaScript, Java, Go, .NET und Rust.
Damit verschiebt sich die Frage. Vor einem Jahr lautete sie, ob A2A sich hält. Heute lautet sie, was in der Agent Card der eigenen Website stehen sollte.
Finden, fragen, Antwort bekommen#
Die Idee passt in drei Schritte. Ein Agent findet heraus, was ein anderer Agent kann. Er schickt eine Nachricht. Er bekommt eine Aufgabe zurück, mit Ergebnis oder mit einer Rückfrage, wenn etwas fehlt.
Technisch sitzt A2A auf JSON-RPC 2.0, einem kleinen, lange etablierten Verfahren, um Funktionen über HTTP aufzurufen. Version 1.0 beschreibt dieselben Operationen auch für gRPC und für schlichtes HTTP mit JSON, ein Agent kann also mehrere Wege zu denselben Funktionen anbieten. Diese Operationen tragen den größten Teil der Arbeit:
| Operation | Was sie tut |
|---|---|
SendMessage | Schickt eine Nachricht und liefert eine Aufgabe oder eine direkte Antwort |
GetTask | Liefert den aktuellen Stand einer Aufgabe |
ListTasks | Listet Aufgaben auf, zum Beispiel die eines Gesprächs |
CancelTask | Bricht eine laufende Aufgabe ab |
Dazu kommen Operationen für Streaming (SendStreamingMessage, SubscribeToTask), für Push-Benachrichtigungen und für eine erweiterte Agent Card, die nur angemeldete Clients zu sehen bekommen. Wer gegen Version 0.3 gebaut hat, kennt SendMessage, GetTask und CancelTask als message/send, tasks/get und tasks/cancel.
Welche Version ein Client spricht, sagt er im HTTP-Kopf A2A-Version. Ist der Kopf leer, soll der Server die Anfrage laut Spezifikation als 0.3 behandeln. So kann ein Server beide Versionen unter derselben Adresse bedienen, und die Agent Card sagt das offen.
Die Agent Card ist die Visitenkarte#
Bevor ein Agent mit einem anderen spricht, muss er wissen, wer auf der anderen Seite steht und was dort möglich ist. Dafür gibt es die Agent Card, eine JSON-Datei unter /.well-known/agent-card.json auf der Domain des Agenten.
Eine vereinfachte Karte für ein Restaurant, im Format von 1.0:
{
"name": "Pizzeria Roma",
"description": "Italienisches Restaurant in München. Beantwortet Fragen zur Speisekarte und nimmt Tischreservierungen an.",
"supportedInterfaces": [
{
"url": "https://pizzeria-roma.example/a2a",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"provider": {
"organization": "Pizzeria Roma",
"url": "https://pizzeria-roma.example"
},
"version": "1.0.0",
"capabilities": {
"streaming": false,
"pushNotifications": false
},
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"skills": [
{
"id": "make-reservation",
"name": "Tischreservierung",
"description": "Tisch reservieren mit Datum, Uhrzeit und Personenzahl.",
"tags": ["reservation", "booking", "table"],
"examples": [
"Reserviere einen Tisch für 4 Personen am Freitag um 19 Uhr",
"Ist heute Abend noch ein Tisch frei?"
]
},
{
"id": "view-menu",
"name": "Speisekarte",
"description": "Aktuelle Speisekarte mit Preisen und Allergenen.",
"tags": ["menu", "food", "allergens"]
}
]
}
Die größte Änderung gegenüber Version 0.3 ist supportedInterfaces. Eine Karte nach 0.3 nannte ihre Hauptadresse in url, weitere Transportwege in additionalInterfaces und eine protocolVersion für die ganze Karte. In 1.0 steht alles in einer Liste: jede Adresse mit ihrem Binding und der Protokollversion, die dort gesprochen wird. Ein Agent, der 1.0 und 0.3 unter derselben Adresse bedient, nennt diese URL zweimal, einmal je Version. Das Feld version ist die Version des Agenten selbst, nicht die des Protokolls.
Die Skills sind der eigentliche Zweck der Karte. Aus ihnen erfährt ein lesender Agent, was er anfragen kann, in welchem Format und mit welcher Art von Nachricht. Je genauer die Beschreibung, desto weniger falsche Anfragen kommen an.
Zwei Felder werden wichtig, sobald es um Vertrauen geht. securitySchemes legt fest, wie sich ein Client anmelden muss, mit den bekannten Wegen des Webs: API-Schlüssel, HTTP-Authentifizierung, OAuth 2, OpenID Connect oder gegenseitiges TLS. Und signatures kann eine JSON Web Signature über die Karte tragen, damit ein Agent prüfen kann, ob die Karte unverändert ist und wirklich von dem Anbieter stammt, den sie nennt. Eine Karte ohne Signatur bleibt gültig. Sie beweist nur weniger.
agents.json und Agent Card beantworten verschiedene Fragen#
Die beiden Dateien werden oft verwechselt, dabei ist der Unterschied einfach. agents.json beschreibt, welche Werkzeuge und HTTP-Endpunkte eine Website anbietet. Die Agent Card beschreibt einen Agenten, mit dem man sprechen kann.
| agents.json | agent-card.json | |
|---|---|---|
| Frage | Was kann diese Website? | Wie spreche ich mit ihrem Agenten? |
| Inhalt | Werkzeuge mit HTTP-Endpunkten, Methoden und Parametern | Skills, Schnittstellen, Fähigkeiten, Sicherheit |
| Protokoll | Kein eigenes, beschreibt REST-Endpunkte | A2A über JSON-RPC, gRPC oder HTTP mit JSON |
| Herkunft | Vorschlag aus der Community | Google, heute Agentic AI Foundation |
| Status | Kein offizieller Standard | Spezifikation in Version 1.0 |
Beide können nebeneinander stehen. Ein Agent, der in der agents.json ein passendes Werkzeug findet, ruft es direkt auf. Einer, der eine Aufgabe übergeben, Rückfragen bekommen und ein Gespräch fortsetzen will, nimmt A2A. Wie agents.json im Einzelnen funktioniert, steht in unserer Erklärung zu agents.json.
A2A und MCP teilen sich die Arbeit#
A2A fällt oft im selben Atemzug wie MCP, und die naheliegende Frage ist, ob das eine das andere ersetzt. Tut es nicht. Die Agentic AI Foundation, unter deren Dach inzwischen beide liegen, beschreibt sie als zwei Ebenen. MCP verbindet einen Agenten mit Werkzeugen, Daten und Anwendungen. A2A verbindet Agenten untereinander, über Firmen- und Plattformgrenzen hinweg.
Für einen Betrieb heißt das: zwei verschiedene Türen. Über MCP werden sein Wissen und seine Aktionen in einem Assistenten nutzbar, etwa wenn jemand Claude nach Öffnungszeiten oder freien Terminen fragt. Über A2A kann ein anderer Agent ihm eine Aufgabe übergeben, nachfragen und ein Ergebnis bekommen.
Ein Punkt gehört klar gesagt, weil der Name etwas anderes nahelegt: A2A ist keine direkte Leitung ins Chatfenster von Claude oder ChatGPT. Es verbindet Agenten, die Firmen und Plattformen bauen. In diesen Agenten arbeitet oft ein großes Sprachmodell. Untereinander sprechen sie A2A.
Ein Durchgang durch unseren eigenen Agenten#
Unsere Website trägt eine Agent Card, und der Agent dahinter antwortet unter derselben Adresse in 1.0 und in 0.3. Die Karte ist signiert, der Schlüssel zum Prüfen liegt unter /.well-known/jwks.json. Das macht sie zu einem brauchbaren Beispiel, denn jeder Schritt unten lässt sich am echten Agenten ausprobieren.
Angenommen, jemand sagt seinem Assistenten: Such mir ein Webdesign-Studio auf Mallorca und frag nach einem Kennenlerngespräch. Der Agent ruft https://studiomeyer.io/.well-known/agent-card.json ab und findet dort die Adresse unseres Agenten und, neben anderen Skills, diesen (gekürzt):
{
"name": "StudioMeyer",
"supportedInterfaces": [
{
"url": "https://studiomeyer.io/api/a2a",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"skills": [
{
"id": "schedule-consultation",
"name": "Request a free intro call",
"description": "Sends a request for a free intro call to StudioMeyer. Needs name and email, optionally phone and topic, as a data part. Someone from StudioMeyer answers by email, written by a person and not by a machine; nothing is booked automatically. Select it with message.metadata.skillId = \"schedule-consultation\" or with a data part {\"skill\": \"schedule-consultation\"}.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
}
]
}
Der Agent wählt den Skill und schickt die erste Nachricht. Er gibt einen Namen und ein Thema mit, vergisst aber die E-Mail-Adresse:
curl -s https://studiomeyer.io/api/a2a \
-H "Content-Type: application/json" \
-H "A2A-Version: 1.0" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "SendMessage",
"params": {
"message": {
"messageId": "msg-001",
"role": "ROLE_USER",
"parts": [
{
"data": {
"skill": "schedule-consultation",
"name": "Jane Doe",
"topic": "Neue Website für ein Restaurant"
}
}
]
}
}
}'
Die Antwort ist eine Aufgabe, die anhält und nachfragt (gekürzt):
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"task": {
"id": "task_0f953c4c-…",
"contextId": "ctx_bbf6ab0b-…",
"status": {
"state": "TASK_STATE_INPUT_REQUIRED",
"message": {
"messageId": "msg_989db7b4-…",
"role": "ROLE_AGENT",
"parts": [
{
"text": "To request a free intro call, send a data part with name and email, optionally phone and topic: {\"skill\": \"schedule-consultation\", \"name\": \"...\", \"email\": \"...\", \"topic\": \"...\"}"
}
]
}
}
}
}
}
Der Agent fängt nicht von vorn an. Er antwortet in derselben Aufgabe, mit taskId und contextId aus der Antwort, und schickt alle Angaben noch einmal:
{
"jsonrpc": "2.0",
"id": 2,
"method": "SendMessage",
"params": {
"message": {
"messageId": "msg-002",
"role": "ROLE_USER",
"taskId": "task_0f953c4c-…",
"contextId": "ctx_bbf6ab0b-…",
"parts": [
{
"data": {
"name": "Jane Doe",
"email": "jane@example.com",
"topic": "Neue Website für ein Restaurant"
}
}
]
}
}
}
In diesem Beispiel lautet die Adresse jane@example.com, und unser Agent fragt ein zweites Mal nach. example.com ist für Beispiele reserviert und empfängt nie Post, beim Ausprobieren geht also weder eine Mail raus noch eine Anfrage ein. Mit einer echten Adresse endet die Aufgabe als TASK_STATE_COMPLETED, die Anfrage landet bei StudioMeyer, und ein Mensch antwortet per E-Mail. Diese Antwort schreibt keine Maschine, und automatisch gebucht wird nichts. Genau das steht auch in der Beschreibung des Skills. Das ist Absicht. Ein Agent sollte nur versprechen, was hinter ihm wirklich passiert.
Freier Text geht auch. Eine Nachricht mit einem Textteil landet bei unserem Assistenten, der auf Deutsch, Englisch oder Spanisch antwortet. Wer die contextId mit der nächsten Nachricht mitschickt, setzt dasselbe Gespräch fort, solange es noch offen ist. Die ganze Schnittstelle ist auf unserer Entwicklerseite für Agenten beschrieben.
Eine Aufgabe weiß immer, wo sie steht#
A2A gibt jeder Aufgabe einen klaren Zustand. In Version 1.0 heißen die Zustände so:
TASK_STATE_SUBMITTED → TASK_STATE_WORKING → TASK_STATE_COMPLETED
→ TASK_STATE_FAILED
→ TASK_STATE_CANCELED
→ TASK_STATE_REJECTED
→ TASK_STATE_INPUT_REQUIRED
→ TASK_STATE_AUTH_REQUIRED
Completed, failed, canceled und rejected sind endgültig. Rejected heißt, der Agent hat entschieden, die Aufgabe nicht auszuführen, gleich zu Beginn oder später. Input required und auth required unterbrechen nur: Die Aufgabe wartet auf weitere Angaben oder auf eine Anmeldung und läuft dann unter derselben ID weiter.
Input required ist genau das, was in unserem Beispiel passiert ist. Es ist der Moment, in dem sich ein Agent verhält wie ein guter Mensch am Telefon. Er legt nicht auf, er fragt nach, was fehlt.
Reichweite und Vertrauen sind noch offen#
Die Unterstützung, die das A2A-Projekt meldet, kommt von Cloud-Plattformen, Unternehmenssoftware und Frameworks für Agenten. Auf den Websites kleiner Betriebe ist eine Agent Card, soweit ich das sehe, noch selten. Wer heute eine veröffentlicht, ist früh dran, nicht spät.
Vertrauen ist der zweite offene Punkt. Eine signierte Karte beweist, dass sie unverändert ist und von dem Anbieter stammt, den sie nennt. Sie beweist nicht, dass der Agent dahinter ehrlich ist oder tut, was er behauptet. Welche Agenten man hereinlässt und was man sie tun lässt, bleibt eine Entscheidung jedes Betreibers, mit den üblichen Mitteln des Webs: Anmeldung, Grenzen und einem Blick in die Logs.
Und Agenten machen weiter Fehler, wenn sie Anfragen ausfüllen, auch strukturierte. Ein guter Agent auf der anderen Seite fängt das auf. Er fragt nach, statt still zu scheitern. Den Zustand dafür bringt das Protokoll mit. Ihn zu nutzen liegt bei dem, der den Agenten baut.
Eine Karte ist ein Versprechen#
Ein Agent, der eine Karte liest, glaubt ihr. Er schickt seine Anfragen so, wie die Karte es beschreibt, und er berichtet seinem Menschen, was die Karte behauptet hat. Eine Karte mit Skills, die dahinter niemand ausführt, ist schlimmer als gar keine, weil sie Fehler dort erzeugt, wo niemand hinsieht.
Auf eine Karte gehört deshalb nur, was wirklich antwortet. Für uns heißt das: Jeder Skill in der Karte ist ausführbar, und ein klarer Satz sagt, wo die Maschine aufhört und ein Mensch übernimmt. Das Protokoll ist stabil. Was in der Karte steht, bleibt eine Entscheidung.
