Bayer lance un moteur multi-agents sur AgentCore : 80% des questions sans ingénieur

Bayer Crop Science a présenté à quoi ressemble une couche agentique de niveau industriel au-dessus d'une plateforme de ML d'entreprise. Le système Agentic Decision Engine (ADE) répond aux questions des sélectionneurs, des analystes et des data engineers sur les workflows, les modèles et leurs résultats. Dans sa première phase, il traite environ 80% des demandes sans ingénieur. Le diagnostic d'une panne, qui demandait auparavant plus d'une heure de recherche manuelle dans les logs et d'attente d'une aide, prend désormais moins de 10 minutes. Sous le capot : 22 agents spécialisés sur Amazon Bedrock AgentCore.

Pourquoi une couche d'agents au-dessus de la plateforme

Bayer a d'abord construit Connected Decision Engine (CDE), un système de déploiement, d'orchestration, de supervision et de réutilisation des workflows de ML. En sélection végétale, les données sont hétérogènes : génomique, essais en champ, images, conditions environnementales, sorties de modèles. Des centaines de configurations tournent par culture, par région et par équipe, et chaque exécution doit être reproductible et contrôlable.

Avec la montée en charge, le goulot d'étranglement n'est plus l'exécution, mais la compréhension. Pour expliquer un résultat, il fallait rassembler du contexte depuis des API, de la documentation, des stocks de métadonnées, des dashboards et des logs. L'utilisateur devait savoir dans quel système chercher. L'ADE supprime cette contrainte : le superviseur classe la question et la transmet à un spécialiste, qui va chercher le contexte dans le bon système.

Architecture et cinq décisions à retenir

Le frontend est en React, et les requêtes passent par un proxy d'identité Microsoft Entra ID. GitHub Actions construit les images des agents, les dépose dans Amazon ECR et les déploie dans AgentCore Runtime. L'orchestration repose sur LangGraph, choisi pour son graphe de contrôle explicite et ses checkpoints adaptés aux scénarios en plusieurs étapes. Les données sont réparties selon leur fonction :

• Amazon DynamoDB — checkpoints LangGraph ;
• Amazon Aurora PostgreSQL — sessions, retours utilisateurs, analytique ;
• Amazon ElastiCache — cache des réponses des agents avec TTL ;
• Amazon S3 + Titan Text Embeddings V2 + OpenSearch Serverless — RAG sur le contenu métier ;
• Amazon CloudWatch — télémétrie du runtime et de l'application ;
• AgentCore Gateway — API backend exposées comme outils MCP, authentification et autorisation hors du code des agents.

Parmi les 22 agents : Domain Expert (questions conceptuelles via RAG), Operational Agent (statut en direct et résultats issus de la CDE), Troubleshooting Agent (analyse de la télémétrie), Visualization Agent (graphiques ou dashboards prêts à l'emploi). Le modèle Models as Skill transforme le code et la documentation d'un modèle en descriptions de skills dans un registre central. L'agent répond ainsi d'après l'implémentation réelle, et non à partir de connaissances générales.

Cinq décisions de conception ont été prises avec le responsable technique de compte (technical account manager) et l'ingénieur en IA générative d'AWS Unified Operations :

• État hors du runtime. La session AgentCore conserve le contexte le temps de sa durée de vie, mais ce n'est pas un stockage fiable. Les checkpoints partent dans DynamoDB, afin que le graphe reprenne après un scaling ou un redémarrage.
• Un mécanisme distinct à chaque frontière de confiance. Entra ID porte l'identité de l'utilisateur, IAM les appels entre services, l'autorisation sortante de Gateway l'accès à la CDE, et un intercepteur Lambda vérifie et transmet les attributs. Aucun jeton unique ne traverse toutes les frontières.
• Le modèle comme contrat d'interface. La nouvelle version avec mode reasoning n'était pas compatible avec le tool use ni avec la sortie structurée dans l'implémentation des agents ; l'équipe est restée sur le modèle actuel.
• Contrôle du jeu d'outils. Avec plus de 500 configurations, un serveur MCP distinct par API aurait multiplié les déploiements et les versions. À la place, les spécifications OpenAPI sont enregistrées dans Gateway et les outils sont attribués agent par agent. Chaque description consomme des tokens d'entrée.
• De l'outil à l'agent. La visualisation a pris de l'ampleur : elle a eu besoin de sa propre recherche de données, de sa logique de choix du graphique, de ses retries et d'une décision entre construire un diagramme ou renvoyer un dashboard existant. Elle a été transformée en agent, avec matplotlib et Plotly dans AgentCore Code Interpreter (échange de données via S3), tandis que les assets prêts à l'emploi sont renvoyés depuis Amazon Quick ou Power BI.

Observabilité, coût et mise en production

Le principal piège des systèmes multi-agents : la requête HTTP réussit, mais la réponse est fausse. Dans l'ADE, les gestionnaires d'exceptions interceptaient les erreurs des agents et renvoyaient des réponses que la supervision comptait comme réussies. L'équipe a ajouté ses propres métriques CloudWatch dans les chemins d'échec, ainsi que des alertes sur les erreurs d'appel d'outils, le throttling, les timeouts des modèles et les échecs de validation de la sortie structurée.

Le coût est attribué selon trois mécanismes : les application inference profiles de Bedrock, les métadonnées de requêtes avec journalisation des appels de modèles, et l'attribution par principal IAM. Ce sont les agents Visualization et Operational, avec leurs nombreux appels d'outils MCP, qui consomment le plus de tokens. La télémétrie a mis au jour une charge avec un long préfixe répétitif, sans cache de prompt. La mise en cache des instructions stables et des descriptions d'outils a réduit de 20–30% le coût des tokens d'entrée.

La sécurité repose sur le principe du moindre privilège : Troubleshooting Agent lit les données opérationnelles mais ne modifie pas les workflows, et Domain Expert n'appelle aucune API CDE extérieure à son périmètre. L'accès aux outils est en lecture seule, la sortie est validée, et les réponses s'appuient sur les données de la CDE et sur la télémétrie. Bayer prévoit d'évaluer Amazon Bedrock Guardrails comme couche supplémentaire. Avant le lancement, AWS a mené une Critical Workload Review et une Well-Architected review avec le Generative AI Lens ; parmi les constats figuraient des lacunes de visibilité sur les échecs entre le superviseur et les spécialistes.

Le bilan pratique pour ceux qui construisent un système similaire : stocker l'état hors de la session, définir issuer, audience et scopes à chaque transition d'identité, limiter le catalogue d'outils par agent, mesurer le succès de la tâche et non celui du transport, et se pencher d'emblée sur la mise en cache du préfixe. Ce sont ces points qui ont donné à Bayer à la fois des économies et de la maîtrise.