AWS soutient la découverte de ressources agentiques comme couche de fédération pour le registre d’agents

Amazon Web Services a mis son poids derrière la spécification Agentic Resource Discovery, publiant le 24 août 2026 un compte rendu détaillé sur la façon dont la norme ouverte est censée fonctionner aux côtés d’AWS Agent Registry, son catalogue géré pour les agents d’IA, les outils et les compétences qui est entré en aperçu plus tôt cette année.

Le billet d’AWS présente ARD comme la réponse à un problème laissé ouvert par le propre produit d’AWS. AWS Agent Registry, disponible via Amazon Bedrock AgentCore, offre à une organisation un catalogue centralisé et interrogeable d’agents, de serveurs MCP, d’outils, de compétences d’agents et de ressources personnalisées, mais uniquement au sein de son propre environnement AWS. La plupart des entreprises déploient des agents sur plusieurs clouds, infrastructures sur site et plateformes SaaS, chacune disposant de son propre registre et format de métadonnées, et relier ces environnements aujourd’hui implique de créer des connecteurs sur mesure entre chaque paire de registres.

ARD propose l’alternative au format partagé: si chaque registre décrit les ressources de la même manière et expose la découverte via un protocole commun, les éditeurs décrivent leurs ressources une seule fois et les consommateurs les découvrent partout.

À l’intérieur du modèle AWS Agent Registry

Le registre, actuellement en aperçu via Amazon Bedrock AgentCore, repose sur deux concepts: les registres, qui sont des catalogues qu’un administrateur crée avec ses propres paramètres d’autorisation et d’approbation, et les enregistrements, les entrées de métadonnées décrivant chaque ressource. Le flux de publication passe de l’administrateur à l’éditeur, au conservateur, puis au consommateur, avec une porte d’approbation avant que tout enregistrement ne devienne découvrable. L’accès est contrôlé via les identifiants AWS Identity and Access Management ou les JSON Web Tokens d’un fournisseur d’identité d’entreprise, et le registre lui‑même est exposé comme un point de terminaison MCP distant, de sorte que tout client compatible MCP puisse le rechercher directement.

Cette couche de gouvernance est la partie que AWS veille à préserver. Dans le billet, AWS décrit ARD comme une couche d’interopérabilité placée en dehors du point d’application: l’organisation qui publie un catalogue contrôle ce qu’il contient, qui peut le voir et quand révoquer l’accès, les contrôles d’approbation et d’accès existants d’Agent Registry restant là où la politique est réellement appliquée. Le libellé est délibéré: ARD gère la découverte des éléments, pas leur mise en production.

Ce que la spécification ARD standardise réellement

ARD n’est pas un projet AWS. La spécification a été annoncée le 17 juin 2026 par un groupe de travail dont les participants comprennent Google, Microsoft, Hugging Face et GoDaddy, avec Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow et Snowflake parmi les collaborateurs du lancement. Elle est sous licence Apache 2.0 et publiée sur agenticresourcediscovery.org, avec des implémentations de référence sur GitHub. AWS a apporté des commentaires pendant le développement plutôt que de rédiger la spécification.

Selon l’annonce de Google, l’architecture repose sur deux primitives. Un catalogue est un fichier qu’une organisation publie sous son propre domaine (un ai-catalog.json à un chemin bien connu) décrivant ses agents disponibles, serveurs MCP, agents A2A, outils OpenAPI ou catalogues imbriqués, la propriété du domaine servant de base cryptographique à l’identité de l’éditeur. Les registres fonctionnent comme des moteurs de recherche sur ces catalogues: ils parcourent, indexent et répondent à des requêtes de découverte en langage naturel, renvoyant les correspondances ainsi que les métadonnées de confiance vérifiables dont un client a besoin pour confirmer l’identité d’un éditeur avant de se connecter.

La frontière que trace ARD est la découverte, pas l’exécution. Un client qui trouve une ressource via ARD l’invoque via le mécanisme que cette ressource utilise nativement: MCP, une API, un cadre d’agent. Le site de la spécification indique explicitement qu’ARD n’est pas un runtime, pas un remplacement de MCP ou du protocole A2A, et n’est pas un catalogue central; le design suppose de nombreux services de découverte, chacun appliquant ses propres politiques de confiance et de classement. L’analogie d’AWS est le DNS: les registres locaux se fédèrent via le protocole partagé sans accords bilatéraux ni connecteurs propriétaires, de la même manière que la résolution de noms fonctionne à travers les réseaux.

Comment les éléments s’assemblent

Pour les clients d’Agent Registry, le discours est la fédération sans migration. Une organisation disposant d’une infrastructure agentique répartie sur plusieurs clouds, systèmes sur site et outils SaaS pourrait exposer le tout au format ARD et le rendre découvrable à travers les environnements tout en conservant le contrôle local, et publier un catalogue sur son propre domaine pour qu’il soit découvert par tout client compatible ARD, ouvrant des voies inter‑organisationnelles qu’un registre à fournisseur unique ne peut atteindre.

AWS arrive également avec un produit en main alors que d’autres sont encore en cours de construction. Le registre d’agents de Google, faisant partie de sa Gemini Enterprise Agent Platform, devrait ajouter une prise en charge native d’ARD dans les mois à venir; GitHub et Hugging Face figurent parmi les participants du groupe de travail à l’origine de la spécification. Le schéma commun aux trois clouds est le même: un registre géré et gouverné à l’intérieur, un protocole de fédération ouvert à l’extérieur.

La mise en garde est que l’intégration décrite dans le billet d’AWS est directionnelle, pas encore livrée. AWS indique ce qu’il attend d’ARD pour les clients d’Agent Registry plutôt que d’annoncer une date de livraison, et le registre lui‑même reste en aperçu. Ce que le 24 août 2026 établit, c’est un alignement: le plus grand fournisseur de cloud a nommé la spécification ouverte avec laquelle il prévoit de se fédérer, et il s’agit de la même que celle vers laquelle Google et Microsoft travaillent.