Wie findet ein AI-Agent einen anderen Agenten? Agent Registry, A2A Agent Card und JSON Capability Discovery

Discovery ist kein Protokoll. Gefunden wird die Card

A2A standardisiert eine Selbstbeschreibung, kein Telefonbuch. Der entfernte Agent schreibt Fähigkeiten als JSON-Visitenkarte. Der Client entscheidet damit Passung, Verbindung und welchen Task er schickt. Die Methode folgt der Umgebung: öffentliches Netz, Unternehmenskatalog, fest verdrahtete URL auf dem Laptop. Alle drei können auf derselben Card landen. Wer „Discovery“ ein weiteres Gesprächsprotokoll nennt, läuft in der Review zuerst schief. Das Protokoll bleibt A2A. Was wechselt, ist die Tür zu well-known oder zum Katalog.

Die offizielle Discovery-Seite spricht unter „Role of the Agent Card“ noch im 0.3-Ton von einer Top-Level-url. Neue Karten folgen 1.0: der Endpoint sitzt in supportedInterfaces. Siehe was in v1.0 neu ist. Liest ein Hop noch das alte Feld, ist das nicht der 1.0-Hauptvertrag. Wie die Felder geschrieben werden, steht im vorigen Text. Heute nur: welcher Hop hat die Karte in die Hand gelegt, und welche Schlüssel prüft ihr zuerst.

Ein Fund ist keine Lizenz für tools/call. Gegenüber bleibt ein undurchsichtiger Agent. Ihr wählt ein Skill, wählt ein Interface und sendet einen Task. Wer einen Suchtreffer als Funktionstabelle behandelt, sprengt in mehreren Klärungsrunden die arguments. Wie ein MCP-Hop Parameter prüft, steht im Schema-Text auf der Site. Heute endet es bei „wen haben wir gefunden, und warum glauben wir, dass er das erledigt“.

Drei offizielle Strategien: Straße wählen, dann gehen

Well-known passt zu einem öffentlichen Agenten oder zu Discovery, wenn ihr den Hostnamen beherrscht. Der Pfad folgt RFC 8615: https://{agent-server-domain}/.well-known/agent-card.json. Der Client kennt die Domain oder kann sie ableiten, schickt HTTP GET und bekommt JSON. Die Umsetzung ist einfach und gut zu automatisieren. Stehen sensible Skills oder eine interne URL auf der Karte, muss dieser GET selbst authentifiziert sein. Einen Intranet-Endpoint hängt ihr nicht nackt ins offene Netz.

Ein kuratierter Katalog passt zu Unternehmen oder Marktplatz: ein Mitteldienst sammelt Cards, Clients fragen nach skills, tags, provider oder capabilities, der Katalog liefert passende Karten oder Zeiger. Ihr gewinnt Steuerung und Suche nach Fähigkeit. Ihr müsst den Katalog auch betreiben. A2A legt diese API nicht fest. Google Agent Registry, ein Community-Registry und ein eigener Katalog erfinden jeweils ihre Abfrageform. Validiert nicht drei Anbieter gegen ein „universelles discover-JSON“.

Direkte Konfiguration passt zu enger Kopplung, privatem Agenten, Laptop. Die Card-URL lebt in einer Umgebungsvariable, einer Datei oder einer proprietären API. Ist die Beziehung statisch, ist das der billigste Weg. Bewegt sich die Card, müssen alle Clients mit. In Produktion die „Laptop-Verdrahtung“ als einzige Discovery-Fläche zu behandeln, ist ein Adressbuch von 2025. Die drei Wege können nebeneinander liegen: der Katalog findet wen, well-known liest die Karte auch wenn der Katalog tot ist, die Config sät ein, zwei stabile Hosts beim Start.

Hostname vorhanden: GET well-known

Der sauberste Hop hat drei Schritte. (1) Eine Domain bekommen, etwa returns.agents.example.com. (2) GET https://returns.agents.example.com/.well-known/agent-card.json. (3) Die Antwort ist eine Card, die das 1.0-Schema besteht. Falscher Pfad, interner Alias statt HTTP, Zertifikats-Hostname passt nicht — der Störungsschein schreibt „Discovery fehlgeschlagen“. Die Card kann in Ordnung sein. Der GET ist nie angekommen.

Die Spezifikation will Cache-Header am Card-Endpoint. Cache-Control: max-age=… hält Zwischenstationen und Clients davon ab, jedes Mal die volle Karte zu holen. ETag darf die version oder ein Inhaltshash sein. Nach Ablauf erst eine bedingte Anfrage (If-None-Match), kein bedingungsloser GET. Schickt der Server keine Header, darf der Client ein kurzes Default setzen — aber keine Karte ewig cachen, deren skills sich ändern können.

Eine öffentliche Karte braucht nur genug, damit ein Orchestrator wählen kann. Sensible Skills und ein zweiter interner Endpoint gehören auf eine authentifizierte erweiterte Karte. Die zweite Kopie holt ihr nur, wenn capabilities.extendedAgentCard wahr ist. Ein Discovery-Hop darf vor der Auth keine erweiterte Karte unterstellen. Ein Katalog, der je Identität andere Cards liefert, und eine well-known-Karte, die für alle gleich ist, sind zwei Offenlegungen. In der Review zwei Sätze.

Katalog vorhanden: tags suchen, dann die Card holen

Ohne Hostname, nur mit dem Satz „finde jemanden, der Retouren klassifiziert“, geht ihr durch einen kuratierten Katalog. Die Abfrage frisst skills[].tags und Skill-Namen auf der Card — nicht die Topologie auf den Folien. Orchestratoren im Google-Projekt, Gemini Enterprise und Agent Gateway suchen registrierte Einträge über Skill-Schlüsselwörter. Das ist Produktverhalten, kein A2A-Standard-RPC. Community und andere Clouds haben jeweils ihre eigene Suche. Ein Review-Fixture soll „Abfrage → Trefferliste → jede Zeile hat cardUrl oder eingebettete Card“ behaupten. Einen Anbieterpfad hebt ihr nicht zur Spezifikation.

Liefert der Katalog einen Zeiger, ist der nächste Hop weiter well-known oder die Card-URL, die der Katalog gab. Liefert er eine eingebettete Card, prüft ihr sie trotzdem gegen das 1.0-Schema: erfolgreiche Registrierung ist kein legales Feldset. Ein NO_SPEC-Eintrag mit Host und ohne skills hat eine leere Suchfläche — das stand in #5. Heute nur die Erinnerung: ein Keyword-Hop auf einem leeren Index ist kein kaputtes Protokoll.

Ein toter Katalog beendet Discovery nicht von selbst. Habt ihr schon einen Hostnamen, soll der Client weiter well-known GETten. Den Katalog als einzige Wahrheit zu behandeln, macht die Discovery-Fläche zum Single Point. Ein, zwei stabile Hosts in der Saat-Config lassen, Keyword-Suche wieder aufnehmen wenn der Katalog zurück ist — das liegt näher an den drei koexistierenden Strategien der Spezifikation als „Katalog 500, wir stehen“.

Nach dem Treffer: skills abgleichen, Interface wählen, Task senden

Ein Suchtreffer heißt nur „vielleicht der“. Der Orchestrator geht trotzdem skills[] durch: ist id die Art Arbeit, die ihr delegieren wollt, treffen tags wirklich die Query, akzeptiert ihr die Grenze in description? Wickelt ein Skill nicht in ein MCP-inputSchema. Die Hinweise von 1.0 sind examples und MIME. Falsches Skill, dann Task: der Fehler sitzt in der Delegation, nicht in der Discovery — aber das Fixture muss „Treffer ≠ Auswahl“ in zwei Schritten schreiben.

Nach der Auswahl supportedInterfaces lesen. Der erste Eintrag ist bevorzugt. Der Client wählt ein Binding, das er spricht: JSONRPC, GRPC, HTTP+JSON. Kein gemeinsames Binding heißt: Discovery geklappt, Gespräch gescheitert. Eine 0.3-Top-Level-url ist nicht der 1.0-Hauptendpoint. Auch die Fähigkeitsflags: ist streaming falsch und ihr abonniert trotzdem einen Stream, will die Spezifikation einen Capability-Fehler, keinen stillen Fallback auf unary.

Das JSON darunter ist ein Ablauf-Fixture, keine offizielle Katalog-API eines Anbieters. Es faltet Query, Treffer und bevorzugtes Interface in ein Objekt, damit ihr es neben der Card im Repo diffen könnt. Das nächste Verb ist message/send. Checklisten zur Validierung und Signaturen bleiben für später.

{
  "kind": "discovery-trace",
  "note": "CI/review fixture — not an official A2A or Google Registry API",
  "query": {
    "tags": ["returns", "classify"]
  },
  "strategy": "curated-registry",
  "hits": [
    {
      "name": "Returns Specialist",
      "cardUrl": "https://returns.agents.example.com/.well-known/agent-card.json",
      "matchedTags": ["returns", "classify"],
      "skillId": "classify-return"
    }
  ],
  "selected": {
    "skillId": "classify-return",
    "preferredInterface": {
      "url": "https://agents.example.com/returns/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    },
    "next": "message/send"
  }
}

Cache, veraltete Indizes, Fixtures

Cards bewegen sich selten: ein Skill dazu, Auth geändert. Die Discovery-Fläche wird trotzdem alt. Der Katalogindex hinkt, well-known liefert schon eine neue version, die Suche zeigt noch auf alte tags. Mindestens zwei Fixtures: Snapshot des Katalogtreffers und die gerade geholte Card. Passen Keywords nicht, zuerst tags und Indexlag prüfen, dann erst einen 1.0-Client verdächtigen, der eine 0.3-Karte gelesen hat.

{
  "hop": "well-known",
  "method": "GET",
  "url": "https://returns.agents.example.com/.well-known/agent-card.json",
  "requestHeaders": {
    "If-None-Match": "1.0.3"
  },
  "response": {
    "status": 304,
    "etag": "1.0.3",
    "cacheControl": "max-age=3600"
  }
}

Die Spezifikation ist klar: sensible Daten brauchen Auth. Dynamische Credentials außerhalb der Karte, keine statischen Geheimnisse in der Card. Ein Discovery-Fixture mit Token oder Intranetpasswort fällt in der Review sofort durch. Die öffentliche Karte so schreiben, als würde sie abgeholt. Cache für die erweiterte Karte folgt der Sitzung. Nicht in denselben Eimer wie das max-age der öffentlichen Karte.

Auch ein Plugin-SKILL.md oder MCP-tools/list ist keine Discovery-Quelle. Wie ein Coding-Agent im selben Repo Skills wachsen lässt, ist die Box. Wie der Retouren-Agent eines anderen Teams gefunden wird, ist die Card. Beides in eine capability.json pressen, und drei gescheiterte Hops landen in derselben Ticketzeile.

Im Browser fertig: JSON formatieren, ob Ablauf-Fixture und Card parsen; JSON-Schema prüfen für die 1.0-Card nach dem Treffer; JSON Diff, Katalog-Snapshot gegen die gerade geholte Card, tags- und Interface-Drift fangen. Daten bleiben auf diesem Rechner. Weiterlesen: das Agent-Card-Feldtutorial und der Registry-Überblick. Signaturen und die Validierungscheckliste sind der nächste Praxistext.

Verwandt: A2A Agent Card JSON Schema, Google Agent Registry, A2A vs MCP.

FAQ

Fazit und nächste Schritte

2026 lässt sich „automatisch einen anderen Agenten finden“ auf drei Hops falten: Strategie wählen, Card holen, an skills und Interfaces entscheiden ob delegiert wird. Ein Katalog ist eine Tür, nicht das Protokoll.

Lieferreihenfolge: öffentlichen Agenten zuerst korrekt an well-known hängen; braucht ihr Keyword-Suche, einen Anbieterkatalog anschließen und das eigene Query-Fixture mitbringen; nach dem Treffer die 1.0-Card prüfen, dann Task senden. Felder schreiben: voriger Text. Was ein Katalog ist: #5. Validierung und Signaturen später. Ablauf-JSON und Repo-Card in JSONVue gegeneinander halten.