Las decisiones de fitomejoramiento dependen de datos que abarcan genómica, ensayos de campo, imágenes, condiciones ambientales y salidas de modelos. Bayer Crop Science ejecuta cientos de configuraciones de modelos de aprendizaje automático (ML) sobre estos datos en diferentes cultivos, regiones y equipos, y cada ejecución debe ser repetible y estar gobernada. Para cumplir ese requisito, Bayer construyó el Connected Decision Engine (CDE), un sistema para implementar, orquestar, monitorear y reutilizar flujos de trabajo de ML. CDE ofrece a los fitomejoradores, analistas, investigadores, científicos de datos e ingenieros de datos una forma consistente de ejecutar análisis, preservando el historial de ejecución y los controles operativos.
A medida que creció la adopción, el cuello de botella pasó de ejecutar los flujos de trabajo a comprenderlos. Explicar un resultado significaba reunir contexto de APIs, documentación, almacenes de metadatos, paneles y registros. Un usuario que quería saber por qué falló un flujo de trabajo, qué hizo un modelo o de dónde provenía un resultado todavía tenía que saber qué sistema inspeccionar. Para cerrar esa brecha, Bayer construyó el Agentic Decision Engine (ADE), una interfaz multiagente de lenguaje natural sobre el CDE. Un agente supervisor dirige cada pregunta a un agente especialista, el especialista recupera el contexto del sistema relevante y el usuario recibe una respuesta sin tener que navegar por la pila operativa. En su primera fase, ADE resuelve alrededor del 80 por ciento de las preguntas de los usuarios sin necesidad de un ingeniero en el proceso.
ADE funciona sobre Amazon Bedrock AgentCore, un servicio de AWS para construir, conectar y optimizar agentes a escala con cualquier framework o modelo. AgentCore permitió al equipo centrarse en el comportamiento de los agentes en lugar de construir y operar su propia capa de alojamiento de agentes, aislamiento de sesiones y acceso a herramientas. Tres capacidades de AgentCore impulsaron esa elección: un runtime administrado que aísla cada sesión de usuario, el acceso a herramientas delimitado por AWS Identity and Access Management (IAM) a través de AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, que mantiene la autenticación y autorización fuera del código del agente, y un diseño agnóstico al framework que permitió al equipo usar su propia orquestación con LangGraph y su elección de modelos.
Para prepararse para el lanzamiento y operar el ADE posteriormente, Bayer recurrió a AWS Unified Operations. La contratación proporcionó un Technical Account Manager (TAM) designado y un Ingeniero Especialista de Dominio en IA generativa (DSE), quienes trabajaron como una extensión del equipo del ADE desde el diseño hasta la producción. El TAM, como asesor estratégico de Bayer, aportó un conocimiento consolidado del modelo operativo y las prioridades comerciales de Bayer. El DSE aportó experiencia de dominio en IA generativa sobre AWS. En tres reuniones técnicas diarias (standups) cada semana, el equipo revisaba y tomaba decisiones de diseño. El DSE adquirió un conocimiento funcional de la carga de trabajo del ADE y de cómo opera el equipo de Bayer, de modo que la orientación técnica reflejaba tanto el comportamiento de los servicios de AWS como el contexto de Bayer. Esta publicación sigue ese recorrido: la arquitectura del ADE, cinco decisiones de diseño tomadas durante la construcción, el trabajo para preparar la plataforma para producción y cómo se opera después del lanzamiento.
Descripción general de la arquitectura
ADE está organizado en cuatro capas: la experiencia de usuario, la orquestación de agentes, los agentes especialistas y las herramientas y fuentes de datos que esos agentes invocan (Figura 1). Los usuarios acceden a ADE a través de un front end web en React, y las solicitudes pasan por un proxy de identidad para Microsoft Entra ID antes de llegar a los agentes. GitHub Actions construye las imágenes de contenedor de los agentes, las envía a Amazon Elastic Container Registry (Amazon ECR), y las implementa en AgentCore runtime, una capacidad de Amazon Bedrock AgentCore.
El runtime de Amazon Bedrock AgentCore aloja los agentes y, como el runtime es agnóstico al framework, el equipo ejecuta directamente sobre él su propia orquestación basada en LangGraph. El equipo eligió LangGraph por su flujo de control explícito basado en grafos y su checkpointing para flujos de trabajo de varios pasos. LangGraph orquesta el flujo de trabajo, con un Supervisor Agent como punto de entrada que clasifica cada solicitud, selecciona un especialista y combina resultados cuando una pregunta abarca varios dominios. El plano de datos se separa por responsabilidad. Amazon DynamoDB almacena el estado de los checkpoints de LangGraph. Amazon Aurora PostgreSQL almacena los registros de sesión, los comentarios de los usuarios y el análisis de datos. Amazon ElastiCache almacena en caché las respuestas de los agentes con un tiempo de vida (TTL). El contenido de dominio en Amazon Simple Storage Service (Amazon S3) se convierte en embeddings con Amazon Titan Text Embeddings V2 y se indexa en Amazon OpenSearch Serverless para la Generación Aumentada por Recuperación (RAG). Amazon CloudWatch captura la telemetría del runtime y de la aplicación. AgentCore Gateway expone las API de backend a los agentes como herramientas del Model Context Protocol (MCP) y mantiene la autenticación y la autorización fuera del código de los agentes.
Figura 1: Arquitectura del Agentic Decision Engine en Amazon Bedrock AgentCore
ADE ejecuta 22 agentes especialistas en producción, cada uno acotado a un dominio con sus propias herramientas y fuentes de datos. Por ejemplo, el Domain Expert Agent responde preguntas conceptuales mediante RAG. El Operational Agent recupera el estado y los resultados en vivo de los flujos de trabajo desde CDE. El Troubleshooting Agent analiza la telemetría operativa. El Visualization Agent genera gráficos o devuelve paneles existentes. Un patrón específico del cliente llamado Models as Skill convierte el código de los modelos y su documentación en definiciones de habilidades almacenadas en un registro central, de modo que los agentes respondan preguntas específicas del modelo a partir de su implementación en lugar de conocimiento genérico del modelo.
Cuando un mejorador pregunta: “¿Por qué falló ayer mi flujo de trabajo de fenotipado?”, el supervisor clasifica la intención y enruta la solicitud al Troubleshooting Agent. Ese agente lee la telemetría del flujo de trabajo en CloudWatch y su estado desde la API de CDE a través de AgentCore Gateway, identifica el punto de falla y devuelve un diagnóstico a través del supervisor (Figura 2). El mejorador no busca directamente en los registros. Con el Troubleshooting Agent, un diagnóstico que antes tomaba más de una hora de búsqueda manual en registros y de espera por el apoyo de un ingeniero ahora toma menos de 10 minutos.
Figura 2: Flujo de solicitudes de ADE: clasificación de la intención, búsqueda en caché, enrutamiento al especialista y respuesta
Cinco decisiones de diseño en el camino a producción
El Unified Operations TAM y el DSE participaron en las siguientes decisiones como miembros del equipo de trabajo, no como un punto de escalamiento a posteriori. Eso permitió a Bayer probar cada diseño contra el comportamiento de los servicios de AWS antes de comprometerse con él, manteniendo la propiedad de la arquitectura y la decisión final.
1. Externalizar el estado de la orquestación sin tratar el runtime como sin estado
El runtime de AgentCore proporciona sesiones aisladas que preservan el contexto de ejecución a través de las invocaciones dentro del ciclo de vida de una sesión. Ese contexto no es un almacén duradero para un flujo de trabajo de varios pasos. ADE escribe los checkpoints de LangGraph en DynamoDB para que el grafo pueda reanudarse después de eventos de escalado horizontal, reinicios o límites de sesión sin depender de que un entorno de ejecución único permanezca disponible.
Principio: Usar la sesión del runtime para la ejecución activa y persistir el estado necesario para reanudar o reconstruir el flujo de trabajo en un servicio duradero.
2. Separar la identidad empresarial, el acceso al gateway y la autorización de los sistemas aguas abajo
Bayer estandariza Microsoft Entra ID para la identidad de los usuarios, mientras que los servicios de ADE se autorizan entre sí con mecanismos nativos de AWS. En lugar de forzar un único token a través de cada límite de confianza, el equipo asignó a cada límite su propio mecanismo.
Entra ID sigue siendo la fuente de la identidad de los usuarios. AWS Identity and Access Management (IAM) autoriza las llamadas entre servicios. La autorización de salida de AgentCore Gateway gestiona el acceso a los servicios de CDE aguas abajo. Una función interceptor de solicitudes de AWS Lambda realiza una validación personalizada y pasa los atributos de autorización que requieren las herramientas aguas abajo. El equipo trabajó el contrato de tokens en cada salto con el DSE.
Principio: Las fallas de identidad en los sistemas de agentes se agrupan en las transiciones entre la identidad del usuario, la identidad del agente y la identidad de la herramienta. Defina el emisor, la audiencia, los claims, los scopes y el tiempo de vida de las credenciales en cada salto en lugar de reutilizar un token que es válido para un límite en el siguiente.
3. Tratar la selección del modelo como un contrato de interfaz
Durante la construcción, el equipo evaluó una versión más reciente del modelo con el modo de razonamiento habilitado. Para esa versión, la combinación de uso de herramientas y salida estructurada de la que depende ADE no era compatible con la forma en que estaban implementados sus agentes. El DSE confirmó la restricción y el equipo mantuvo el modelo actual para la versión.
Principio: Para los agentes que usan herramientas, la elección del modelo está condicionada por la interfaz completa: llamada de herramientas, salida estructurada, comportamiento de streaming, funciones de razonamiento, latencia, disponibilidad de cuota y semántica de solicitudes específicas del modelo. Un modelo más nuevo no es automáticamente un reemplazo directo.
4. Controle la superficie de herramientas antes de que ella controle el prompt
CDE gestiona más de 500 configuraciones de modelos. Un servidor MCP dedicado por API habría añadido sobrecarga de despliegue, autenticación y gestión de versiones. En su lugar, ADE registra especificaciones OpenAPI con AgentCore Gateway, que expone las operaciones REST como herramientas MCP. Añadir o modificar una API pasa a ser un cambio de esquema y de configuración de gateway en lugar de un nuevo despliegue de servidor.
Los esquemas y descripciones de las herramientas también consumen tokens de entrada y compiten con la solicitud del usuario y el contexto recuperado. ADE delimita las herramientas por agente especialista en lugar de dar a cada agente el catálogo completo. Para catálogos más grandes, AgentCore Gateway admite la búsqueda semántica de herramientas, de modo que un agente puede encontrar herramientas relevantes sin cargar todo el catálogo en cada turno.
Principio: Delimite el catálogo de herramientas por agente. Cada definición de herramienta añade tokens y amplía el espacio de decisión del modelo.
5. Promover capacidades complejas de herramientas a agentes
La visualización comenzó como una herramienta invocada por otros agentes. A medida que creció, necesitó su propia recuperación de datos, lógica de selección de gráficos, reintentos, manejo de errores y una decisión sobre si generar un gráfico o devolver un panel existente. El equipo la convirtió en un Agente de Visualización especialista. El agente genera gráficos bajo demanda con matplotlib y Plotly en AgentCore Code Interpreter, una capacidad de Amazon Bedrock AgentCore que proporciona un entorno aislado de ejecución de código, e intercambia datos con él a través de Amazon S3. Cuando un panel preconstruido es la mejor respuesta, el agente devuelve el recurso existente de Amazon Quick o Power BI.
Principio: Una herramienta realiza una operación acotada. Cuando una capacidad empieza a gestionar estado, reintentos, planificación, políticas o decisiones de presentación, modeléela como un agente.
Preparar ADE para producción
A medida que la construcción se acercaba al lanzamiento, el foco pasó del diseño a la operabilidad: detectar fallos de los agentes, atribuir el costo de inferencia y reforzar el despliegue.
Observabilidad: Medir los fallos de las tareas, no solo las excepciones
Una arquitectura de supervisor convierte una solicitud de usuario en una cadena de llamadas a modelos, llamadas a herramientas y traspasos entre agentes. La respuesta final puede ser incorrecta incluso cuando cada solicitud HTTP tuvo éxito. ADE se encontró con esto directamente: los gestores de excepciones de la aplicación capturaban errores de los agentes y devolvían respuestas que la monitorización contaba como exitosas. Tras reproducir el problema con el DSE, el equipo añadió métricas personalizadas de CloudWatch dentro de las rutas de fallo y alarmas sobre condiciones específicas de los agentes: errores en llamadas a herramientas, limitación (throttling), tiempos de espera agotados de modelos y fallos de validación de salida estructurada. Las trazas y los registros de invocación siguen cada solicitud a través del supervisor y los especialistas.
Principio: Distinga el éxito de transporte del éxito de la tarea. La observabilidad de los agentes debe mostrar si la tarea se completó, qué agente o herramienta cambió el resultado y si la respuesta utilizó la fuente esperada.
Atribución de costos: Combinar la atribución de facturación con la telemetría a nivel de solicitud
Una solicitud de ADE puede invocar varios modelos y herramientas, por lo que el gasto de Amazon Bedrock a nivel de cuenta no explica la economía unitaria. El equipo diseñó el enfoque de atribución con el DSE usando tres mecanismos que responden a preguntas diferentes. Los perfiles de inferencia de aplicación de Amazon Bedrock atribuyen el uso facturado de modelos a una aplicación o carga de trabajo. Los metadatos de solicitud y el registro de invocaciones de modelos asocian el uso de tokens con un agente, característica o solicitud específica. La atribución de principales de IAM añade una dimensión de identidad. En conjunto, permiten al equipo estimar el costo por interacción, identificar agentes costosos y determinar si los prompts, el contexto recuperado o las definiciones de herramientas impulsan el uso de tokens. En la práctica, los agentes de Visualización y Operaciones, que dependen de herramientas MCP y de múltiples llamadas a herramientas, fueron los que más tokens consumieron.
La misma telemetría reveló durante la preparación del lanzamiento una carga de trabajo con un gran prefijo de entrada repetido y sin actividad de caché de prompts. Para los modelos compatibles, colocar instrucciones estables y definiciones de herramientas en un prefijo de prompt almacenable en caché reduce el procesamiento repetido de la entrada, lo que disminuye la latencia y el costo de tokens. Para ADE, almacenar en caché el prefijo de prompt estable redujo el costo de tokens de entrada entre un 20 y un 30 por ciento.
Seguridad y preparación para el lanzamiento
Los roles de IAM están delimitados a la responsabilidad de cada agente. El Agente de Resolución de Problemas puede leer los datos operativos que necesita para el diagnóstico, pero no puede modificar flujos de trabajo. El Agente Experto en Dominio puede consultar su índice de recuperación, pero no puede llamar a APIs de CDE no relacionadas. Hoy en producción, las respuestas de los agentes de ADE se rigen por el privilegio mínimo, acceso de solo lectura a herramientas delimitado a cada agente, validación de salida estructurada en las respuestas de los agentes, y respuestas fundamentadas en datos y telemetría de CDE recuperados en lugar de generación abierta. Bayer también planea evaluar Amazon Bedrock Guardrails como una capa adicional sobre estos controles, complementando las comprobaciones de seguridad personalizadas ya utilizadas en los flujos de trabajo multivuelta de CDE.
Antes del lanzamiento, Unified Operations realizó una Critical Workload Review y una revisión Well-Architected con la Generative AI Lens junto al equipo de ADE. Como el DSE ya conocía la carga de trabajo, ambas revisiones se centraron en los modos de fallo específicos de ADE, los riesgos de capacidad y las brechas de despliegue, en lugar de prácticas recomendadas genéricas. Los hallazgos incluyeron brechas en la visibilidad de fallos entre el supervisor y los agentes especialistas, etiquetas de imágenes de contenedor mutables, trazabilidad limitada de imágenes y falta de escaneo de vulnerabilidades. El equipo respondió con alarmas más robustas, imágenes inmutables versionadas, escaneo al subir en Amazon ECR y políticas de ciclo de vida para imágenes no utilizadas.
El DSE también revisó con el equipo los requisitos de escalado y cuotas. Las pruebas de carga validaron tanto la aplicación como sus cuotas de servicio y expusieron un modo de fallo de red que devolvía respuestas vacías, el cual el equipo corrigió antes del evento de producción. Para el lanzamiento, el equipo había hecho seguimiento de 35 bloqueadores hasta su resolución con Unified Operations.
Lanzamiento, operaciones y próximos pasos
Bayer lanzó ADE a un grupo restringido en lugar de abrirlo a toda la organización de una vez. Desde su lanzamiento, más de 100 usuarios de Bayer Crop Science han usado ADE, incluidos fitomejoradores, analistas, investigadores, científicos de datos e ingenieros. Junto con sus 22 agentes especializados, ADE expone alrededor de 20 herramientas de API y puede alojar agentes de terceros a medida que se expande. Exponer esas API a través de AgentCore Gateway en lugar de un servidor dedicado por API redujo los costos generales de integración por API en más del 99 por ciento. En su primera fase, ADE ha resuelto alrededor del 80 por ciento de las preguntas de los usuarios sin necesidad de un ingeniero en el proceso.
CDE remains the governed execution so users ADE adds a natural language layer over it, so users can ask about workflow status, results, model behavior, and failures without learning the location or interface of each underlying system.
El compromiso pasó entonces de la preparación del lanzamiento a las operaciones continuas. El DSE sigue reuniéndose con el equipo, por lo que la clasificación de problemas y las revisiones operativas parten de un conocimiento existente de ADE en lugar de una nueva fase de aprendizaje. Las alarmas críticas de CloudWatch de ADE, incluidas las alarmas específicas del agente descritas anteriormente, están incorporadas a AWS Incident Detection and Response. Cuando se activa una, los AWS Incident Management Engineers intervienen en 5 minutos y parten del contexto de la carga de trabajo en lugar de empezar de cero. En el ámbito de la seguridad, los ingenieros de AWS Security Incident Response apoyan al equipo durante eventos de seguridad potenciales o activos, de modo que ADE cuenta con cobertura de monitoreo y respuesta de AWS tanto para problemas operativos como de seguridad.
Con la comunicación de agente a agente ya establecida, Bayer se centrará a continuación en la interoperabilidad de agentes en la nube híbrida. El equipo está explorando cómo los agentes que se ejecutan en distintos entornos pueden descubrirse y comunicarse entre sí sin necesidad de configuración manual.
Conclusión
Bayer no reemplazó su plataforma de analítica con ADE. Hizo que CDE fuera más fácil de consultar y operar. La mayor parte del trabajo de producción estaba fuera de los prompts: estado duradero, límites de identidad, alcance de herramientas, observabilidad a nivel de tareas, atribución de costos y preparación para el lanzamiento. Bayer era propietaria de la arquitectura y de cada una de esas decisiones. Trabajando con un DSE y un TAM designados a través de AWS Unified Operations, el equipo puso a prueba esas decisiones contra el comportamiento de los servicios de AWS durante el diseño y llevó el mismo contexto a la producción.
Para obtener más información, explore Amazon Bedrock AgentCore, Atribución de costos de Amazon Bedrock, Orientación de AWS Well-Architected sobre IA generativa, y AWS Unified Operations.
Los autores quisieran agradecer a Sijie Shi, Jorge Gomes, Naveen Reddy, Iago Fonseca, Mateus Silva y Sushimitha Jarugula por sus contribuciones al diseño, desarrollo y lanzamiento de ADE.