Bayer Crop Science runs hundreds of machine-learning configurations across breeding programmes, imagery and environmental data. Running those workflows created another problem: explaining why one failed. Its Agentic Decision Engine now lets researchers ask about a run in ordinary language, sending specialist agents to the relevant logs and APIs. Bayer and AWS report that diagnoses which once required more than an hour of investigation and waiting can take under ten minutes.[1]
Their technical account, published on 23 October, describes 22 specialist agents in production, around 20 API tools and more than 100 users in a gated rollout. About 80 percent of first-phase questions were resolved without an engineer, the companies say. The account does not disclose the number or difficulty of those questions, so the figure is best read as a reported operational result.[1]
The old analytics engine remains in charge
Bayer production deployment
| Measure | Value | Context |
|---|---|---|
| Specialist agents | 22 | |
| Approximate tool APIs | 20 | |
| Gated users | More than 100 | |
| Questions reportedly resolved without engineers | About 80% |
Bayer's Connected Decision Engine, or CDE, already manages repeatable machine-learning activity across crops, environmental data, imagery and breeding programmes. The newer Agentic Decision Engine, or ADE, sits above it. A supervisor reads the user's request and routes it to an appropriate specialist: one that knows domain concepts, another that retrieves operational status, another that inspects troubleshooting telemetry, and one that displays charts or existing dashboards. It is a natural-language control and explanation layer, not an announcement that a chatbot now makes autonomous planting or breeding decisions.[1]
Consider a breeder asking why a phenotyping workflow failed yesterday. The supervisor selects the troubleshooting agent. That agent requests workflow status through the CDE API and relevant logs through AWS CloudWatch, then provides a diagnosis. This is different from giving a general model the job of guessing why a process might fail. The answer should derive from a named run, tool results and a traceable operating environment. Model-specific skills are registered using actual implementation code and documentation, making answers less dependent on what a language model remembers about similar software elsewhere.[1]
The design also separates what tools may do from what agents may decide. A bounded API can retrieve a workflow result. A specialist agent is responsible for planning how to use that API, interpreting errors and choosing how to present its findings. Access remains constrained through AWS identity permissions and Amazon Bedrock AgentCore Gateway. The aim is that a request for information should not quietly become permission to alter production analytics or access unrelated research.[1]
A successful HTTP call is not a successful answer
One of the most instructive problems arose in monitoring. The system's exception handlers sometimes caught agent failures and returned a response that ordinary HTTP monitoring considered successful. A dashboard of green requests could therefore hide unsuccessful user tasks. The team added agent-specific measurements for tool-call errors, throttling, timeouts and malformed outputs, together with traces spanning the supervisor and its specialists. The distinction is fundamental: uptime and application correctness are different properties.[1]
A multi-step agent must also survive changes in its runtime. Bayer uses LangGraph checkpoints stored in DynamoDB, rather than assuming a temporary execution session will retain the state of a long workflow after restarts or scaling. Cost presents another operational challenge: one user's question can trigger multiple models and retrieval operations. Request-level token records and billing attribution are needed to find which activity is driving cost. AWS says the operational and visualisation specialists were among the heavier token users.[1]
The most revealing design choice is what counts as success. Bayer had to distinguish a healthy server response from a useful answer to a scientist’s question. Its agents make the existing analytics platform easier to interrogate; their value depends on reaching the right evidence and recognising when the task has failed.[1]
Sources & further reading
- How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations Bayer Crop Science and AWS · 23 Oct 2026 · Accessed 26 Oct 2026