A2A Protocol: Wie Websites direkt mit KI-Agenten sprechen

Stellen Sie sich vor, Sie rufen bei einem Unternehmen an. Sie sagen, was Sie brauchen. Die Person am anderen Ende versteht Sie, prueft die Verfuegbarkeit und gibt Ihnen eine klare Antwort. Kein Durchklicken durch Menues, 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 fuer Agent-to-Agent Protocol. Google hat es im April 2025 vorgestellt und anschliessend an die Linux Foundation uebergeben, wo es von ueber 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 Unterstuetzung, aber noch frueh in der Adoption. Wir verwenden es, weil das zugrundeliegende Konzept solide ist -- nicht weil es bereits ueberall funktioniert.

Die Kernidee

Das Web hat ein Problem: KI-Agenten koennen Websites besuchen, den Text lesen und Links folgen. Aber sie koennen nicht handeln -- keinen Termin buchen, kein Angebot anfragen, keine Reservierung machen. Zumindest nicht zuverlaessig und strukturiert.

A2A loest 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 empfaengt (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:

Daneben gibt es weitere Operationen fuer Streaming (tasks/sendSubscribe), Push-Benachrichtigungen und Konfiguration -- insgesamt 11 definierte Methoden. Die Transportschicht unterstuetzt JSON-RPC 2.0 ueber HTTP, gRPC und HTTP/REST-Bindings.

Die agent-card.json: Visitenkarte fuer KI-Agenten

Bevor ein Agent kommunizieren kann, muss er wissen, mit wem er spricht und was moeglich ist. Dafuer gibt es die agent-card.json -- eine Datei unter /.well-known/agent-card.json, die alle Faehigkeiten 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 fuer 4 Personen am Freitag um 19 Uhr",
        "Gibt es noch freie Plaetze fuer 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

• Identitaet: Wer ist dieser Agent? Name, URL, Anbieter
• Protocol-Version: Welche A2A-Version wird unterstuetzt
• Input/Output-Modi: Welche Formate akzeptiert und liefert der Agent (Text, JSON, Bilder, etc.)
• Capabilities: Kann der Agent streamen? Push-Benachrichtigungen senden?
• Skills: Konkrete Faehigkeiten mit Beschreibung, Tags und Beispielen

Die Skills sind das Kernstack. Ein KI-Agent liest die agent-card.json, versteht die verfuegbaren Faehigkeiten 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:

In der Praxis ergaenzen sich beide: Ein Agent findet ueber agents.json heraus, welche Services es gibt. Ueber 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 Beratungsgespraech fuer naechste 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 moechte ein Beratungsgespraech buchen. Name: Max Mustermann, Email: max@example.com, Thema: Neue Website fuer 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

1. Der Agent hat die Faehigkeiten der Website gelesen (Discovery)
2. Er hat eine strukturierte Anfrage gesendet (Task)
3. Er hat eine maschinenlesbare Antwort empfangen (Result)

Kein Formular ausgefuellt. Kein HTML geparst. Kein Raten, ob der "Submit"-Button funktioniert.

Task-Lifecycle: Nicht alles ist sofort fertig

A2A definiert einen klaren Lebenszyklus fuer 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 wuerde: "Fuer welches Datum moechten Sie reservieren?"

Was A2A heute kann -- und was nicht

Was funktioniert

• Die Spezifikation ist solide. JSON-RPC 2.0 als Basis ist bewaehrt und leichtgewichtig.
• Das Konzept ist klar. Discovery, Task-Execution, Response -- ein logischer Dreiklang.
• Starke Unterstuetzung. 150+ Organisationen in der Linux Foundation, darunter Google, Salesforce, SAP.
• SDK verfuegbar. @a2a-js/sdk fuer 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 standardmaessig fuer Web-Interaktionen.
• Tooling. Debugging-Tools, Monitoring, Logging fuer A2A-Kommunikation sind noch rudimentaer.
• 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 fuer Suchmaschinen zu nutzbar fuer KI-Agenten. Die Frage ist nicht ob, sondern wann. A2A ist der bisher konkreteste Vorschlag dafuer, wie diese Kommunikation aussehen soll.

Fuer unsere Kunden bedeutet das: Wenn A2A oder ein aehnliches 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 ueberschaubar -- eine JSON-Datei und saubere API-Endpoints. Das Risiko, dass es sich nicht durchsetzt, ist gering im Verhaeltnis zum Vorteil, wenn es sich durchsetzt.

Zusammenfassung

A2A ist kein Hype, den man ignorieren kann, und kein Standard, den man sofort braucht. Es ist ein konkreter Vorschlag fuer ein reales Problem -- und der bisher ueberzeugendste Ansatz, wie Websites und KI-Agenten in Zukunft miteinander sprechen werden.