Bayer Crop Science Builds Multi-Agent Engine on Amazon Bedrock AgentCore

Bayer Crop Science has built the Agentic Decision Engine (ADE), a multi-agent natural language interface running on Amazon Bedrock AgentCore, and according to AWS it resolves about 80 percent of user questions in its first phase without an engineer in the loop.
- Bayer Crop Science built the Agentic Decision Engine (ADE), a multi-agent natural language interface over its Connected Decision Engine.
- According to AWS, ADE resolves about 80 percent of user questions without an engineer in its first phase.
- ADE runs 22 specialist agents on Amazon Bedrock AgentCore with LangGraph orchestration.
- A troubleshooting diagnosis that took over an hour now takes under 10 minutes, per AWS.
- AWS Unified Operations supplied a Technical Account Manager and a generative AI Domain Specialist Engineer.
From running workflows to understanding them
Bayer Crop Science runs hundreds of machine learning model configurations against data from genomics, field trials, imagery, environmental conditions and model outputs. Each run has to be repeatable and governed. To meet that requirement, Bayer built the Connected Decision Engine (CDE), a system for deploying, orchestrating, monitoring and reusing ML workflows for breeders, analysts, researchers, data scientists and data engineers.
As adoption grew, the bottleneck shifted. Running workflows was no longer the hard part; explaining them was. Users had to piece together context from APIs, documentation, metadata stores, dashboards and logs, and they needed to know which system to inspect to learn why a workflow failed or where a result came from.
ADE is Bayer's answer. A supervisor agent routes each question to a specialist agent, the specialist pulls context from the relevant system, and the user gets an answer without navigating the operational stack.
How ADE is built
ADE runs on Amazon Bedrock AgentCore. According to AWS, three capabilities drove the choice: a managed runtime that isolates each user session, IAM-scoped tool access through AgentCore Gateway that keeps authentication and authorization outside agent code, and a framework-agnostic design that let Bayer bring its own LangGraph orchestration and choice of models.
The system has four layers: the user experience, agent orchestration, specialist agents, and the tools and data sources they call. Users reach ADE through a React web front end, and requests pass through an identity proxy for Microsoft Entra ID. GitHub Actions builds the agent container images, pushes them to Amazon ECR and deploys them to the AgentCore runtime. Bayer chose LangGraph for its explicit graph-based control flow and checkpointing for multi-step workflows.
- State and data: Amazon DynamoDB stores LangGraph checkpoint state, Amazon Aurora PostgreSQL holds session records, feedback and analytics, and Amazon ElastiCache caches agent responses with a time to live.
- Retrieval: Domain content in Amazon S3 is embedded with Amazon Titan Text Embeddings V2 and indexed in Amazon OpenSearch Serverless for RAG.
- Tools: AgentCore Gateway exposes backend APIs to agents as Model Context Protocol (MCP) tools. Amazon CloudWatch captures telemetry.
In production, ADE runs 22 specialist agents, each scoped to one domain. The Domain Expert Agent answers conceptual questions through RAG, the Operational Agent retrieves live workflow status and results from CDE, the Troubleshooting Agent analyzes operational telemetry, and the Visualization Agent generates charts or returns existing dashboards. A customer-specific Models as Skill pattern turns model code and documentation into skill definitions in a central registry, so agents answer from a model's implementation rather than generic model knowledge.
Design decisions and AWS support
Bayer worked with AWS Unified Operations, which provided a designated Technical Account Manager and a generative AI Domain Specialist Engineer. They joined three technical standups each week and took part in design decisions as members of the working team, while Bayer kept ownership of the architecture and the final call.
AWS describes five design decisions from the build. Three are covered in the source text available here:
- Externalize orchestration state. AgentCore runtime sessions preserve context within a session's lifecycle but are not a durable store. ADE writes LangGraph checkpoints to DynamoDB so graphs can resume after scale-out events, restarts or session boundaries.
- Separate identity boundaries. Entra ID remains the source of user identity, IAM authorizes service-to-service calls, and AgentCore Gateway outbound authorization handles access to downstream CDE services. A request interceptor Lambda function performs custom validation. AWS says identity failures in agent systems cluster at the transitions between user, agent and tool identity.
- Treat model selection as an interface contract. Bayer evaluated a newer model version with reasoning mode enabled, but the combination of tool use and structured output that ADE depends on was not compatible with how its agents were implemented. The team kept the current model for the release.
A fourth decision concerns controlling the tool surface. CDE manages more than 500 model configurations, and a dedicated MCP server per API would have added deployment, authentication and version management overhead. ADE instead registers OpenAPI specifications with AgentCore Gateway, which exposes the REST operations as MCP tools.
What it means for users
The practical gain is speed of diagnosis. When a breeder asks why a phenotyping workflow failed, the supervisor routes the question to the Troubleshooting Agent, which reads telemetry in CloudWatch and status from the CDE API through AgentCore Gateway. According to the AWS post, a diagnosis that once took over an hour of manual log-hunting and waiting for engineer support now takes under 10 minutes.
For teams building agent systems on AWS, the case study offers a concrete pattern: persist workflow state outside the runtime, give each trust boundary its own identity mechanism, and check a new model against the full tool-calling interface before swapping it in.


