Découvrir des outils à l'exécution avec AWS Agent Registry
Face à des catalogues d'outils qui gonflent, AWS propose de ne plus câbler les capacités d'un agent au moment de la compilation, mais de les découvrir à l'exécution grâce à AWS Agent Registry. Ce service managé référence les serveurs MCP (Model Context Protocol), les agents et les compétences d'agents. Les éditeurs y enregistrent des descripteurs propres à chaque protocole et des descriptions interrogeables. Un exemple en Python illustre une boucle « Discover, Instantiate, Execute ». Il déploie un serveur MCP de gestion de commandes via Amazon Bedrock AgentCore Gateway, deux agents A2A (agent-à-agent) sur AgentCore Runtime, un registre et un orchestrateur sans connaissance préalable des outils. Lors de la découverte, l'orchestrateur envoie une requête en langage naturel au plan de données du registre. La réponse contient l'identité de l'enregistrement, son nom, sa description, son type, son statut, sa version et les descripteurs (métadonnées du serveur MCP ou carte d'agent A2A), mais aucun identifiant d'invocation. Pour chaque résultat, l'orchestrateur construit ensuite un client adapté. Pour le serveur MCP, le descripteur pointe vers le point d'accès de la Gateway, et un jeton OAuth Cognito est obtenu séparément pour créer le MCPClient. Pour les agents A2A, la carte d'agent indique l'URL d'un point d'accès AgentCore Runtime, appelé via le client boto3 qui signe la requête avec les identifiants AWS de l'appelant. Enfin, un agent interne éphémère est construit avec les seuls outils découverts, le modèle choisit les plus pertinents et la réponse est synthétisée. L'agent et ses clients sont détruits après le tour, et la requête suivante déclenche une nouvelle recherche.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est très concret pour les entreprises. Des outils codés en dur fonctionnent pour une poignée de cas, se dégradent à quelques dizaines et deviennent ingérables au-delà. Or les systèmes d'entreprise exposent des centaines d'API internes (tarification, support, commandes, stocks, données clients). Le modèle peut alors consommer davantage de jetons à distinguer des noms d'outils qu'à raisonner sur la demande de l'utilisateur. Chaque nouvelle capacité exige aujourd'hui une modification du code de l'orchestrateur, un redéploiement et une publication coordonnée entre des équipes qui préféreraient livrer à leur propre rythme. Avec le registre, une nouvelle intégration devient utilisable après son enregistrement et son approbation, sans toucher à l'orchestrateur. La séparation entre découverte et authentification constitue aussi un point de sécurité notable : le registre fournit uniquement des métadonnées de connexion, et l'application doit obtenir ses identifiants par un chemin de configuration distinct et fiable.
Ce schéma apparaît dans de nombreux projets de logiciels en mode SaaS d'entreprise, où des équipes exposent de vastes surfaces d'API à des consommateurs agentiques. Le câblage à la compilation devient alors un goulet d'étranglement à mesure que le catalogue s'étend. Le modèle d'architecture décrit s'appuie sur plusieurs briques de l'écosystème Amazon Bedrock AgentCore : un orchestrateur unique tourne sur AgentCore Runtime, interroge le registre, appelle les serveurs MCP via la Gateway et les agents A2A directement sur leur runtime. L'approche suppose toutefois une gouvernance du catalogue, puisque seuls les enregistrements approuvés et découvrables sont renvoyés, et une gestion rigoureuse des identifiants en dehors du registre. Le dépôt d'exemple contient le script de déploiement, l'orchestrateur, les modules utilitaires et le script de nettoyage.
Pas d'impact direct sur la France/UE