Bayer's 22 agents don't run its plant-breeding models. They explain what happened inside them

A breeder looks at a model output for a corn trial and it doesn’t match last season’s. Was the input data different? Did someone change the configuration? Did the run fail halfway and restart? Until recently, at Bayer Crop Science, answering that meant finding an engineer, who would spend the better part of an hour across APIs, documentation, metadata stores, dashboards and logs.

That is the problem Bayer described in a case study published by AWS on October 23. It is a useful one to study because the agents it built do not make breeding decisions and do not run the models. They explain what the existing platform did.

The platform already worked. Understanding it did not

Bayer’s Connected Decision Engine deploys, orchestrates and monitors machine learning workflows for plant breeding, with more than 500 model configurations across crops, regions and research teams. It keeps execution history and operational controls. Its users are breeders, analysts, researchers, data scientists and data engineers.

Running workflows was no longer the bottleneck. Understanding them was. Each question required knowing which of several systems held the answer, and the people who knew were engineers whose time went to explaining instead of building.

The new layer: a supervisor and 22 specialists, all read-only

The Agentic Decision Engine sits beside the existing platform, not inside it. A supervisor agent built with LangGraph classifies each question and routes it to one of 22 specialist agents, combining results when a question spans domains. Examples: a domain expert that searches documentation, an operational agent that reads live workflow status, a troubleshooting agent that reads CloudWatch telemetry, and a visualization agent that draws charts in a sandboxed code interpreter.

The infrastructure choices are worth noting:

• Tools through a gateway. About 20 platform APIs are exposed as MCP tools through Amazon Bedrock AgentCore Gateway, which Bayer says cut per-API integration overhead by more than 99%.
• Identity at every boundary. Users authenticate with Microsoft Entra ID; service calls use IAM. Each agent gets a scoped tool catalog: the documentation agent cannot call unrelated platform APIs.
• Read-only by design. The troubleshooting agent “can read the operational data it needs for diagnosis but can’t modify workflows.”
• State outside the runtime. Orchestration checkpoints live in DynamoDB, not in the agent session.

Bayer reports that in the first phase the system resolves about 80% of user questions without an engineer, and that diagnosing a failure went from over an hour to under ten minutes. These are customer-reported figures in a vendor-published story; the article does not define “resolved” or describe an evaluation method. More than 100 users have used it in a gated launch.

Five decisions other teams can copy

The lessons Bayer lists are more transferable than the architecture diagram:

1. Persist orchestration state outside the runtime. A session that ends should not take the investigation with it.
2. Treat the model as an interface contract. When a newer model with a reasoning mode broke tool use and structured output, the team kept the current one for release. A model upgrade is a change to test, not a drop-in swap.
3. Scope tools per agent. Smaller catalogs mean fewer tokens and fewer wrong choices, as well as smaller blast radius.
4. Promote a tool to an agent only when it takes on state, retries or presentation. Not every capability needs its own agent; 22 is a consequence of the platform’s domains, not a goal.
5. Measure task success, not transport success. An agent that returns a well-formed answer to the wrong question is a failure that uptime dashboards will never show. We made the same point about grading what an agent did, not its summary.

Why the read-only choice is the real lesson

It is tempting to read this as a story about multi-agent architecture. It is more useful as a story about where to start. The first production agent over a complex system did not need permission to change anything, so the questions that usually stall agent projects (who approves an action, how to roll it back, who is liable) did not arise. What it needed was access to history: run metadata, configuration, logs, documentation.

That matches what we see in operations agents, whose diagnosis is a starting point rather than a finding, and in our five tests for agent-ready work inside existing processes. An explanation layer is valuable on its own, and it also produces the evidence anyone would want before letting an agent act: which questions it answers well, where its sources are thin, and which data the platform never recorded. Bayer’s next phase, agent interoperability across hybrid environments, will test how far that foundation carries.