Créer des systèmes multi-agents modulaires et interopérables avec A2A sur AWS
Les agents d'un système multi-agents qui traverse les frontières entre organisations doivent pouvoir se découvrir, communiquer et s'échanger des tâches sans exposer leurs mécanismes internes ni imposer le même framework de part et d'autre. AWS décrit une architecture de référence déployée qui répond à ce besoin avec le protocole Agent-to-Agent (A2A). Un orchestrateur d'entreprise reposant sur LangChain dialogue avec un agent SaaS conçu avec Strands Agents, chacun hébergé dans un compte AWS distinct, l'un pour l'entreprise et l'autre pour l'éditeur. Chaque compte dispose de son propre groupe d'utilisateurs Amazon Cognito. Lors de l'intégration, les deux parties n'échangent que des valeurs publiques (URL des fournisseurs d'identité, identifiants clients, périmètres d'accès, adresses des points de terminaison) et chacune fait confiance aux jetons émis par l'autre, sans aucun secret partagé. Pour chaque requête, l'application obtient un jeton OAuth, interroge l'API Amazon API Gateway, qui transmet la demande via un lien VPC et un Network Load Balancer interne à l'orchestrateur. Ce dernier, lorsque son modèle juge qu'un contrôle de conformité est nécessaire, obtient son propre jeton grâce à un secret conservé dans AWS Secrets Manager, puis envoie une requête A2A à l'agent de conformité exécuté sur Amazon Bedrock AgentCore Runtime. Cet agent vérifie la fiche (Agent Card) de l'agent de contexte de l'entreprise, se procure un jeton auprès de son propre groupe, rappelle l'agent de contexte pour obtenir des métadonnées de compte, termine son analyse et renvoie la réponse.
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'intérêt est d'abord économique et technique pour les éditeurs de logiciels. Sans A2A, chaque client et chaque framework exigent du code d'intégration sur mesure. Avec le protocole, un éditeur peut proposer des agents compatibles avec les frameworks que ses clients utilisent déjà. Le schéma vaut aussi pour toute organisation qui expose des agents à des partenaires, des clients ou des équipes internes aux outils différents. L'extensibilité est un autre atout : pour ajouter une compétence, il suffit d'enregistrer une nouvelle fiche d'agent auprès de l'orchestrateur, sans modifier les agents déjà en service. Au démarrage, l'orchestrateur lit la fiche de l'agent SaaS à son adresse standard « well-known » et crée un outil LangChain pour chaque compétence décrite. Le modèle choisit ensuite l'outil à appeler selon la question posée, ce qui supprime tout routage codé en dur.
Côté entreprise, deux agents tournent sur Amazon ECS avec AWS Fargate. L'orchestrateur, point d'entrée des utilisateurs, s'appuie sur LangChain pour le cadre d'agent et l'appel d'outils, et sur Amazon Bedrock avec Anthropic Claude Sonnet 4.6 pour le raisonnement. Il transmet les demandes d'analyse de conformité par A2A avec des jetons OAuth et résume les résultats à l'intention de la direction. Cette démarche prolonge un précédent article de la série sur les protocoles ouverts d'interopérabilité des agents, qui présentait la découverte par fiche d'agent, l'exécution structurée de tâches et le modèle de serveur A2A avec deux agents Strands. Le protocole est désormais un projet de la Linux Foundation, soutenu notamment par AWS, et s'appuie sur des standards établis comme OAuth 2.0 et OpenID Connect pour la sécurité entre organisations. Le déploiement est proposé via trois notebooks Jupyter, avec un test de bout en bout.