Google Agent Registry 2026 : qu’est-ce qu’une Agent Card, et comment un agent A2A décrit capacités, tools et skills en JSON ?

A2A vs MCP a déjà séparé la délégation latérale de l’appel d’outil vers le bas. On ne rejoue pas cette phrase. La question suivante : avec des dizaines d’agents dans l’org, quelle table l’orchestrateur interroge-t-il ? La réponse Google Cloud est Agent Registry. Il mange du JSON, pas des slogans : une Agent Card conforme A2A (10 Ko max) ou un toolspec.json MCP. Les formes sont dans les schémas JSON officiels. Ici on pose « la Card est la source, le Registry est le catalogue ». Champ par champ : l’article suivant. Le parcours de découverte : celui d’après.

Un catalogue, pas un troisième protocole

Agent Registry sonne comme un nouveau protocole de conversation inventé par Google. Ce n’est pas ça. A2A dit encore comment un agent se décrit et accepte une Task. Le Registry est un catalogue de composants découvrables sur Google Cloud : les agents déjà là deviennent des ressources cherchables. Une fois enregistrés, les orchestrateurs, Gemini Enterprise et Agent Gateway du même projet les trouvent par mots-clés de skill. Le protocole reste A2A. Ce qui change, c’est qui retient la Card pour vous. Sans catalogue, vous durcissez des URL dans l’orchestrateur — carnet d’adresses 2025, pas découverte 2026.

L’enregistrement est automatique ou manuel. Agent Runtime du même projet, GKE avec le label agent IA et l’annotation Card, Cloud Run avec le type fonctionnel, et les agents Workspace / Gemini de Google peuvent entrer tout seuls. L’auto-enregistrement ne scanne que ce projet. Inter-projets, on-prem ou runtimes sans auto-découverte exigent un Service écrit à la main, qui donne un Agent en lecture seule. Un projet de gouvernance central qui doit voir les agents des spokes passe par un enregistrement manuel inter-projets, pas par un scan magique de l’org. La page Register agents a été mise à jour le 2026-09-22.

Le même catalogue accepte aussi des serveurs MCP. Le fichier s’appelle toolspec.json, formé comme une réponse tools/list, plafonné à 10 Ko aussi. Le Registry tient donc à la fois les collègues de côté et les mains vers le bas. N’écrivez pas un validateur générique pour les deux types. Comment le hop d’appel vérifie les arguments : MCP et JSON Schema. Aujourd’hui, seulement comment le catalogue s’en souvient.

Ce que vous regardez	Ce que c’est	JSON source
A2A Agent	Un pair à qui déléguer	`agent-card.json` (0.3 ou 1.0)
MCP Server	Un ensemble d’outils appelables	`toolspec.json` (`tools[]`)
NO_SPEC REST	Un endpoint, pas de skills auto	Un `Service` manuel, pas de Card

L’Agent Card : le JSON source qui se fait indexer

Une Agent Card est la carte de visite numérique du serveur A2A. Le chemin spec reste /.well-known/agent-card.json — voir quoi de neuf dans A2A v1.0. Pour une entrée conforme A2A, le Registry récupère cette carte et indexe skills pour la recherche par mots-clés. La carte elle-même doit passer le schéma A2A officiel. La forme 1.0 met les transports dans supportedInterfaces, chacun avec url, protocolBinding et protocolVersion. url et protocolVersion au sommet sont le contrat 0.3. Un client 1.0 ne doit plus les lire comme champs primaires.

L’identité humaine, c’est name, description et version — la version de l’agent, pas celle du protocole. La version de protocole voyage avec l’interface. Chaque item de skills[] veut id, name, description ; le Registry cherche dans tags. examples sont des prompts pour les humains, pas un schéma d’arguments. Le tableau des champs est pour l’article suivant. Aujourd’hui : sans Card valide, pas d’extraction auto pour le type A2A. Au-delà de 10 Ko, le Registry refuse le fichier ; l’orchestrateur ne vous trouvera jamais.

Ci-dessous une carte 1.0 commitable. Faites-la parser, puis passez le schéma officiel. Verser tout un runbook dans description heurte d’abord le plafond. La découverte, c’est un blurb court plus des tags, pas un manuel fourré dans une carte de visite.

{
  "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"]
    }
  ]
}

Après l’enregistrement : à quoi ressemble une entrée

La spec n’oblige pas Google à exporter un « snapshot de catalogue » local. La revue veut pourtant voir ce qui a été indexé. Pliez le résultat en fixture : displayName, specType (A2A_AGENT_CARD ou NO_SPEC), cardVersion, ids de skills extraits, interfaces, searchKeywords. Ce snapshot n’est pas une instance du schéma A2A — ne le validez pas avec le schéma Card. C’est une assertion CI : enregistré n’est pas cherchable.

{
  "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"
    }
  ]
}

L’extraction auto n’arrive que pour les entrées conformes A2A. Le Registry interroge /.well-known/agent-card.json et écrit les skills revendiqués dans le catalogue. Un endpoint REST NO_SPEC entre sans rien à chercher — les orchestrateurs voient qu’un agent existe, et ne matchent pas « le collègue qui interroge les factures ». Pour être cherchable, ajoutez une Card ou enregistrez des ressources skill autonomes. Gemini Enterprise peut aussi enregistrer des skills autonomes comme ressources Skill de premier niveau. C’est une autre ligne de gouvernance. Ne la fusionnez pas dans le même fichier que skills[] de la Card.

Différez le snapshot et la Card commitée. Mots-clés en désaccord : tags omis ou index en retard. URL en désaccord : vous avez enregistré un endpoint périmé. Card valide mais skillsIndexed vide : vérifiez si le Registry a lu une carte 0.3 avec les règles 1.0 — sans supportedInterfaces, l’extraction maigrit en silence, et le ticket dit encore « introuvable ».

Les skills de la Card ne sont ni des tools MCP ni des skills Plugin

Un mot, trois couches. Un skill de Card est ce que l’agent prétend traiter, pour la recherche catalogue et le choix de l’orchestrateur. Un tool MCP est un appel déterministe dont le contrat est inputSchema. Un SKILL.md Plugin / Agent Skills est un brief pour le modèle du même agent. Le Registry indexe le premier. Copier un nom de tool MCP dans Card.skills[].id peut faire matcher la recherche ; la délégation affronte encore un agent opaque, pas tools/call. Les tours de clarification et les callbacks asynchrones font éclater une forme d’appel de fonction.

Certaines implémentations de Card attachent inputSchema à un skill. C’est une forme d’indice, pas le contrat d’exécution MCP. Ne validez pas une Card avec plugin.schema.json, ni tools/call avec une Card. Trois JSON disent « capacité » ; le traitement d’échec diffère. Une Card pourrie est un échec de découverte. Un inputSchema pourri est un échec d’appel. Comment un agent de code fait pousser skills et mains : Plugin Manifest en pratique. Aujourd’hui, seulement comment un autre agent est retenu par le catalogue.

Une entrée NO_SPEC n’a pas cette revendication. Dans le catalogue, elle ressemble à une ligne d’annuaire avec un hostname. Les orchestrateurs ne la trouvent pas par mot-clé, sauf si vous enregistrez aussi des skills autonomes ou une Card. Décidez d’abord si vous devez être trouvés, ensuite si vous parlez A2A. Une Card vide « pour le catalogue » indexe un tableau de skills vide — pire que de ne pas s’enregistrer.

Ce mot	Où il est écrit	Qui le lit
A2A skill	Agent Card `skills[]`	Recherche Registry / orchestrateur
MCP tool	`tools/list` ou `toolspec.json`	Runtime `tools/call`
Agent Skill	`skills/…/SKILL.md`	Le modèle dans le même agent

0.3 contre 1.0 : ne pas mélanger les deux contrats

Le Registry accepte 0.3 et 1.0 ; les nouvelles cartes doivent être 1.0. La 1.0 a déplacé version de protocole et URL primaire dans supportedInterfaces ; extendedAgentCard est sous capabilities ; stateTransitionHistory de 0.3 n’est plus une capacité cœur. Mélanger les deux jeux de champs : chaque client lit une moitié différente ; l’index du catalogue en perd une. La liste breaking d’A2A est sur la page des changements v1.0, pas un fork privé Google.

Gardez au moins deux cartes en revue : la 1.0 légale ci-dessus, et un négatif qui gare url au sommet tout en s’enregistrant en 1.0. La seconde doit échouer à la validation 1.0, ou l’endpoint primaire est ignoré. Si la CI écrase les deux schémas en un « check agent générique », vous êtes plus sales que le client. Le Registry choisit les règles selon la version déclarée et ne va pas chercher un schéma au chargement — même discipline qu’un Plugin Manifest.

Signatures, cartes étendues et GetExtendedAgentCard sont la couche sécu après auth, pas la rampe d’accès au catalogue. La carte publique doit d’abord livrer des skills ; ensuite l’orchestrateur décide s’il tire une seconde copie authentifiée. Les signatures sont hors sujet aujourd’hui. Rendez d’abord les tags cherchables.

Les fixtures dans JSONVue

Au moins trois fixtures de revue : la Card 1.0 ci-dessus, le snapshot de catalogue, et un négatif 0.3/1.0 mélangé. La première doit passer le schéma A2A 1.0. La deuxième utilise votre schéma de snapshot, ou assert skillsIndexed et tags. La troisième doit échouer. Copier des champs Plugin fermés dans une Card, ou verser toute une table inputSchema MCP dans skills[], se voit tout de suite au diff.

Ajoutez un contre-fixture MCP : un toolspec.json légal, pour prouver le second fichier source du catalogue. N’y appliquez pas le schéma Card. tools[].name est pour le runtime ; skills[].tags pour la recherche. Aucun secret dans une fixture commitée. Une Card est une carte de visite publique — écrivez-la comme si elle allait être fetchée.

Dans le navigateur :Formateur JSON pour voir si Card et snapshot parsent ;Validateur JSON Schema pour 1.0 supportedInterfaces et skills ;JSON Diff pour attraper la dérive tags / URL entre Card commitée et snapshot. Rien ne quitte la machine. Pour aller plus loin :A2A vs MCP, validation MCP, et le Plugin Manifest.

Liés : A2A vs MCP, MCP et JSON Schema, Plugin Manifest en pratique.

FAQ

Avec un Registry, peut-on sauter la Card well-known ?

Non. Le Registry consomme la Card, il ne la remplace pas. L’extraction auto est un fetch de /.well-known/agent-card.json. Si le catalogue est down, un client qui a le domaine doit encore pouvoir lire la carte.

Un agent non-A2A peut-il entrer dans le Registry ?

Oui. Le type est NO_SPEC ; vous enregistrez l’endpoint à la main. Les skills ne sont pas extraits. Pour être trouvé par mot-clé, ajoutez une Card ou enregistrez des ressources Skill autonomes.

Un skill de Card égale-t-il un tool MCP ?

Non. Le premier est une revendication pour le catalogue et l’orchestrateur. Le second est un appel déterministe avec inputSchema. Un hit de recherche n’est pas un tools/call. En face, un agent opaque ; vous envoyez une Task.

10 Ko, c’est trop petit pour notre runbook. Alors ?

N’y mettez pas le runbook. Écrivez une courte description et des tags cherchables. Le texte de process reste dans les skills ou docs de l’agent. Au-dessus du plafond, le Registry refuse le fichier et la découverte tombe à zéro.

À retenir et suite

En 2026, Google Agent Registry se plie en une phrase : c’est un catalogue ; la Card est le JSON source indexé. Les orchestrateurs cherchent des tags et des noms de skill, pas la topologie de vos slides.

Ordre de livraison : une Card 1.0 légale ; vérifier specType à l’enregistrement ; assert dans le snapshot que les skills sont vraiment là ; un toolspec.json à part pour MCP. Vérifiez les trois contrats dans JSONVue. Couches : l’article A2A vs MCP. Champs : le suivant. La marche : celui d’après.