Los 22 agentes de Bayer no ejecutan sus modelos de mejora vegetal. Explican qué ocurrió dentro

Un fitomejorador observa la salida de un modelo para un ensayo de maíz y no coincide con la de la temporada pasada. ¿Los datos de entrada eran distintos? ¿Alguien cambió la configuración? ¿La ejecución falló a mitad de camino y se reinició? Hasta hace poco, en Bayer Crop Science, responder eso significaba encontrar a un ingeniero, que pasaba buena parte de una hora entre APIs, documentación, almacenes de metadatos, dashboards y logs.

Ese es el problema que Bayer describió en un caso de estudio publicado por AWS el 23 de octubre. Es útil estudiarlo porque los agentes que construyó no toman decisiones de mejora vegetal ni ejecutan los modelos. Explican lo que hizo la plataforma existente.

La plataforma ya funcionaba. Entenderla, no

El Connected Decision Engine de Bayer despliega, orquesta y monitoriza workflows de machine learning para la mejora vegetal, con más de 500 configuraciones de modelos entre cultivos, regiones y equipos de investigación. Conserva el historial de ejecuciones y los controles operativos. Sus usuarios son fitomejoradores, analistas, investigadores, científicos de datos e ingenieros de datos.

Ejecutar los workflows ya no era el cuello de botella. Entenderlos, sí. Cada pregunta exigía saber cuál de varios sistemas tenía la respuesta, y quienes lo sabían eran ingenieros cuyo tiempo se iba en explicar en lugar de construir.

La nueva capa: un supervisor y 22 especialistas, todos de solo lectura

El Agentic Decision Engine se sitúa junto a la plataforma existente, no dentro de ella. Un agente supervisor construido con LangGraph clasifica cada pregunta y la dirige a uno de los 22 agentes especialistas, y combina resultados cuando una pregunta abarca varios dominios. Ejemplos: un experto de dominio que busca en la documentación, un agente operativo que lee el estado de los workflows en vivo, un agente de diagnóstico que lee la telemetría de CloudWatch y un agente de visualización que dibuja gráficos en un intérprete de código dentro de un sandbox.

Las decisiones de infraestructura merecen atención:

• Herramientas a través de un gateway. Alrededor de 20 APIs de la plataforma se exponen como herramientas MCP mediante Amazon Bedrock AgentCore Gateway, lo que, según Bayer, redujo la sobrecarga de integración por API en más del 99%.
• Identidad en cada límite. Los usuarios se autentican con Microsoft Entra ID; las llamadas de servicio usan IAM. Cada agente recibe un catálogo de herramientas con alcance limitado: el agente de documentación no puede llamar a APIs de la plataforma que no estén relacionadas.
• Solo lectura por diseño. El agente de diagnóstico “puede leer los datos operativos que necesita para el diagnóstico, pero no puede modificar workflows”.
• Estado fuera del runtime. Los checkpoints de orquestación viven en DynamoDB, no en la sesión del agente.

Bayer reporta que, en la primera fase, el sistema resuelve alrededor del 80% de las preguntas de los usuarios sin un ingeniero, y que diagnosticar un fallo pasó de más de una hora a menos de diez minutos. Son cifras reportadas por el cliente en una historia publicada por el proveedor; el artículo no define “resuelto” ni describe un método de evaluación. Más de 100 usuarios lo han usado en un lanzamiento con acceso restringido.

Cinco decisiones que otros equipos pueden copiar

Las lecciones que Bayer enumera son más transferibles que el diagrama de arquitectura:

1. Persistir el estado de orquestación fuera del runtime. Una sesión que termina no debería llevarse la investigación consigo.
2. Tratar el modelo como un contrato de interfaz. Cuando un modelo más nuevo con un modo de razonamiento rompió el uso de herramientas y la salida estructurada, el equipo mantuvo el actual para el lanzamiento. Una actualización de modelo es un cambio que hay que probar, no un reemplazo directo.
3. Limitar el alcance de las herramientas por agente. Catálogos más pequeños implican menos tokens y menos elecciones erróneas, además de un menor radio de impacto.
4. Convertir una herramienta en agente solo cuando asume estado, reintentos o presentación. No toda capacidad necesita su propio agente; 22 es una consecuencia de los dominios de la plataforma, no un objetivo.
5. Medir el éxito de la tarea, no el éxito del transporte. Un agente que devuelve una respuesta bien formada a la pregunta equivocada es un fallo que los dashboards de disponibilidad nunca mostrarán. Hicimos el mismo planteamiento sobre evaluar lo que hizo un agente, no su resumen.

Por qué la decisión de solo lectura es la verdadera lección

Es tentador leer esto como una historia sobre arquitectura multiagente. Es más útil como una historia sobre dónde empezar. El primer agente en producción sobre un sistema complejo no necesitaba permiso para cambiar nada, así que las preguntas que suelen frenar los proyectos de agentes (quién aprueba una acción, cómo revertirla, quién es responsable) no surgieron. Lo que necesitaba era acceso al historial: metadatos de ejecución, configuración, logs y documentación.

Eso coincide con lo que vemos en agentes de operaciones, cuyo diagnóstico es un punto de partida y no un hallazgo, y en nuestras cinco pruebas para trabajo listo para agentes dentro de procesos existentes. Una capa de explicación es valiosa por sí misma, y además produce la evidencia que cualquiera querría antes de dejar actuar a un agente: qué preguntas responde bien, dónde sus fuentes son escasas y qué datos la plataforma nunca registró. La siguiente fase de Bayer, la interoperabilidad de agentes entre entornos híbridos, pondrá a prueba hasta dónde lleva esa base.