--- title: "A2A Protocol erklärt: So spricht deine Website mit ChatGPT, Perplexity + Claude" 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-02-15 outdated: true outdated_since: 2026-07-27 outdated_note: "Dieser Beitrag beschreibt den Stand vom Februar 2026. A2A ist inzwischen als Version 1.0 final. Damit sind hier drei Dinge überholt: der Status als Protokoll in aktiver Entwicklung, die Versionsangabe 0.3.0 RC1, und die Methodennamen: statt tasks/send, tasks/get und tasks/cancel heißen sie in 1.0 SendMessage, GetTask und CancelTask. Die Erklärung, wie A2A funktioniert, gilt weiterhin." superseded_by: "https://studiomeyer.io/de/docs/developer/agents" 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 spricht deine Website mit ChatGPT, Perplexity + Claude > **Ueberholter Stand (2026-07-27).** Dieser Beitrag beschreibt den Stand vom Februar 2026. A2A ist inzwischen als Version 1.0 final. Damit sind hier drei Dinge überholt: der Status als Protokoll in aktiver Entwicklung, die Versionsangabe 0.3.0 RC1, und die Methodennamen: statt tasks/send, tasks/get und tasks/cancel heißen sie in 1.0 SendMessage, GetTask und CancelTask. Die Erklärung, wie A2A funktioniert, gilt weiterhin. Aktueller Stand: https://studiomeyer.io/de/docs/developer/agents Stellen Sie sich vor, Sie rufen bei einem Unternehmen an. Sie sagen, was Sie brauchen. Die Person am anderen Ende versteht Sie, prüft die Verfügbarkeit und gibt Ihnen eine klare Antwort. Kein Durchklicken durch Menüs, kein Raten, kein Interpretieren von HTML. Genau das ist die Idee hinter dem A2A Protocol -- nur dass hier kein Mensch anruft, sondern ein KI-Agent. Und das "Unternehmen" ist eine Website mit strukturierter API. ## Was ist das A2A Protocol? A2A steht für **Agent-to-Agent Protocol**. Google hat es im April 2025 vorgestellt und anschließend an die Linux Foundation übergeben, wo es von über 150 Organisationen weiterentwickelt wird. Stand Februar 2026 befindet sich die Spezifikation in Version 0.3.0 (Release Candidate 1). **Wichtig vorab:** A2A ist kein finaler, breit adoptierter Standard. Es ist ein Protokoll in aktiver Entwicklung mit starker Unterstützung, aber noch früh in der Adoption. Wir verwenden es, weil das zugrundeliegende Konzept solide ist -- nicht weil es bereits überall funktioniert. ### Die Kernidee Das Web hat ein Problem: KI-Agenten können Websites besuchen, den Text lesen und Links folgen. Aber sie können nicht *handeln* -- keinen Termin buchen, kein Angebot anfragen, keine Reservierung machen. Zumindest nicht zuverlässig und strukturiert. A2A löst das mit einem standardisierten Kommunikationsprotokoll. Es definiert, wie ein KI-Agent: 1. **Herausfindet**, was eine Website kann (Discovery) 2. **Aufgaben sendet** (Task Execution) 3. **Ergebnisse empfängt** (Response) ## Die technische Basis: JSON-RPC 2.0 A2A baut auf JSON-RPC 2.0 auf -- einem etablierten, leichtgewichtigen Remote-Procedure-Call-Standard. Das ist kein experimentelles Format, sondern wird seit Jahren in der Software-Entwicklung eingesetzt. Die drei wichtigsten Operationen: | Operation | Zweck | |-----------|-------| | `tasks/send` | Eine Aufgabe an den Agent senden | | `tasks/get` | Status einer laufenden Aufgabe abfragen | | `tasks/cancel` | Eine laufende Aufgabe abbrechen | Daneben gibt es weitere Operationen für Streaming (`tasks/sendSubscribe`), Push-Benachrichtigungen und Konfiguration -- insgesamt 11 definierte Methoden. Die Transportschicht unterstützt JSON-RPC 2.0 über HTTP, gRPC und HTTP/REST-Bindings. ## Die agent-card.json: Visitenkarte für KI-Agenten Bevor ein Agent kommunizieren kann, muss er wissen, *mit wem* er spricht und *was möglich ist*. Dafür gibt es die `agent-card.json` -- eine Datei unter `/.well-known/agent-card.json`, die alle Fähigkeiten einer Website deklariert. So sieht eine vereinfachte agent-card.json aus: ```json { "name": "Pizzeria Roma", "description": "Italienisches Restaurant in Muenchen", "url": "https://pizzeria-roma.de", "protocolVersion": "0.3.0", "provider": { "organization": "Pizzeria Roma", "url": "https://pizzeria-roma.de" }, "defaultInputModes": ["text/plain", "application/json"], "defaultOutputModes": ["text/plain", "application/json"], "capabilities": { "streaming": false, "pushNotifications": false }, "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", "Gibt es noch freie Plätze für heute Abend?" ] }, { "id": "view-menu", "name": "Speisekarte ansehen", "description": "Aktuelle Speisekarte mit Preisen und Allergenen", "tags": ["menu", "food", "prices"] } ] } ``` ### Was die agent-card.json definiert - **Identität:** Wer ist dieser Agent? Name, URL, Anbieter - **Protocol-Version:** Welche A2A-Version wird unterstützt - **Input/Output-Modi:** Welche Formate akzeptiert und liefert der Agent (Text, JSON, Bilder, etc.) - **Capabilities:** Kann der Agent streamen? Push-Benachrichtigungen senden? - **Skills:** Konkrete Fähigkeiten mit Beschreibung, Tags und Beispielen Die Skills sind das Kernstack. Ein KI-Agent liest die agent-card.json, versteht die verfügbaren Fähigkeiten und weiss dann, welche Aufgaben er senden kann. ## agents.json vs. agent-card.json: Was ist der Unterschied? Hier werden oft zwei Dateien verwechselt. Die Unterscheidung ist wichtig: | | agents.json | agent-card.json | |---|---|---| | **Zweck** | Discovery: *Was kann diese Website?* | Kommunikation: *Wie spreche ich mit ihr?* | | **Analogie** | Gelbe Seiten (Services auflisten) | Telefonnummer + Anleitung (anrufen und bestellen) | | **Inhalt** | Tools mit HTTP-Endpoints, Methoden, Parametern | Skills mit I/O-Modi, Capabilities, Protocol-Version | | **Protokoll** | Kein eigenes Protokoll, beschreibt REST-Endpoints | A2A Protocol (JSON-RPC 2.0) | | **Herkunft** | Community-Proposal (Wildcard AI / nicepkg) | Google → Linux Foundation | | **Standard-Status** | Kein offizieller Standard | Aktive Spezifikation (v0.3.0 RC1) | In der Praxis ergänzen sich beide: Ein Agent findet über `agents.json` heraus, welche Services es gibt. Über `agent-card.json` und das A2A Protocol kommuniziert er dann strukturiert mit diesen Services. ## Konkretes Beispiel: Ein Agent bucht einen Beratungstermin Nehmen wir an, jemand sagt zu seinem KI-Assistenten: *"Finde mir eine Webdesign-Agentur und buche ein Beratungsgespräch für nächste Woche."* ### Schritt 1: Discovery Der Agent ruft `https://studiomeyer.io/.well-known/agent-card.json` ab und findet den Skill `schedule-consultation`: ```json { "id": "schedule-consultation", "name": "Schedule Consultation", "description": "Book a free consultation call to discuss your web project.", "tags": ["booking", "consultation", "meeting"], "inputModes": ["text/plain", "application/json"], "outputModes": ["application/json"], "examples": [ "I'd like a consultation about a new website", "Can I schedule a call to discuss a redesign?" ] } ``` ### Schritt 2: Task senden Der Agent sendet einen JSON-RPC Request: ```json { "jsonrpc": "2.0", "method": "tasks/send", "id": "req-001", "params": { "id": "task-abc-123", "message": { "role": "user", "parts": [ { "type": "text", "text": "Ich möchte ein Beratungsgespraech buchen. Name: Max Mustermann, Email: max@example.com, Thema: Neue Website für mein Restaurant" } ] } } } ``` ### Schritt 3: Response empfangen Die Website verarbeitet die Anfrage und antwortet: ```json { "jsonrpc": "2.0", "id": "req-001", "result": { "id": "task-abc-123", "status": { "state": "completed" }, "artifacts": [ { "parts": [ { "type": "text", "text": "Beratungsgespraech erfolgreich gebucht. Max Mustermann erhaelt eine Bestaetigungsmail an max@example.com. Thema: Neue Restaurant-Website." } ] } ] } } ``` ### Was hier passiert ist 1. Der Agent hat die Fähigkeiten der Website *gelesen* (Discovery) 2. Er hat eine strukturierte Anfrage *gesendet* (Task) 3. Er hat eine maschinenlesbare Antwort *empfangen* (Result) Kein Formular ausgefüllt. Kein HTML geparst. Kein Raten, ob der "Submit"-Button funktioniert. ## Task-Lifecycle: Nicht alles ist sofort fertig A2A definiert einen klaren Lebenszyklus für Tasks: ``` submitted → working → completed → failed → canceled → input-required ``` Der Status `input-required` ist besonders interessant: Wenn der Agent nicht genug Informationen geliefert hat, kann die Website nachfragen -- genau wie ein Mensch am Telefon sagen würde: "Für welches Datum möchten Sie reservieren?" ## Was A2A heute kann -- und was nicht ### Was funktioniert - **Die Spezifikation ist solide.** JSON-RPC 2.0 als Basis ist bewährt und leichtgewichtig. - **Das Konzept ist klar.** Discovery, Task-Execution, Response -- ein logischer Dreiklang. - **Starke Unterstützung.** 150+ Organisationen in der Linux Foundation, darunter Google, Salesforce, SAP. - **SDK verfügbar.** `@a2a-js/sdk` für JavaScript/TypeScript existiert. ### Was noch fehlt - **Breite Adoption.** Stand Februar 2026 implementieren wenige Websites A2A aktiv. Die meisten KI-Agenten (ChatGPT, Claude, Gemini) nutzen es noch nicht standardmäßig für Web-Interaktionen. - **Tooling.** Debugging-Tools, Monitoring, Logging für A2A-Kommunikation sind noch rudimentär. - **Auth-Standard.** A2A definiert keine eigene Authentifizierung. Wie sich Agents identifizieren und autorisieren, ist noch offen. ## Warum wir A2A trotzdem einbauen Die ehrliche Antwort: Weil die Richtung stimmt. Das Web entwickelt sich von *lesbar für Suchmaschinen* zu *nutzbar für KI-Agenten*. Die Frage ist nicht ob, sondern wann. A2A ist der bisher konkreteste Vorschlag dafür, wie diese Kommunikation aussehen soll. Für unsere Kunden bedeutet das: Wenn A2A oder ein ähnliches Protokoll zum Standard wird, sind ihre Websites vorbereitet. Die agent-card.json ist geschrieben, die API-Endpoints existieren, die Validierung ist implementiert. Der Aufwand ist überschaubar -- eine JSON-Datei und saubere API-Endpoints. Das Risiko, dass es sich nicht durchsetzt, ist gering im Verhältnis zum Vorteil, wenn es sich durchsetzt. ## Zusammenfassung | Aspekt | Detail | |--------|--------| | **Was ist A2A?** | Protokoll für strukturierte Kommunikation zwischen KI-Agenten und Websites | | **Wer steht dahinter?** | Google → Linux Foundation, 150+ Organisationen | | **Technische Basis** | JSON-RPC 2.0, agent-card.json für Discovery | | **Status** | v0.3.0 RC1, aktive Entwicklung, frühe Adoption | | **Kernkonzept** | Discovery (agent-card.json) → Task (tasks/send) → Result | | **Unterschied zu agents.json** | agents.json = Was gibt es? A2A = Wie kommuniziere ich damit? | A2A ist kein Hype, den man ignorieren kann, und kein Standard, den man sofort braucht. Es ist ein konkreter Vorschlag für ein reales Problem -- und der bisher überzeugendste Ansatz, wie Websites und KI-Agenten in Zukunft miteinander sprechen werden. ## Weiterlesen, Agent-Protokolle (A2A) - [agents.json erklärt: Mache deine Website lesbar für ChatGPT (mit Code)](https://studiomeyer.io/de/blog/agents-json-explained.md) - [Das Agentic Web: Die nächste Evolution des Internets](https://studiomeyer.io/de/blog/agentic-web-zukunft.md) - [Agent-to-Agent: Wenn KI-Systeme miteinander sprechen](https://studiomeyer.io/de/blog/agent-to-agent-kommunikation.md)