Bayer Launches Multi-Agent Engine on AgentCore: 80% of Questions Handled Without Engineers

Bayer Crop Science has shown what a production-grade agent layer over an enterprise ML platform looks like. The Agentic Decision Engine (ADE) answers questions from breeders, analysts and data engineers about workflows, models and results. In its first phase, it handles about 80% of requests without an engineer. Diagnosing a failure used to take more than an hour of manual log searching and waiting for help. It now takes less than 10 minutes. Under the hood are 22 specialized agents running on Amazon Bedrock AgentCore.

Why a layer of agents over the platform was needed

Bayer first built the Connected Decision Engine (CDE), a system for deploying, orchestrating, monitoring and reusing ML workflows. Data in plant breeding is heterogeneous: genomics, field trials, imagery, environmental conditions, model outputs. Hundreds of configurations run across crops, regions and teams, and every run has to be reproducible and controlled.

As usage grew, the bottleneck became not execution but understanding. To explain a result, people had to assemble context from APIs, documentation, metadata stores, dashboards and logs. Users had to know which system to look in. ADE removes that requirement: a supervisor classifies the question and routes it to a specialist, which pulls context from the relevant system.

Architecture and five decisions worth remembering

The frontend is built on React, and requests go through a Microsoft Entra ID identity proxy. GitHub Actions builds the agent images, pushes them to Amazon ECR and deploys them to AgentCore Runtime. Orchestration runs on LangGraph, chosen for its explicit control graph and checkpoints for multi-step scenarios. Data is split by responsibility:

• Amazon DynamoDB — LangGraph checkpoints;
• Amazon Aurora PostgreSQL — sessions, feedback, analytics;
• Amazon ElastiCache — a cache of agent responses with TTL;
• Amazon S3 + Titan Text Embeddings V2 + OpenSearch Serverless — RAG over domain content;
• Amazon CloudWatch — runtime and application telemetry;
• AgentCore Gateway — backend APIs as MCP tools, with authentication and authorization kept outside agent code.

The 22 agents include Domain Expert (conceptual questions via RAG), Operational Agent (live status and results from CDE), Troubleshooting Agent (telemetry analysis) and Visualization Agent (charts or ready-made dashboards). A Models as Skill template turns a model's code and documentation into skill descriptions in a central registry, so the agent answers from the actual implementation rather than from general knowledge.

The five design decisions were made together with a technical account manager and a generative AI engineer from AWS Unified Operations:

• State outside the runtime. An AgentCore session holds context for its lifetime, but it is not durable storage. Checkpoints go to DynamoDB so the graph can resume after scaling events and restarts.
• A separate mechanism at each trust boundary. Entra ID handles user identity, IAM handles calls between services, and Gateway outbound authorization handles access to CDE. A Lambda interceptor validates and forwards attributes. The team did not pass a single token across all boundaries.
• The model as an interface contract. The new model version with a reasoning mode did not work with tool use and structured output in the team's agent implementation, so they stayed on the current model.
• Control over the toolset. With 500+ configurations, a separate MCP server for each API would have meant extra deployments and versions. Instead, OpenAPI specifications are registered in Gateway, and tools are assigned per agent. Every tool description consumes input tokens.
• From tool to agent. Visualization grew in scope: it needed its own data retrieval, chart-selection logic, retries and a decision on whether to build a chart or return a ready-made dashboard. The team moved it into a dedicated agent that uses matplotlib and Plotly in AgentCore Code Interpreter (with data exchanged via S3), while ready-made assets are returned from Amazon Quick or Power BI.

Observability, cost and launch

The main trap of multi-agent systems is an HTTP request that succeeds while the answer is wrong. In ADE, exception handlers caught agent errors and returned responses that monitoring counted as successful. The team added custom CloudWatch metrics inside the failure paths, plus alerts for tool-call errors, throttling, model timeouts and structured-output validation failures.

Cost is attributed through three mechanisms: application inference profiles in Bedrock, request metadata with model invocation logging, and attribution by IAM principal. The Visualization and Operational agents consume the most tokens because they make many MCP tool calls. Telemetry revealed a workload with a long, repeating prefix and no prompt caching. Caching the stable instructions and tool descriptions cut input-token costs by 20–30%.

Security is built on least privilege: the Troubleshooting Agent reads operational data but does not modify workflows, and the Domain Expert does not call unrelated CDE APIs. Tool access is read-only, output is validated, and answers rely on CDE data and telemetry. Bayer plans to evaluate Amazon Bedrock Guardrails as an additional layer. Before launch, AWS ran a Critical Workload Review and a Well-Architected review with the Generative AI Lens. Among the findings were gaps in failure visibility between the supervisor and the specialists.

The practical takeaway for anyone building something similar: keep state outside the session, set issuer, audience and scopes at every identity transition, limit the tool catalog per agent, measure task success rather than transport success, and look at prefix caching right away. Those points gave Bayer both its cost savings and its manageability.