A2A Protocol erklärt: So spricht deine Website mit ChatGPT, Perplexity + Claude

Matthias Meyer

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:

Herausfindet, was eine Website kann (Discovery)
Aufgaben sendet (Task Execution)
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:

{
  "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:

{
  "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:

{
  "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:

{
  "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#

Der Agent hat die Fähigkeiten der Website gelesen (Discovery)
Er hat eine strukturierte Anfrage gesendet (Task)
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.