Google Agent Registry 2026: Was ist eine Agent Card, und wie beschreiben A2A-Agenten Fähigkeiten, Tools und Skills in JSON?

Ein Katalog, kein drittes Protokoll

Agent Registry klingt, als hätte Google noch ein Gesprächsprotokoll erfunden. Hat es nicht. A2A sagt weiter, wie ein Agent sich beschreibt und einen Task annimmt. Die Registry ist ein Katalog auffindbarer Komponenten auf Google Cloud: vorhandene Agenten werden suchbare Ressourcen. Nach der Registrierung finden Orchestratoren, Gemini Enterprise und Agent Gateway im selben Projekt sie über Skill-Keywords. Das Protokoll bleibt A2A. Neu ist, wer die Card für euch merkt. Ohne Katalog hartcodiert ihr URLs im Orchestrator — ein Adressbuch von 2025, keine Discovery von 2026.

Registrierung ist automatisch oder manuell. Agent Runtime im selben Projekt, GKE mit AI-Agent-Label und Card-Annotation, Cloud Run mit Funktionstyp und Googles eigene Workspace-/Gemini-Agenten können selbst in den Katalog. Automatisch gilt nur für dieses Projekt. Quer über Projekte, On-Prem oder Laufzeiten ohne Autodiscovery brauchen einen handgeschriebenen Service, daraus entsteht ein read-only Agent. Ein zentrales Governance-Projekt, das Spoke-Agenten sehen muss, registriert manuell quer, nicht per Magie-Org-Scan. Die Seite Register agents wurde am 2026-09-22 aktualisiert.

Derselbe Katalog nimmt auch MCP-Server. Die Datei heißt toolspec.json, geformt wie eine tools/list-Antwort, ebenfalls 10KB. Deshalb sitzen seitliche Kollegen und abwärts gerichtete Hände nebeneinander. Schreibt keinen generischen Validator für beide Eintragstypen. Wie der Call-Hop Argumente prüft, steht in MCP und JSON Schema. Heute nur, wie der Katalog sie merkt.

Die Agent Card: Quell-JSON, das indexiert wird

Eine Agent Card ist die digitale Visitenkarte des A2A-Servers. Der Spec-Pfad bleibt /.well-known/agent-card.json — siehe Was ist neu in A2A v1.0. Bei einem A2A-konformen Eintrag holt die Registry die Karte und indexiert skills für die Keyword-Suche. Die Karte selbst muss das offizielle A2A-Schema passieren. Die 1.0-Form legt Transporte in supportedInterfaces, je mit url, protocolBinding und protocolVersion. Top-Level-url und protocolVersion sind der 0.3-Vertrag. Ein 1.0-Client liest sie nicht als Primärfelder.

Die menschliche Identität ist name, description und version — die Version des Agenten, nicht die des Protokolls. Die Protokollversion wandert mit dem Interface. Jedes skills[]-Item braucht id, name, description; die Registry sucht in tags. examples sind Prompts für Menschen, kein Argument-Schema. Die volle Feldtabelle kommt als Nächstes. Heute: ohne gültige Card gibt es keine automatische Extraktion vom Typ A2A. Über 10KB lehnt die Registry die Datei ab; der Orchestrator findet euch nie.

Unten eine 1.0-Karte, die ins Repo darf. Erst parsen, dann das offizielle Schema. Ein ganzes Runbook in description trifft zuerst die Deckelung. Discovery ist ein kurzer Blurb plus tags, kein Handbuch in der Visitenkarte.

{
  "name": "Invoice Specialist",
  "description": "Finds and summarizes invoices for finance. Does not post payments.",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Look up invoices by week, status, or counterparty.",
      "tags": ["invoices", "finance", "search"],
      "examples": ["Find overdue invoices for last week"]
    }
  ]
}

Nach der Registrierung: so sieht ein Katalogeintrag aus

Die Spec zwingt Google nicht, einen lokalen „Katalog-Snapshot“ zu exportieren. Review will trotzdem sehen, was indexiert wurde. Faltet das Ergebnis in ein Fixture: displayName, specType (A2A_AGENT_CARD oder NO_SPEC), cardVersion, extrahierte Skill-IDs, interfaces, searchKeywords. Dieser Snapshot ist kein A2A-Schema-Instanz — nicht mit dem Card-Schema validieren. Es ist eure CI-Assertion: registriert ist nicht suchbar.

{
  "registry": "google-cloud-agent-registry",
  "displayName": "Invoice Specialist",
  "specType": "A2A_AGENT_CARD",
  "cardVersion": "1.0",
  "skillsIndexed": ["search-invoices"],
  "searchKeywords": ["invoices", "finance", "search"],
  "interfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC"
    }
  ]
}

Automatische Extraktion gilt nur für A2A-konforme Einträge. Die Registry fragt /.well-known/agent-card.json und schreibt behauptete Skills in den Katalog. Ein NO_SPEC-REST-Endpoint landet im Katalog ohne suchbare Skills — Orchestratoren sehen, dass ein Agent existiert, und matchen nicht „Kollege, der Rechnungen sucht“. Wer suchbar sein will, legt eine Card nach oder registriert eigenständige Skill-Ressourcen. Gemini Enterprise kann eigenständige Skills auch als Top-Level-Skill führen. Das ist eine andere Governance-Linie. Nicht in dieselbe Datei wie Card-skills[] mischen.

Snapshot und committete Card nebeneinander diffen. Keywords passen nicht: tags fehlen oder der Index hinkt. URLs passen nicht: ihr habt einen alten Endpoint registriert. Card gültig, skillsIndexed leer: prüfen, ob die Registry eine 0.3-Karte mit 1.0-Regeln gelesen hat — fehlt supportedInterfaces, wird die Extraktion still dünner, das Ticket sagt nur „nicht gefunden“.

Card-Skills sind weder MCP-Tools noch Plugin-Skills

Ein Wort, drei Schichten. Ein Card-Skill ist, was der Agent behauptet zu erledigen — für Katalogsuche und Orchestrator-Wahl. Ein MCP-Tool ist ein deterministischer Call, Vertrag inputSchema. Ein Plugin-/Agent-Skills-SKILL.md ist ein Brief für dasselbe Modell im selben Agenten. Die Registry indexiert das Erste. Einen MCP-Toolnamen nach Card.skills[].id kopieren kann die Suche treffen; Delegation steht trotzdem vor einem opaken Agenten, nicht vor tools/call. Mehrstufige Klärung und asynchrone Callbacks sprengen eine Funktionsaufruf-Form.

Manche Card-Implementierungen hängen inputSchema an einen Skill. Das ist eine Hinweiform, kein MCP-Ausführungsvertrag. Validiert eine Card nicht mit plugin.schema.json und tools/call nicht mit einer Card. Drei JSON-Dateien sagen „Fähigkeit“; Fehlerbehandlung unterscheidet sich. Eine kaputte Card ist Discovery-Fehler. Ein kaputtes inputSchema ist Call-Fehler. Wie ein Coding-Agent Skills und Hände wachsen lässt, steht in Plugin Manifest in der Praxis. Heute nur, wie ein anderer Agent im Katalog landet.

Ein NO_SPEC-Eintrag hat keine solche Behauptung. Im Katalog wirkt er wie eine Adresszeile mit Hostname. Orchestratoren finden ihn nicht per Keyword, außer ihr registriert eigenständige Skills oder legt eine Card nach. Entscheidet zuerst, ob ihr gefunden werden wollt, dann ob ihr A2A sprecht. Eine leere Card „für den Katalog“ indexiert ein leeres Skill-Array — schlimmer als keine Registrierung.

0.3 gegen 1.0: die zwei Verträge nicht mischen

Die Registry nimmt 0.3 und 1.0; neue Karten sollen 1.0 sein. Version 1.0 hat Protokollversion und primäre URL nach supportedInterfaces verschoben; extendedAgentCard sitzt unter capabilities; 0.3s stateTransitionHistory ist keine Kernfähigkeit mehr. Mischt ihr beide Feldsätze, liest jeder Client eine andere Hälfte; der Katalogindex verliert eine Hälfte. A2As eigene Breaking-Liste steht auf der v1.0-Änderungsseite, kein privater Google-Fork.

Lasst mindestens zwei Karten im Review: die legale 1.0 oben und ein Negativ, das url oben parkt und sich als 1.0 registriert. Die zweite muss an 1.0-Validierung scheitern oder der primäre Endpoint wird ignoriert. Wenn CI beide Schemas zu einem „generischen Agent-Check“ quetscht, seid ihr unordentlicher als der Client. Die Registry wählt Regeln nach der deklarierten Version und holt beim Laden kein Schema — dieselbe Disziplin wie ein Plugin Manifest.

Signaturen, erweiterte Karten und GetExtendedAgentCard sind die Sicherheitsschicht nach Auth, nicht die Auffahrt in den Katalog. Die öffentliche Karte muss zuerst Skills liefern; dann entscheidet ein Orchestrator, ob er eine authentifizierte Zweitkopie zieht. Signaturen liegen heute außerhalb. Macht tags zuerst suchbar.

Fixtures in JSONVue

Mindestens drei Review-Fixtures: die 1.0-Card oben, der Katalog-Snapshot und ein gemischtes 0.3/1.0-Negativ. Die erste muss das A2A-1.0-Schema passieren. Die zweite nutzt euer Snapshot-Schema oder assertet skillsIndexed und tags. Die dritte muss scheitern. Geschlossene Plugin-Felder in eine Card kopieren oder eine volle MCP-inputSchema-Tabelle in skills[] gießen sieht man im Diff sofort.

Legt ein MCP-Gegenfixture dazu: eine legale toolspec.json, als Beweis für die zweite Quelldatei im Katalog. Das Card-Schema nicht darauf laufen lassen. tools[].name gilt der Runtime; skills[].tags der Suche. Kein Secret in ein committetes Fixture. Eine Card ist eine öffentliche Visitenkarte — schreibt sie, als würde sie geholt.

Im Browser:JSON-Formatierer, ob Card und Snapshot parsen;JSON-Schema-Validator für 1.0-supportedInterfaces und skills;JSON Diff, um Tags- und URL-Drift zwischen committeter Card und Snapshot zu fangen. Nichts verlässt die Maschine. Weiterlesen:A2A vs MCP, MCP-Validierung und das Plugin Manifest.

Verwandt: A2A vs MCP, MCP und JSON Schema, Plugin Manifest in der Praxis.

FAQ

Fazit und nächste Schritte

2026 fällt Google Agent Registry auf einen Satz: Sie ist ein Katalog; die Card ist das indexierte Quell-JSON. Orchestratoren suchen tags und Skillnamen, nicht die Topologie auf euren Folien.

Reihenfolge: legale 1.0-Card; bei Registrierung specType prüfen; im Snapshot asserten, dass Skills wirklich landeten; für MCP eine eigene toolspec.json. Die drei Verträge in JSONVue prüfen. Schichten: der A2A-vs-MCP-Text. Felder: der nächste. Der Walk: der danach.