Bayer lanza un motor multiagente sobre AgentCore: el 80% de las consultas, sin ingenieros

Bayer Crop Science ha mostrado cómo es una capa agéntica de nivel industrial sobre una plataforma corporativa de ML. El sistema Agentic Decision Engine (ADE) responde a las preguntas de mejoradores genéticos, analistas e ingenieros de datos sobre workflows, modelos y resultados. En su primera fase resuelve cerca del 80% de las consultas sin ingeniero. El diagnóstico de un fallo, que antes requería más de una hora de búsqueda manual en logs y de espera de ayuda, ahora lleva menos de 10 minutos. Por debajo hay 22 agentes especializados sobre Amazon Bedrock AgentCore.

Por qué hacía falta una capa de agentes sobre la plataforma

Primero, Bayer construyó Connected Decision Engine (CDE), un sistema para desplegar, orquestar, monitorizar y reutilizar workflows de ML. Los datos en mejora genética son heterogéneos: genómica, ensayos de campo, imágenes, condiciones ambientales, salidas de modelos. Se lanzan cientos de configuraciones por cultivo, región y equipo, y cada ejecución debe ser reproducible y estar bajo control.

A medida que crecía el uso, el cuello de botella dejó de ser la ejecución y pasó a ser la comprensión. Para explicar un resultado había que reunir contexto de API, documentación, almacenes de metadatos, dashboards y logs. El usuario tenía que saber en qué sistema mirar. ADE elimina ese requisito: el supervisor clasifica la pregunta y la dirige a un especialista, que extrae el contexto del sistema adecuado.

Arquitectura y cinco decisiones que conviene recordar

El frontend está en React y las solicitudes pasan por un proxy de identidad de Microsoft Entra ID. GitHub Actions construye las imágenes de los agentes, las sube a Amazon ECR y las despliega en AgentCore Runtime. La orquestación usa LangGraph, elegido por su grafo de control explícito y sus checkpoints para escenarios de varios pasos. Los datos se reparten según su función:

• Amazon DynamoDB: checkpoints de LangGraph;
• Amazon Aurora PostgreSQL: sesiones, feedback y analítica;
• Amazon ElastiCache: caché de respuestas de los agentes con TTL;
• Amazon S3 + Titan Text Embeddings V2 + OpenSearch Serverless: RAG sobre contenido de dominio;
• Amazon CloudWatch: telemetría del runtime y de la aplicación;
• AgentCore Gateway: API de backend como herramientas MCP, con autenticación y autorización fuera del código de los agentes.

Entre los 22 agentes figuran Domain Expert (preguntas conceptuales mediante RAG), Operational Agent (estado en vivo y resultados de CDE), Troubleshooting Agent (análisis de telemetría) y Visualization Agent (gráficos o dashboards ya hechos). La plantilla Models as Skill convierte el código y la documentación de un modelo en descripciones de skills dentro de un registro central, de modo que el agente responde a partir de la implementación real y no del conocimiento general.

Cinco decisiones de diseño, adoptadas junto con el technical account manager y un ingeniero de IA generativa de AWS Unified Operations:

• Estado fuera del runtime. La sesión de AgentCore guarda el contexto mientras dura, pero no es un almacenamiento fiable. Los checkpoints van a DynamoDB para que el grafo se reanude tras escalados y reinicios.
• Un mecanismo distinto en cada frontera de confianza. Entra ID identifica al usuario, IAM cubre las llamadas entre servicios, la autorización saliente de Gateway da acceso a CDE y un interceptor Lambda verifica y transmite los atributos. No se arrastró un único token a través de todas las fronteras.
• El modelo como contrato de la interfaz. La nueva versión con modo de razonamiento no era compatible con tool use ni con la salida estructurada en la implementación de los agentes, así que se quedaron con el modelo actual.
• Control del conjunto de herramientas. Con más de 500 configuraciones, un servidor MCP por cada API habría supuesto despliegues y versiones de más. En su lugar, las especificaciones OpenAPI se registran en Gateway y las herramientas se asignan por agente. Cada descripción consume tokens de entrada.
• De herramienta a agente. La visualización creció: necesitaba su propia búsqueda de datos, su lógica de elección de gráfico, reintentos y la decisión de construir un diagrama o devolver un dashboard ya hecho. La convirtieron en un agente con matplotlib y Plotly en AgentCore Code Interpreter (intercambio de datos a través de S3), mientras que los activos ya hechos se devuelven desde Amazon Quick o Power BI.

Observabilidad, coste y lanzamiento

La gran trampa de los sistemas multiagente: la solicitud HTTP tiene éxito, pero la respuesta es incorrecta. En ADE, los manejadores de excepciones capturaban los errores de los agentes y devolvían respuestas que el monitoreo daba por buenas. El equipo añadió métricas propias de CloudWatch dentro de las rutas de fallo y alertas para errores de llamada a herramientas, throttling, timeouts de modelos y fallos de validación de la salida estructurada.

El coste se atribuye con tres mecanismos: application inference profiles en Bedrock, metadatos de las solicitudes con registro de las llamadas a modelos y atribución por principal de IAM. Los agentes que más tokens consumen son Visualization y Operational, con muchas llamadas a herramientas MCP. La telemetría reveló una carga con un prefijo largo y repetitivo sin caché de prompt. Almacenar en caché las instrucciones estables y las descripciones de herramientas redujo el coste de los tokens de entrada entre un 20% y un 30%.

La seguridad se basa en el mínimo privilegio: Troubleshooting Agent lee datos operativos pero no modifica workflows, y Domain Expert no llama a API de CDE ajenas a su función. El acceso a las herramientas es solo de lectura, la salida se valida y las respuestas se apoyan en datos de CDE y en telemetría. Bayer planea evaluar Amazon Bedrock Guardrails como capa adicional. Antes del lanzamiento, AWS realizó una Critical Workload Review y una Well-Architected review con Generative AI Lens; entre los hallazgos había lagunas de visibilidad de los fallos entre el supervisor y los especialistas.

La conclusión práctica para quien construya algo similar: guardar el estado fuera de la sesión, definir issuer, audience y scopes en cada transición de identidad, limitar el catálogo de herramientas por agente, medir el éxito de la tarea y no el del transporte, y mirar desde el principio el almacenamiento en caché del prefijo. Esos puntos le dieron a Bayer tanto el ahorro como la capacidad de control.