Was haben A2A Extensions am 9. September veröffentlicht? Erweiterungsmechanismus und JSON-Protokoll (2026)

Kurzüberblick

Aspekt	Inhalt
Offizielle Veröffentlichung	2025-09-09 Google Developers Blog «A2A Extensions: Empowering Custom Agent Functionality»
Kernstück	Optionale Protokollerweiterungen mit URI: neue Daten, neue Einschränkungen, neue RPC, neue Zustandsautomaten
JSON-Träger	capabilities.extensions[] der Agent Card
Aushandlung	HTTP-Kopf A2A-Extensions, standardmäßig inaktiv
Rolle 2026	A2A steuert die Interoperabilität der Agents; Extensions die Fachanpassung; kein Ersatz für MCP oder Function Calling

Was erschien am 9. September?

A2A (Agent2Agent) legt bereits fest, wie Agents einander finden, Aufgaben senden und Ergebnisse stromweise zurückgeben. Das Kernprotokoll muss jedoch allgemein bleiben — Sprachlatenz, Ende-zu-Ende-Nachverfolgung oder Zero-Trust-Handschlag gehören nicht in den Kern. Am 9. September 2025 gaben Google-Ingenieure im offiziellen Blog die Antwort: Extensions.

An jenem Tag kam nicht eine einzelne neue RPC, sondern ein vollständiger offener Erweiterungsmechanismus:

• Jede Person kann eine Erweiterung definieren, veröffentlichen und umsetzen, gekennzeichnet durch eine eindeutige URI (mit Versionsnummer, etwa https://example.com/ext/my-extension/v1).
• Der Agent erklärt in der Agent Card (einem JSON, das Fähigkeiten beschreibt), welche Erweiterungen er unterstützt.
• Der Client aktiviert sie bei Bedarf über einen HTTP-Kopf auf einer einzelnen Anfrage; Clients ohne diese Erklärung bleiben beim Kernprotokoll und werden nicht gestört.
• Zugleich gab es ein Einstiegsbeispiel: Zeitstempel in metadata von Message und Artifact.

2026 steht die Regelung im Themenbeitrag A2A Extensions; es gibt ein Governance-Rahmenwerk (offizielle Erweiterungen nutzen das Präfix https://a2a-protocol.org/extensions/). Im Folgenden zerlegen wir den Mechanismus anhand des JSON-Protokolls.

A2A-Protokoll und Agent Card JSON

Die Agent Card ist die maschinenlesbare Visitenkarte eines Agents: Name, Beschreibung, Einstiegs-URL, Ein- und Ausgabe-MIME, Fertigkeitenliste sowie capabilities. Extensions hängen an capabilities, nicht an einer zweiten Datei.

Eine Agent Card mit Erweiterung sieht etwa so aus (Aufbau nach dem offiziellen Beispiel, Feldnamen gemäß geltender Spezifikation):

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

Beim Prüfen dieses JSON zuerst mit dem JSONSort-Formatierer Klammern und Kommas sichern, dann am Schema kontrollieren, ob in extensions[] Felder fehlen. Die Agent Card liegt öffentlich im Netz — Geheimnisse gehören nicht in params.

Erweiterungsmechanismus: erklären, standardmäßig aus, je Anfrage aktivieren

Ziel der Extensions ist es, A2A zu erweitern, ohne den Kernstandard zu zerreißen. Die Spezifikation zieht klare Grenzen:

1. Standardmäßig inaktiv. Clients, die eine Erweiterung nicht kennen, rufen weiter die Kernmethoden auf und erhalten die Grundfunktion.
2. Der Client entscheidet sich ausdrücklich. Im HTTP-Request steht A2A-Extensions; der Wert ist eine kommagetrennte URI-Liste.
3. Der Agent ignoriert unbekannte URI und wiederholt im Antwortkopf die tatsächlich aktivierten Erweiterungen.
4. required: true ist eine harte Abhängigkeit. Aktiviert oder befolgt der Client sie nicht, soll der Agent die Anfrage ablehnen. Erweiterungen nur zur Datendarstellung nicht als required markieren.

Eine Erweiterung darf von anderen abhängen (verpflichtend oder wahlfrei). Die Spezifikation verlangt, Abhängigkeiten in der Erweiterungsbeschreibung festzuhalten; beim Aktivieren sendet der Client die abhängigen URI mit. Die Versionsnummer gehört in die URI: ein Bruch der Kompatibilität erfordert eine neue URI. Der Agent darf nicht stillschweigend auf eine andere Version zurückfallen.

Felder von AgentExtension JSON

Die Spezifikation zieht eine rote Linie, damit Erweiterungen die Typprüfung des Kerns nicht zerstören: Definierte Datenstrukturen weder um Pflichtfelder erweitern noch Felder streichen — eigene Eigenschaften gehören in die vorhandene Map metadata; Aufzählungen nicht um neue Werte ergänzen, zusätzliche Semantik ebenfalls in metadata. Diese beiden Regeln bestimmen die Form des JSON.

Anfrage-Aushandlung: HTTP-Kopf und JSON-RPC-Nachricht

Die Aktivierung gilt für jede einzelne HTTP-Anfrage, nicht dauerhaft nach dem Verbindungsaufbau. Typische Anfrage (im Stil des offiziellen Einstiegsbeispiels):

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

Die passende Antwort wiederholt die erfolgreich aktivierte Erweiterung:

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

Der Schlüssel in params.metadata ist die Erweiterungs-URI plus Pfadsuffix, kein frei erfundener Kurzname. So können mehrere Erweiterungen dieselbe JSON-RPC-Nachricht füllen, ohne sich die Namen zu stehlen. Bleibt eine Erweiterung wirkungslos, zuerst prüfen, ob der Anfragekopf die URI trägt, dann Anfrage- und Antwort-JSON vergleichen — der JSON-Diff eignet sich, um metadata vor und nach der Aktivierung gegenüberzustellen.

Vier Erweiterungstypen: Daten, Profile, Methoden, Zustandsautomat

Die Spezifikation lässt bewusst offen, was eine Erweiterung tun darf. Die 2026 absehbaren Nutzungen lassen sich in vier Typen fassen:

• Daten (Data-only): Nur zusätzliche strukturierte Angaben in der Agent Card, ohne den Anfrage-Antwort-Ablauf zu ändern. Beispiel: Felder zur DSGVO-Konformität. Solche Erweiterungen nicht mit required: true markieren.
• Profile: Strengere Struktur- oder Zustandsregeln über die Kernnachrichten legen — ein Profil über A2A. Beispiel: alle parts müssen ein DataPart nach einem bestimmten Schema sein; oder bei TaskStatus.state === "working" über metadata["generating-image"] einen Unterzustand anzeigen.
• Methoden (Extended Skills): RPC außerhalb der Kernmenge. Die Erweiterung task-history ergänzt etwa tasks/search und gibt dem Agent die Fertigkeit, historische Aufgaben zu durchsuchen.
• Zustandsautomat: Zusätzliche Zustände oder Übergänge der Aufgabenmaschine. Hier ist die rote Linie am leichtesten zu überschreiten: neue Semantik gehört in metadata, nicht in die Kernaufzählung.

Praxisbeispiele vom Veröffentlichungstag

Der Google-Beitrag blieb nicht bei der Abstraktion: Er nannte Erweiterungen, die bereits liefen, und zeigt, welches JSON sie tragen.

Traceability (Nachvollziehbarkeit): Die Kernnachricht ist ResponseTrace — ein strukturiertes Protokoll unabhängig vom Hauptprotokoll, das die Schritte des Agents festhält. Jeder Step ist entweder ToolInvocation (Aufruf eines Werkzeugs oder einer API) oder AgentInvocation (Aufruf eines weiteren Agents). Schritte dürfen verschachtelt sein: Unterstützt der nachgelagerte Agent dieselbe Erweiterung, hängt dessen Trace am übergeordneten Schritt und bildet einen Ende-zu-Ende-Aufrufbaum. Das ist unverzichtbar, um die Zusammenarbeit mehrerer Agents zu bewerten und Fehler zu finden — gehört aber nicht in den A2A-Kern.

Twilio Latency Extension: Sprach-Agents (ConversationRelay) müssen Latenz bekanntgeben, um das passende nachgelagerte Modell zu wählen oder elegant zurückzufallen. Latenz ist kein Kernfeld der Agent Card; Twilio ergänzt sie per Erweiterung — das Musterbeispiel dafür, dass Fachdaten den Kern nicht belasten dürfen.

Identity Machines: Erweiterungen für den Zero-Trust-Handschlag zwischen Agents. Vor der Aufgabenübergabe prüft ein Richtlinienfilter Zweck, Budget, Fähigkeiten, Modell, PII-Status und weitere eigene Bedingungen. Das JSON trägt hier Richtlinienkontext, keinen Chattext.

Der Beitrag nennt außerdem die Richtung ERC-8004 von Ethereum: On-Chain-Register für Identität, Ruf und Prüfung als Vertrauensschicht zwischen Organisationsgrenzen. Das muss nicht als A2A Extension erscheinen, zeigt aber dieselbe Trennung — das Kernprotokoll regelt «wie man spricht», Erweiterungen und Fremdnormen regeln «weshalb man vertraut».

Wie stehen MCP und Function Calling dazu?

Alle drei erzeugen JSON, liegen aber auf unterschiedlichen Ebenen und sollen sich 2026 nicht ersetzen:

Die übliche Architektur ist gestuft: Ein MCP-Server liefert Werkzeuge → der Wirt bildet sie auf Function Calling des Modells ab → mehrere Agents verteilen Aufgaben per A2A und tragen mit Extensions Nachverfolgung, Latenz und Identität über Agent-Grenzen. Den JSON-Vergleich der ersten beiden Ebenen behandelt der vorherige Beitrag MCP Tool Schema vs Function Calling.

Erweiterungsdaten mit JSON Schema binden

Eine Erweiterungsbeschreibung sollte mindestens enthalten: URI-Liste, Schema von params, zusätzliche Datenstrukturen zwischen Client und Agent, neue Anfrage-Antwort-Abläufe. In der Praxis:

• Für AgentExtension.params und für metadata-Schlüssel je ein JSON Schema pflegen.
• In der CI Beispielnutzlasten prüfen; die Agent Card als öffentlichen API-Vertrag behandeln.
• Alle erweiterungsbezogenen Eingaben als unvertraut behandeln: zuerst zerlegen, dann prüfen.

Zur Schreibweise von JSON Schema siehe das vollständige JSON-Schema-Tutorial auf dieser Seite. Formatieren, Syntaxprüfung und Versionsvergleich erledigt JSONSort lokal — eine Card mit Richtlinien- oder Identitätsdaten muss nicht auf fremde Seiten.

Typische Fehler

• Eine Extension als Freibrief für beliebige Felder verstehen. Die Kernstruktur bleibt unangetastet; neue Daten gehören in metadata.
• Daten-Erweiterungen als required markieren. Das weist unnötig viele Clients ab.
• URI ohne Version. Bei einem Bruch der Kompatibilität fehlt der Ausweg, die Aushandlung gerät durcheinander.
• Bei Versionskonflikt auf die alte Umsetzung zurückfallen. Die Spezifikation verlangt, die Aktivierung zu ignorieren — nicht stillschweigend zu verträglich machen.
• Neue RPC an der bestehenden Authentifizierung vorbei führen. Erweiterungsmethoden unterliegen derselben Anmeldung und Berechtigung wie Kernmethoden.
• Mit der MCP-Werkzeugliste vermengen. MCP beantwortet «welche Werkzeuge gibt es»; eine A2A Extension beantwortet «wie sprechen zwei Agents nach Fachregeln».

Häufige Fragen (FAQ)

Sind A2A Extensions am 9. September 2026 erschienen?

Der offizielle Blogbeitrag trägt das Datum 9. September 2025. 2026 suchen viele weiter unter diesem Datum nach «was erschien»; der Mechanismus steht in der geltenden A2A-Spezifikation und wächst um Governance und Beispielerweiterungen (Traceability, Timestamp, Secure Passport und andere).

Muss man Erweiterungen umsetzen, um A2A zu nutzen?

Nein. Erweiterungen sind standardmäßig aus. Nur wenn die Agent Card der Gegenstelle eine Erweiterung als required markiert, muss sie nach Spezifikation aktiviert und eingehalten werden.

Gehört das Erweiterungs-JSON in den Nachrichtenkörper oder in den HTTP-Kopf?

Die Aktivierungsliste steht im Kopf A2A-Extensions; fachliche Daten der Erweiterung liegen in JSON-RPC params.metadata (oder an einer anderen, von der Spezifikation genannten Stelle). Der Kopf handelt aus, das JSON trägt die Nutzlast.

Wie prüft man Agent Card und Erweiterungs-metadata?

Lokal mit JSONSort die Card formatieren, am Schema prüfen und zwei Versionen des Feldes extensions vergleichen. JSON mit Identität oder Richtlinien nicht in Online-Werkzeuge einfügen.

Fazit

Am 9. September erschien keine weitere herstellereigene API, sondern die offene Erweiterungsschicht von A2A: Fähigkeiten per URI benennen, in der Agent Card JSON erklären, je Anfrage mit A2A-Extensions aktivieren, Fachdaten in metadata tragen. Beim Bau von Systemen mit mehreren Agents 2026 gilt: Kerndialog über A2A, Werkzeugangebot über MCP, Modellabsicht über Function Calling, senkrechte Anforderungen über Extensions — jede Schicht eine Aufgabe, JSON Schema als einzige Quelle der Wahrheit für Parameter und Erweiterungsdaten.

Weiterführende Lektüre

• Google: Blogbeitrag zu A2A Extensions Originaltext und Beispiele vom 2025-09-09
• Themenbeitrag zur Spezifikation A2A Extensions Erklärung, Aktivierung, Governance und Grenzen
• MCP Tool Schema vs Function Calling JSON-Vergleich auf der Werkzeugebene
• Lokaler JSON-Werkzeugkasten von JSONSort Formatieren, Syntaxprüfung, Diff

Änderungsprotokoll: 2026-08-28 Erstveröffentlichung