--- title: "A2A Protocol erklärt: So sprechen KI-Agenten mit deiner Website" description: "Was A2A ist, wie es funktioniert und wie deine Website eine Schnittstelle anbietet, die ein KI-Agent abrufen kann. JSON-RPC 2.0, agent-card.json, Code-Beispiel." author: "Matthias Meyer" published: 2026-02-15 updated: 2026-09-30 updates: - date: 2026-09-30 note: "A2A-Signaturen präzisiert: Integrität und Anbieteridentität brauchen unterschiedliche Nachweise." - date: 2026-09-22 note: "Auf A2A 1.0 gebracht: der Status als stabiler Standard seit März 2026 und unter dem Dach der Agentic AI Foundation seit August 2026, die Methodennamen von 1.0 (SendMessage, GetTask, ListTasks, CancelTask), der Kopf A2A-Version, die Agent Card mit supportedInterfaces und Signaturen und die Zustände mit ihren TASK_STATE-Namen. Das Beispiel läuft jetzt Schritt für Schritt gegen unseren echten Agenten, dazu kommt ein Abschnitt zu A2A und MCP." language: de tags: ["a2a", "protocol", "agent-card", "json-rpc", "ki-agenten", "api"] canonical: "https://studiomeyer.io/de/blog/a2a-protocol-explained" markdown_versions: ["https://studiomeyer.io/de/blog/a2a-protocol-explained.md", "https://studiomeyer.io/en/blog/a2a-protocol-explained.md", "https://studiomeyer.io/es/blog/a2a-protocol-explained.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # A2A Protocol erklärt: So sprechen KI-Agenten mit deiner Website 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](https://a2a-protocol.org/latest/specification/) 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: ```json { "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 die Integrität der Karte prüfen kann. Die Anbieteridentität folgt daraus nur, wenn der Schlüssel vertrauenswürdig dem Anbieter zugeordnet wurde. 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](https://studiomeyer.io/de/blog/agents-json-explained). ## 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): ```json { "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: ```bash 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): ```json { "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: ```json { "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](https://studiomeyer.io/de/docs/developer/agents) 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 gültige Signatur belegt, dass die Karte unverändert ist und zum verwendeten Schlüssel gehört. Die Identität des Anbieters ist erst belegt, wenn dieser Schlüssel vertrauenswürdig dem Anbieter zugeordnet wurde. 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. ## Weiterlesen, WebMCP + Agenten-Protokolle - [agents.json erklärt: ein eigenes Manifest für Website-Tools](https://studiomeyer.io/de/blog/agents-json-explained.md) - [WebMCP Reality Check: Wo der Spec wirklich steht](https://studiomeyer.io/de/blog/webmcp-reality-check-may-2026.md) - [WebMCP: Das neue Web-Protokoll für KI-Agents](https://studiomeyer.io/de/blog/webmcp-w3c-standard.md)