Las decisiones de mejora de cultivos 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) contra estos datos en diferentes cultivos, regiones y equipos, y cada ejecución debe ser repetible y gobernada. Para cumplir con ese requisito, Bayer creó el Connected Decision Engine (CDE), un sistema para implementar, orquestar, monitorear y reutilizar flujos de trabajo de ML. CDE brinda a los mejoradores, analistas, investigadores, científicos de datos y ingenieros de datos una forma consistente de ejecutar análisis mientras se preserva el historial de ejecución y los controles operativos.

A medida que crecía la adopción, el cuello de botella se trasladó de ejecutar flujos de trabajo a entenderlos. Explicar un resultado significaba reunir contexto de APIs, documentación, almacenes de metadatos, paneles de control y registros. Un usuario que quería saber por qué un flujo de trabajo falló, qué hizo un modelo o de dónde provino un resultado todavía tenía que saber qué sistema inspeccionar. Para cerrar esa brecha, Bayer creó el Agentic Decision Engine (ADE), una interfaz de lenguaje natural multiagente sobre CDE. Un agente supervisor enruta cada pregunta a un agente especialista, el agente especialista recupera contexto del sistema relevante y el usuario recibe una respuesta sin navegar por la pila operativa. En su primera fase, ADE resuelve alrededor del 80 por ciento de las preguntas de los usuarios sin un ingeniero en el ciclo.

ADE se ejecuta en Amazon Bedrock AgentCore, un servicio de AWS para crear, conectar y optimizar agentes a escala con cualquier framework o modelo. AgentCore permitió que el equipo se centrara en el comportamiento del agente 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, acceso a herramientas con ámbito de 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 de framework que permitió que el equipo trajera su propia orquestación de LangGraph y elección de modelos.

Para prepararse para el lanzamiento y operar ADE posteriormente, Bayer contrató AWS Unified Operations. El contrato proporcionó un Gerente de Cuenta Técnica (TAM) designado y un Ingeniero Especialista en Dominio de Inteligencia Artificial Generativa (DSE), que trabajó como una extensión del equipo de ADE desde el diseño hasta la producción. El TAM, como asesor estratégico de Bayer, aportó una comprensión establecida del modelo operativo y las prioridades comerciales de Bayer. El DSE aportó experiencia en dominio de inteligencia artificial generativa en AWS. En tres reuniones técnicas cada semana, el equipo revisó y tomó decisiones de diseño. El DSE construyó conocimientos sobre la carga de trabajo de ADE y cómo opera el equipo de Bayer, por lo que la orientación técnica reflejó tanto el comportamiento del servicio de AWS como el contexto de Bayer. Esta publicación sigue ese viaje: la arquitectura de ADE, cinco decisiones de diseño tomadas durante la construcción, el trabajo para preparar la plataforma para la producción y cómo se opera después del lanzamiento.

Visión general de la arquitectura

ADE se organiza en cuatro capas: la experiencia del usuario, la orquestación de agentes, los agentes especializados y las herramientas y fuentes de datos que estos agentes llaman (Figura 1). Los usuarios acceden a ADE a través de una interfaz web de React, y las solicitudes pasan por un proxy de identidad para Microsoft Entra ID antes de llegar a los agentes. GitHub Actions crea las imágenes de contenedores de agentes, las envía a Amazon Elastic Container Registry (Amazon ECR) y las despliega en AgentCore runtime, una capacidad de Amazon Bedrock AgentCore.

El runtime de Amazon Bedrock AgentCore hospeda a los agentes, y como el runtime es agnóstico al framework, el equipo ejecuta su propia orquestación basada en LangGraph directamente en él. El equipo eligió LangGraph por su control de flujo de trabajo explícito basado en gráficos y su capacidad de crear puntos de control para flujos de trabajo de varios pasos. LangGraph orquesta el flujo de trabajo, con un Agente Supervisor como punto de entrada que clasifica cada solicitud, selecciona un especialista y combina los resultados cuando una pregunta abarca varios dominios. El plano de datos se separa por responsabilidad. Amazon DynamoDB almacena el estado de los puntos de control de LangGraph. Amazon Aurora PostgreSQL almacena registros de sesión, comentarios de los usuarios y análisis. 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 incorpora con Amazon Titan Text Embeddings V2 y se indexa en Amazon OpenSearch Serverless para Generación mejorada con recuperación (RAG). Amazon CloudWatch captura la telemetría del runtime y la aplicación. La puerta de enlace de AgentCore expone las API de backend a los agentes como herramientas de Protocolo de contexto de modelo (MCP) y mantiene la autenticación y autorización fuera del código del agente.

Figura 1: Arquitectura del motor de decisión de Agentic en Amazon Bedrock AgentCore

ADE ejecuta 22 agentes especializados en producción, cada uno con un alcance limitado a un dominio con sus propias herramientas y fuentes de datos. Por ejemplo, el Agente Experto en Dominio responde preguntas conceptuales a través de RAG. El Agente Operativo recupera el estado y los resultados del flujo de trabajo en vivo desde CDE. El Agente de Solución de Problemas analiza la telemetría operativa. El Agente de Visualización genera gráficos o devuelve paneles de control existentes. Un patrón de Modelos como Habilidad específico del cliente convierte el código del modelo y la documentación en definiciones de habilidades almacenadas en un registro central, por lo que los agentes responden preguntas específicas del modelo a partir de la implementación del modelo en lugar de conocimientos genéricos del modelo.

Cuando un criador pregunta: “¿Por qué falló mi flujo de trabajo de fenotipado ayer!”, el supervisor clasifica la intención y ruta la solicitud al Agente de Solución de Problemas. Ese agente lee la telemetría del flujo de trabajo en CloudWatch y su estado desde la API de CDE a través de la puerta de enlace de AgentCore, identifica el punto de falla y devuelve un diagnóstico a través del supervisor (Figura 2). El criador no busca registros directamente. Con el Agente de Solución de Problemas, un diagnóstico que antes tomaba más de una hora de búsqueda manual de registros y espera de soporte de ingeniería ahora toma menos de 10 minutos.

Figura 2: Flujo de solicitudes de ADE: clasificación de intención, búsqueda de caché, enrutamiento de especialista y respuesta

Cinco decisiones de diseño en el camino a la producción

El TAM y DSE de Operaciones Unificadas participaron en las siguientes decisiones como miembros del equipo de trabajo, no como un punto de escalada después del hecho. Eso permitió a Bayer probar cada diseño contra el comportamiento del servicio de AWS antes de comprometerse con él, manteniendo la propiedad de la arquitectura y la última llamada.

1. Externalizar el estado de orquestación sin tratar el runtime como estadoless

El runtime de AgentCore proporciona sesiones aisladas que conservan el contexto de ejecución a través de las invocaciones dentro del ciclo de vida de una sesión. Ese contexto no es una tienda duradera para un flujo de trabajo de varios pasos. ADE escribe puntos de control de LangGraph en DynamoDB para que el gráfico pueda reanudarse después de eventos de escalado, reinicios o límites de sesión sin depender de que un entorno de ejecución permanezca disponible.

Principio: Utilice la sesión de runtime para la ejecución activa y persista el estado requerido para reanudar o reconstruir el flujo de trabajo en un servicio duradero.

2. Separar la identidad empresarial, el acceso a la puerta de enlace y la autorización descendente

Bayer estandariza en Microsoft Entra ID para la identidad de usuario, mientras que los servicios de ADE se autorizan entre sí con mecanismos nativos de AWS. En lugar de forzar un token en cada límite de confianza, el equipo dio a cada límite su propio mecanismo.

Entra ID sigue siendo la fuente de identidad de usuario. AWS Identity and Access Management (IAM) autoriza las llamadas de servicio a servicio. La autorización de salida de AgentCore Gateway controla el acceso a los servicios CDE downstream. Una función AWS Lambda de interceptor de solicitudes realiza una validación personalizada y pasa los atributos de autorización que las herramientas downstream requieren. El equipo trabajó en el contrato de token en cada salto con el DSE.

Principio: Los fallos de identidad en los sistemas de agentes se agrupan en las transiciones entre la identidad de usuario, la identidad de agente y la identidad de herramienta. Defina el emisor, el público, las reclamaciones, los ámbitos 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. Trate la selección de modelo como un contrato de interfaz

Durante la compilación, el equipo evaluó una versión más nueva del modelo con el modo de razonamiento habilitado. Para esa versión, la combinación de uso de herramientas y salida estructurada en la que ADE depende no era compatible con la forma en que sus agentes estaban implementados. El DSE confirmó la restricción y el equipo retuvo el modelo actual para la versión.

Principio: Para los agentes que utilizan herramientas, la elección del modelo está limitada por la interfaz completa: llamada de herramienta, salida estructurada, comportamiento de transmisión, características de razonamiento, latencia, disponibilidad de cuota y semántica de solicitud específica del modelo. Un modelo más nuevo no es automáticamente un reemplazo directo.

4. Controle la superficie de la herramienta antes de que controle la solicitud

CDE administra más de 500 configuraciones de modelo. Un servidor MCP dedicado por API habría agregado sobrecarga de implementación, autenticación y administración de versiones. ADE registra en su lugar especificaciones de OpenAPI con AgentCore Gateway, que expone las operaciones REST como herramientas MCP. Agregar o cambiar una API se convierte en un cambio de esquema y configuración de la puerta de enlace en lugar de una implementación de servidor nuevo.

Los esquemas y descripciones de herramientas también consumen tokens de entrada y compiten con la solicitud del usuario y el contexto recuperado. ADE limita 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 de herramientas semánticas, por lo que un agente puede encontrar herramientas relevantes sin cargar el catálogo completo en cada turno.

Principio: Limite el catálogo de herramientas por agente. Cada definición de herramienta agrega tokens y amplía el espacio de decisión del modelo.

5. Promueva capacidades complejas de las herramientas a los agentes

La visualización comenzó como una herramienta invocada por otros agentes. A medida que crecía, necesitaba 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 de control existente. El equipo lo movió a un Agente de Visualización especializado. El agente genera gráficos bajo demanda con matplotlib y Plotly en el intérprete de código de AgentCore, una capacidad de Amazon Bedrock AgentCore que proporciona un entorno de ejecución de código aislado, y intercambia datos con él a través de Amazon S3. Cuando un panel de control preconstruido es la mejor respuesta, el agente devuelve el activo existente de Amazon Quick o Power BI.

Principio: Una herramienta realiza una operación limitada. Cuando una capacidad comienza a poseer estado, reintentos, planificación, política o decisiones de presentación, modélala como un agente.

Preparación de ADE para producción

A medida que la compilación se acercaba al lanzamiento, el enfoque se desplazó desde el diseño a la operabilidad: detección de fallas de agente, atribución de costo de inferencia y endurecimiento de la implementación.

Observabilidad: Medir fallas de tareas, no solo excepciones

Una arquitectura de supervisor convierte una solicitud de usuario en una cadena de llamadas de modelo, llamadas de herramienta y transferencias de agente. La respuesta final puede ser incorrecta incluso cuando todas las solicitudes HTTP tuvieron éxito. ADE enfrentó esto directamente: los controladores de excepciones de la aplicación capturaron errores de agente y devolvieron respuestas que el monitoreo contó como exitosas. Después de reproducir el problema con el DSE, el equipo agregó métricas personalizadas de CloudWatch dentro de los caminos de falla y alarmas en condiciones específicas de agente: errores de llamadas de herramienta, limitación, tiempos de espera de modelo y fallas de validación de salida estructurada. Los registros de seguimiento y los registros de invocación siguen cada solicitud a través del supervisor y los especialistas.

Principio: Distinguir el éxito del transporte del éxito de la tarea. La observabilidad del agente 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 costo: Combinar la atribución de facturación con 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 de unidades. El equipo diseñó el enfoque de atribución con el DSE utilizando tres mecanismos que responden a diferentes preguntas. Los perfiles de inferencia de aplicaciones de Amazon Bedrock atribuyen el uso de modelos facturados a una aplicación o carga de trabajo. Los metadatos de la solicitud y la registrazione de invocación de modelos asocian el uso de tokens con un agente específico, función o solicitud. La atribución de principal de IAM agrega una dimensión de identidad. Juntos permiten que el equipo estime el costo por interacción, identifique agentes costosos y determine si las solicitudes, el contexto recuperado o las definiciones de herramientas impulsan el uso de tokens. En la práctica, los agentes de Visualización y Operativos, que dependen de herramientas de MCP y múltiples llamadas a herramientas, consumieron la mayoría de los tokens.

La misma telemetría reveló una carga de trabajo durante la preparación del lanzamiento con un prefijo de entrada repetido grande y sin actividad de caché de solicitudes. Para los modelos compatibles, colocar instrucciones estables y definiciones de herramientas en un prefijo de solicitud cachéable reduce el procesamiento de entradas repetidas, lo que reduce la latencia y el costo de tokens. Para ADE, almacenar en caché el prefijo de solicitud estable redujo el costo de tokens de entrada en un 20-30 por ciento.

Seguridad y preparación para el lanzamiento

Los roles de IAM están limitados a la responsabilidad de cada agente. El Agente de Solución de Problemas puede leer los datos operativos que necesita para el diagnóstico pero no puede modificar flujos de trabajo. El Agente de Experto en Dominio puede consultar su índice de recuperación pero no puede llamar a API de CDE no relacionadas. En producción hoy en día, las respuestas de los agentes de ADE están gobernadas por el privilegio mínimo, acceso de solo lectura a herramientas limitado a cada agente, validación de salida estructurada en las respuestas de los agentes y respuestas basadas en datos de CDE recuperados y telemetría en lugar de generación abierta. Bayer también planea evaluar Amazon Bedrock Guardrails como una capa adicional de estos controles, complementando las comprobaciones de seguridad personalizadas ya utilizadas en flujos de trabajo de CDE de varias vueltas.

Antes del lanzamiento, Unified Operations realizó una Revisión de Carga de Trabajo Crítica y una revisión de Arquitectura Bien Diseñada con la Lente de Inteligencia Artificial Generativa junto con el equipo de ADE. Debido a que el DSE ya conocía la carga de trabajo, ambas revisiones se centraron en los modos de falla específicos de ADE, los riesgos de capacidad y los gaps de implementación en lugar de prácticas recomendadas genéricas. Los hallazgos incluyeron gaps en la visibilidad de fallas en los agentes supervisor y especialista, etiquetas de imagen de contenedor mutables, trazabilidad de imagen limitada y análisis de vulnerabilidades faltantes. El equipo respondió con alarmas más fuertes, imágenes de versión inmutable, análisis en push en Amazon ECR y políticas de ciclo de vida para imágenes no utilizadas.

El DSE también revisó los requisitos de escalado y cuotas con el equipo. Las pruebas de carga validaron tanto la aplicación como sus cuotas de servicio y expusieron un modo de falla de red que devolvió respuestas vacías, que el equipo solucionó antes del evento de producción. Para el lanzamiento, el equipo había rastreado 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 el lanzamiento, más de 100 usuarios en Bayer Crop Science han utilizado 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 la sobrecarga 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 un ingeniero en el ciclo.

CDE sigue siendo la capa de ejecución gobernada para analíticas. ADE agrega una capa de lenguaje natural sobre ella, para que los usuarios puedan preguntar sobre el estado del flujo de trabajo, los resultados, el comportamiento del modelo y los errores sin aprender la ubicación o la interfaz de cada sistema subyacente.

El compromiso luego se trasladó de la preparación para el lanzamiento a las operaciones continuas. El DSE sigue reuniéndose con el equipo, para que el triaje de problemas y las revisiones operativas comiencen desde el conocimiento existente de ADE en lugar de un nuevo proceso de incorporación. Las alarmas críticas de CloudWatch de ADE, incluidas las alarmas específicas de agente descritas anteriormente, se incorporan a la detección y respuesta de incidentes de AWS. Cuando se dispara una alarma, los ingenieros de gestión de incidentes de AWS se involucran dentro de los 5 minutos y comienzan desde el contexto de la carga de trabajo en lugar de partir de cero. En el lado de la seguridad, los ingenieros de respuesta a incidentes de seguridad de AWS apoyan al equipo durante eventos de seguridad potenciales o activos, para que ADE tenga cobertura de monitoreo y respuesta de AWS tanto para problemas operativos como de seguridad.

Con la comunicación de agente a agente ya implementada, Bayer se enfoca a continuación en la interoperabilidad de agentes de nube híbrida. El equipo está explorando cómo los agentes que se ejecutan en diferentes entornos pueden descubrirse y comunicarse entre sí sin configuración manual.

Conclusión

Bayer no reemplazó su plataforma de analíticas con ADE. Hizo que CDE fuera más fácil de consultar y operar. La mayor parte del trabajo de producción se encontraba fuera de las solicitudes: estado duradero, límites de identidad, alcance de herramientas, observabilidad a nivel de tarea, atribución de costos y preparación para el lanzamiento. Bayer poseía la arquitectura y cada una de esas decisiones. Trabajando con un DSE y un TAM designado a través de las operaciones unificadas de AWS, el equipo probó esas decisiones contra el comportamiento del servicio 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, guía de AWS Well-Architected para IA generativa y Operaciones unificadas de AWS.

Los autores desean 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.

Acerca de los autores