Les décisions de sélection végétale dépendent de données qui couvrent la génomique, les essais en champ, l'imagerie, les conditions environnementales et les sorties de modèles. Bayer Crop Science exécute des centaines de configurations de modèles de machine learning (ML) sur ces données à travers différentes cultures, régions et équipes, et chaque exécution doit être reproductible et gouvernée. Pour répondre à cette exigence, Bayer a construit le Connected Decision Engine (CDE), un système de déploiement, d'orchestration, de surveillance et de réutilisation des workflows ML. Le CDE offre aux sélectionneurs, analystes, chercheurs, data scientists et ingénieurs données un moyen cohérent d'exécuter des analyses tout en préservant l'historique d'exécution et les contrôles opérationnels.
À mesure que l'adoption croissait, le goulot d'étranglement est passé de l'exécution des workflows à leur compréhension. Expliquer un résultat signifiait reconstituer le contexte à partir d'API, de documentation, de magasins de métadonnées, de tableaux de bord et de journaux. Un utilisateur qui voulait savoir pourquoi un workflow avait échoué, ce que faisait un modèle ou d'où provenait un résultat devait encore savoir quel système inspecter. Pour combler ce manque, Bayer a construit l'Agentic Decision Engine (ADE), une interface multi-agents en langage naturel au-dessus du CDE. Un agent superviseur achemine chaque question vers un agent spécialiste, le spécialiste récupère le contexte du système concerné, et l'utilisateur reçoit une réponse sans avoir à naviguer dans la pile opérationnelle. Dans sa première phase, l'ADE résout environ 80 pour cent des questions des utilisateurs sans intervention d'un ingénieur.
L'ADE fonctionne sur Amazon Bedrock AgentCore, un service AWS permettant de construire, connecter et optimiser des agents à grande échelle avec n'importe quel framework ou modèle. AgentCore a permis à l'équipe de se concentrer sur le comportement des agents au lieu de construire et d'exploiter sa propre couche d'hébergement d'agents, d'isolation de sessions et d'accès aux outils. Trois capacités d'AgentCore ont motivé ce choix : un runtime managé qui isole chaque session utilisateur, un accès aux outils délimité par AWS Identity and Access Management (IAM) via AgentCore Gateway, une capacité d'Amazon Bedrock AgentCore, qui maintient l'authentification et l'autorisation en dehors du code des agents, et une conception indépendante du framework qui a permis à l'équipe d'apporter sa propre orchestration LangGraph et son choix de modèles.
Pour se préparer au lancement puis exploiter l'ADE, Bayer a fait appel à AWS Unified Operations. Cet accompagnement a fourni un Technical Account Manager (TAM) désigné et un ingénieur spécialiste de domaine en IA générative (DSE), qui ont travaillé en tant que prolongement de l'équipe ADE de la conception à la production. Le TAM, en tant que conseiller stratégique de Bayer, apportait une compréhension établie du modèle opérationnel de Bayer et de ses priorités commerciales. Le DSE apportait une expertise de domaine en IA générative sur AWS. Lors de trois standups techniques chaque semaine, l'équipe examinait et prenait les décisions de conception. Le DSE a acquis une connaissance approfondie de la charge de travail ADE et du fonctionnement de l'équipe Bayer, de sorte que les conseils techniques reflétaient à la fois le comportement des services AWS et le contexte de Bayer. Cet article retrace ce parcours : l'architecture de l'ADE, cinq décisions de conception prises pendant la construction, le travail de préparation de la plateforme pour la production, et son exploitation après le lancement.
Présentation de l'architecture
L'ADE est organisé en quatre couches : l'expérience utilisateur, l'orchestration des agents, les agents spécialistes, et les outils et sources de données que ces agents appellent (Figure 1). Les utilisateurs accèdent à l'ADE via une interface web React, et les requêtes passent par un proxy d'identité pour Microsoft Entra ID avant d'atteindre les agents. GitHub Actions construit les images de conteneurs des agents, les pousse vers Amazon Elastic Container Registry (Amazon ECR), et les déploie sur le runtime d'AgentCore, une capacité d'Amazon Bedrock AgentCore.
Le runtime Amazon Bedrock AgentCore héberge les agents, et comme le runtime est indépendant du framework, l'équipe exécute directement dessus sa propre orchestration basée sur LangGraph. L'équipe a choisi LangGraph pour son contrôle de flux explicite sous forme de graphe et sa gestion de points de contrôle pour les flux de travail multi-étapes. LangGraph orchestre le flux de travail, avec un Supervisor Agent comme point d'entrée qui classe chaque requête, sélectionne un spécialiste et combine les résultats lorsqu'une question couvre plusieurs domaines. Le plan de données est séparé par responsabilité. Amazon DynamoDB stocke l'état des points de contrôle LangGraph. Amazon Aurora PostgreSQL stocke les enregistrements de session, les retours utilisateurs et les analyses. Amazon ElastiCache met en cache les réponses des agents avec une durée de vie (TTL). Le contenu de domaine dans Amazon Simple Storage Service (Amazon S3) est vectorisé avec Amazon Titan Text Embeddings V2 et indexé dans Amazon OpenSearch Serverless pour la génération augmentée par récupération (RAG). Amazon CloudWatch capture la télémétrie du runtime et des applications. AgentCore Gateway expose les API backend aux agents sous forme d'outils Model Context Protocol (MCP) et maintient l'authentification et l'autorisation en dehors du code des agents.
Figure 1 : Architecture de l'Agentic Decision Engine sur Amazon Bedrock AgentCore
ADE exécute 22 agents spécialisés en production, chacun limité à un seul domaine avec ses propres outils et sources de données. Par exemple, le Domain Expert Agent répond aux questions conceptuelles via le RAG. L'Operational Agent récupère l'état et les résultats en direct des flux de travail depuis le CDE. Le Troubleshooting Agent analyse la télémétrie opérationnelle. Le Visualization Agent génère des graphiques ou renvoie des tableaux de bord existants. Un modèle spécifique au client, Models as Skill convertit le code et la documentation des modèles en définitions de compétences stockées dans un registre central, afin que les agents répondent aux questions spécifiques à un modèle à partir de son implémentation plutôt que de connaissances génériques sur le modèle.
Lorsqu'un sélectionneur demande : « Pourquoi mon flux de travail de phénotypage a-t-il échoué hier ? », le superviseur classe l'intention et achemine la requête vers le Troubleshooting Agent. Cet agent lit la télémétrie du flux de travail dans CloudWatch et son statut depuis l'API du CDE via AgentCore Gateway, identifie le point de défaillance et renvoie un diagnostic via le superviseur (Figure 2). Le sélectionneur ne consulte pas directement les journaux. Avec le Troubleshooting Agent, un diagnostic qui nécessitait auparavant plus d'une heure de recherche manuelle dans les journaux et d'attente du soutien d'un ingénieur prend désormais moins de 10 minutes.
Figure 2 : Flux de requête ADE : classification de l'intention, recherche en cache, routage vers le spécialiste et réponse
Cinq décisions de conception sur le chemin de la production
Le Unified Operations TAM et le DSE ont participé aux décisions suivantes en tant que membres de l'équipe de travail, et non comme point d'escalade après coup. Cela a permis à Bayer de tester chaque conception par rapport au comportement des services AWS avant de s'y engager, tout en conservant la propriété de l'architecture et la décision finale.
1. Externaliser l'état d'orchestration sans considérer le runtime comme sans état
Le runtime AgentCore fournit des sessions isolées qui préservent le contexte d'exécution entre les invocations au cours du cycle de vie d'une session. Ce contexte n'est pas un stockage durable pour un flux de travail multi-étapes. ADE écrit les points de contrôle LangGraph dans DynamoDB afin que le graphe puisse reprendre après des événements de mise à l'échelle, des redémarrages ou des limites de session sans dépendre de la disponibilité d'un environnement d'exécution unique.
Principe : Utilisez la session du runtime pour l'exécution active, et persistez l'état nécessaire pour reprendre ou reconstruire le flux de travail dans un service durable.
2. Séparer l'identité d'entreprise, l'accès à la passerelle et l'autorisation en aval
Bayer normalise sur Microsoft Entra ID pour l'identité des utilisateurs, tandis que les services d'ADE s'autorisent mutuellement avec des mécanismes natifs AWS. Plutôt que d'imposer un seul jeton à travers chaque frontière de confiance, l'équipe a donné à chaque frontière son propre mécanisme.
Entra ID demeure la source de l'identité des utilisateurs. AWS Identity and Access Management (IAM) autorise les appels de service à service. L'autorisation sortante d'AgentCore Gateway gère l'accès aux services CDE en aval. Une fonction AWS Lambda d'intercepteur de requêtes effectue une validation personnalisée et transmet les attributs d'autorisation requis par les outils en aval. L'équipe a travaillé avec le DSE sur le contrat de jeton à chaque saut.
Principe : Les échecs d'identité dans les systèmes d'agents se concentrent aux transitions entre l'identité utilisateur, l'identité de l'agent et l'identité de l'outil. Définissez l'émetteur, l'audience, les revendications, les portées et la durée de vie des informations d'identification à chaque saut au lieu de réutiliser un jeton valide pour une frontière à la suivante.
3. Considérer le choix du modèle comme un contrat d'interface
Pendant la construction, l'équipe a évalué une version plus récente du modèle avec le mode de raisonnement activé. Pour cette version, la combinaison d'utilisation d'outils et de sortie structurée dont ADE dépend n'était pas compatible avec la manière dont ses agents étaient implémentés. Le DSE a confirmé la contrainte, et l'équipe a conservé le modèle actuel pour la version.
Principe : Pour les agents utilisant des outils, le choix du modèle est contraint par l'interface complète : appel d'outils, sortie structurée, comportement de streaming, fonctionnalités de raisonnement, latence, disponibilité des quotas et sémantique des requêtes spécifique au modèle. Un modèle plus récent n'est pas automatiquement un remplacement direct.
4. Contrôler la surface d'outils avant qu'elle ne contrôle le prompt
CDE gère plus de 500 configurations de modèles. Un serveur MCP dédié par API aurait ajouté des charges de déploiement, d'authentification et de gestion des versions. ADE enregistre plutôt les spécifications OpenAPI avec AgentCore Gateway, qui expose les opérations REST comme outils MCP. Ajouter ou modifier une API devient un changement de schéma et de configuration de passerelle au lieu d'un nouveau déploiement de serveur.
Les schémas et descriptions d'outils consomment également des tokens d'entrée et entrent en concurrence avec la requête de l'utilisateur et le contexte récupéré. ADE délimite les outils par agent spécialiste au lieu de donner à chaque agent le catalogue complet. Pour les catalogues plus volumineux, AgentCore Gateway prend en charge la recherche sémantique d'outils, afin qu'un agent puisse trouver les outils pertinents sans charger tout le catalogue à chaque tour.
Principe : Délimitez le catalogue d'outils par agent. Chaque définition d'outil ajoute des tokens et élargit l'espace de décision du modèle.
5. Promouvoir les capacités complexes d'outils en agents
La visualisation a commencé comme un outil invoqué par d'autres agents. À mesure qu'elle grandissait, elle avait besoin de sa propre récupération de données, de sa logique de sélection de graphiques, de tentatives répétées, de la gestion des erreurs et d'une décision sur la question de générer un graphique ou de renvoyer un tableau de bord existant. L'équipe l'a transformée en un agent spécialiste de visualisation. L'agent génère des graphiques à la demande avec matplotlib et Plotly dans AgentCore Code Interpreter, une capacité d'Amazon Bedrock AgentCore qui fournit un environnement d'exécution de code isolé (sandbox), et échange des données avec lui via Amazon S3. Lorsqu'un tableau de bord préconstruit est la meilleure réponse, l'agent renvoie l'actif Amazon Quick ou Power BI existant.
Principe : Un outil effectue une opération délimitée. Lorsqu'une capacité commence à posséder un état, des tentatives répétées, de la planification, des politiques ou des décisions de présentation, modélisez-la comme un agent.
Préparer ADE pour la production
À mesure que le développement se rapprochait du lancement, l'attention s'est déplacée de la conception vers l'exploitabilité : détecter les défaillances d'agents, attribuer les coûts d'inférence et renforcer le déploiement.
Observabilité : Mesurer les échecs de tâches, pas seulement les exceptions
Une architecture de superviseur transforme une requête utilisateur en une chaîne d'appels de modèles, d'appels d'outils et de transferts entre agents. La réponse finale peut être erronée même lorsque chaque requête HTTP a réussi. ADE l'a constaté directement : les gestionnaires d'exceptions d'application capturaient les erreurs d'agents et renvoyaient des réponses que la surveillance comptait comme réussies. Après avoir reproduit le problème avec le DSE, l'équipe a ajouté des métriques CloudWatch personnalisées dans les chemins d'échec et des alarmes sur des conditions propres aux agents : erreurs d'appel d'outils, limitation de débit (throttling), délais d'attente de modèles et échecs de validation de sortie structurée. Les traces et les journaux d'invocation suivent chaque requête à travers le superviseur et les spécialistes.
Principe : Distinguez le succès de transport du succès de tâche. L'observabilité des agents doit montrer si la tâche s'est terminée, quel agent ou quel outil a changé le résultat, et si la réponse a utilisé la source attendue.
Attribution des coûts : Combiner l'attribution de facturation avec la télémétrie au niveau des requêtes
Une requête ADE peut invoquer plusieurs modèles et outils, de sorte que les dépenses Amazon Bedrock au niveau du compte n'expliquent pas l'économie unitaire. L'équipe a conçu l'approche d'attribution avec le DSE en utilisant trois mécanismes qui répondent à des questions différentes. Les profils d'inférence d'application d'Amazon Bedrock attribuent l'utilisation facturée des modèles à une application ou à une charge de travail. Les métadonnées de requête et la journalisation des invocations de modèles associent l'utilisation de tokens à un agent, une fonctionnalité ou une requête spécifique. L'attribution par principal IAM ajoute une dimension d'identité. Ensemble, ils permettent à l'équipe d'estimer le coût par interaction, d'identifier les agents coûteux et de déterminer si ce sont les prompts, le contexte récupéré ou les définitions d'outils qui tirent l'utilisation des tokens. En pratique, les agents de visualisation et opérationnel, qui s'appuient sur des outils MCP et de multiples appels d'outils, ont consommé le plus de tokens.
La même télémétrie a révélé une charge de travail pendant la préparation du lancement avec un grand préfixe d'entrée répété et aucune activité de cache de prompt. Pour les modèles pris en charge, placer les instructions stables et les définitions d'outils dans un préfixe de prompt pouvant être mis en cache réduit le traitement répété des entrées, ce qui diminue la latence et le coût en tokens. Pour ADE, la mise en cache du préfixe de prompt stable a réduit le coût des tokens d'entrée de 20 à 30 pour cent.
Sécurité et préparation au lancement
Les rôles IAM sont délimités à la responsabilité de chaque agent. L'agent de dépannage peut lire les données opérationnelles dont il a besoin pour le diagnostic mais ne peut pas modifier les workflows. L'agent expert du domaine peut interroger son index de récupération mais ne peut pas appeler des API CDE sans rapport. En production aujourd'hui, les réponses des agents ADE sont régies par le principe du moindre privilège, un accès aux outils en lecture seule délimité à chaque agent, une validation de sortie structurée sur les réponses des agents, et des réponses fondées sur les données et la télémétrie CDE récupérées plutôt que sur une génération libre. Bayer prévoit également d'évaluer Amazon Bedrock Guardrails comme couche supplémentaire à ces contrôles, complétant les vérifications de sécurité personnalisées déjà utilisées dans les workflows CDE multi-tours.
Avant le lancement, Unified Operations a mené une Critical Workload Review et une revue Well-Architected avec le Generative AI Lens aux côtés de l'équipe ADE. Comme le DSE connaissait déjà la charge de travail, les deux revues ont ciblé les modes de défaillance spécifiques d'ADE, les risques de capacité et les lacunes de déploiement plutôt que des bonnes pratiques génériques. Les constats comprenaient des lacunes dans la visibilité des échecs entre le superviseur et les agents spécialistes, des tags d'images de conteneur modifiables, une traçabilité limitée des images et l'absence d'analyse de vulnérabilités. L'équipe a répondu par des alarmes renforcées, des images versionnées immuables, une analyse au push dans Amazon ECR et des politiques de cycle de vie pour les images inutilisées.
Le DSE a également examiné avec l'équipe les exigences de mise à l'échelle et de quotas. Les tests de charge ont validé à la fois l'application et ses quotas de service, et ont révélé un mode de défaillance réseau qui renvoyait des réponses vides, que l'équipe a corrigé avant l'événement de production. Au lancement, l'équipe avait suivi la résolution de 35 bloqueurs avec Unified Operations.
Lancement, opérations et prochaines étapes
Bayer a lancé ADE auprès d'un groupe restreint plutôt que de l'ouvrir à toute l'organisation d'un coup. Depuis son lancement, plus de 100 utilisateurs de Bayer Crop Science ont utilisé ADE, notamment des sélectionneurs, des analystes, des chercheurs, des data scientists et des ingénieurs. En plus de ses 22 agents spécialisés, ADE expose environ 20 outils API et peut héberger des agents tiers à mesure qu'il s'étend. L'exposition de ces API via AgentCore Gateway plutôt qu'un serveur dédié par API a réduit les frais d'intégration par API de plus de 99 pour cent. Dans sa première phase, ADE a résolu environ 80 pour cent des questions des utilisateurs sans intervention d'un ingénieur.
CDE reste la couche d'exécution gouvernée pour l'analytique. ADE y ajoute une couche en langage naturel, permettant aux utilisateurs de s'informer sur l'état des workflows, les résultats, le comportement des modèles et les échecs sans avoir à connaître l'emplacement ou l'interface de chaque système sous-jacent.
L'engagement s'est ensuite déplacé de la préparation au lancement vers les opérations continues. Le DSE continue de rencontrer l'équipe, de sorte que le triage des incidents et les revues opérationnelles partent d'une connaissance existante d'ADE au lieu d'une nouvelle phase de montée en compétence. Les alarmes CloudWatch critiques d'ADE, y compris les alarmes spécifiques à l'agent décrites précédemment, sont intégrées à AWS Incident Detection and Response. Lorsque l'une d'elles se déclenche, des AWS Incident Management Engineers interviennent dans les 5 minutes et partent du contexte de la charge de travail plutôt que de zéro. Sur le plan de la sécurité, des ingénieurs AWS Security Incident Response accompagnent l'équipe lors d'événements de sécurité potentiels ou actifs, de sorte qu'ADE bénéficie d'une couverture de surveillance et de réponse AWS à la fois pour les problèmes opérationnels et de sécurité.
Avec la communication d'agent à agent déjà en place, Bayer se concentre ensuite sur l'interopérabilité des agents dans le cloud hybride. L'équipe explore comment des agents exécutés dans des environnements différents peuvent se découvrir et communiquer entre eux sans configuration manuelle.
Conclusion
Bayer n’a pas remplacé sa plateforme d’analytique par ADE. Elle a rendu CDE plus facile à interroger et à exploiter. L’essentiel du travail de production se situait en dehors des prompts : état durable, frontières d’identité, périmétrage des outils, observabilité au niveau des tâches, attribution des coûts et préparation au lancement. Bayer a été propriétaire de l’architecture et de chacune de ces décisions. En travaillant avec un DSE et un TAM désignés dans le cadre d’AWS Unified Operations, l’équipe a testé ces décisions par rapport au comportement des services AWS dès la phase de conception, puis a reporté le même contexte en production.
Pour en savoir plus, explorez Amazon Bedrock AgentCore, Attribution des coûts d'Amazon Bedrock, Recommandations AWS Well-Architected pour l'IA générative, et AWS Unified Operations.
Les auteurs tiennent à remercier Sijie Shi, Jorge Gomes, Naveen Reddy, Iago Fonseca, Mateus Silva et Sushimitha Jarugula pour leurs contributions à la conception, au développement et au lancement d'ADE.