Bayer’s Agentic Decision Engine turns a tangled AI stack into a usable chatbot

Bayer’s Agentic Decision Engine turns a tangled AI stack into a usable chatbot

According to Artificial Intelligence, Bayer Crop Science built an Agentic Decision Engine (ADE) on Amazon Bedrock AgentCore to let breeders ask natural‑language questions about their machine‑learning pipelines. The system claims to resolve about 80 % of queries without an engineer and to shrink a typical troubleshooting session from over an hour to under ten minutes.

The problem: data‑rich breeding meets operational opacity

Plant‑breeding teams juggle genomics, field‑trial imagery, weather feeds, and hundreds of model configurations. Bayer already had a Connected Decision Engine (CDE) that could launch and monitor those ML jobs, but the operational stack was a maze of APIs, dashboards, and logs. When a workflow failed, a breeder had to know which system to open, which log to read, and which team to call. The bottleneck shifted from running models to understanding their outcomes.

ADE’s architecture: a four‑layer, multi‑agent stack

ADE sits on top of CDE and is split into:

  1. User experience – a React front‑end protected by Microsoft Entra ID.
  2. Agent orchestration – a LangGraph graph that directs traffic; LangGraph provides explicit, checkpoint‑able control flow for multi‑step interactions.
  3. Specialist agents – 22 agents each scoped to a domain (e.g., troubleshooting, visualization, model documentation).
  4. Tools & data sources – DynamoDB for checkpoint state, Aurora PostgreSQL for session records, ElastiCache for response caching, S3‑stored embeddings indexed in OpenSearch Serverless for Retrieval‑Augmented Generation (RAG), and CloudWatch for telemetry.

The supervisor agent receives a user query, classifies intent, and routes it to the appropriate specialist. AgentCore’s managed runtime isolates each user session, while the AgentCore Gateway enforces IAM‑scoped tool access, keeping authentication out of the agent code. When a specialist needs a tool, it calls the tool via the Model Context Protocol (MCP) – a lightweight JSON‑over‑HTTP contract that lets the agent invoke a REST operation as if it were a function.

Five design decisions that shaped the production system

# Decision What the team did Trade‑off / catch
1 Externalize orchestration state LangGraph checkpoints were written to DynamoDB instead of relying on the runtime’s in‑memory session. Adds latency and cost for DynamoDB writes, but guarantees resumability after scale‑out or crashes.
2 Separate identity layers User identity stays in Entra ID; service‑to‑service calls use IAM; AgentCore Gateway handles downstream tool auth. More token contracts to manage, but isolates failures to a single boundary and avoids over‑privileged tokens.
3 Model selection as an interface contract The team kept the older model version because the newer “reasoning mode” broke structured‑output expectations. Slower inference or higher cost than the latest model, but avoids breaking tool‑calling logic.
4 Control tool surface before it controls the prompt Tools are registered as OpenAPI specs with the gateway and scoped per specialist agent. Smaller token budget per request, but requires careful catalog management and periodic schema updates.
5 Promote complex capabilities from tools to agents Visualization logic moved from a simple tool to its own agent, using Bedrock’s Code Interpreter sandbox for chart generation. More code to maintain, but gains stateful retries, policy handling, and the ability to return pre‑built dashboards when appropriate.

These choices were not vendor hype; they reflected concrete limits of the Bedrock runtime and the needs of a large, regulated organization.

What actually changes for the everyday user

The headline claim – “under ten minutes instead of an hour” – rests on two shifts. First, the supervisor‑specialist routing eliminates the manual log‑hunting step; the Troubleshooting Agent can read CloudWatch telemetry and CDE status in a single API call. Second, the managed runtime guarantees that each request runs in an isolated sandbox, so a buggy specialist does not corrupt another user’s session. In practice this means a breeder can type "Why did my phenotyping workflow fail yesterday?" and get a concise diagnosis within the same UI session, without opening a ticket.

The trade‑off is hidden in the token budget. Each specialist’s tool schema consumes part of the prompt, leaving fewer tokens for the actual question and retrieved context. If a user asks a very detailed question, the system may have to truncate the tool list or the retrieved documents, potentially lowering answer quality. Monitoring that balance requires custom CloudWatch metrics – something Bayer added after an early bug where failed agent steps were still reported as successful HTTP responses.

Who should care and who can ignore it

Breeders and analysts gain immediate productivity: they no longer wait on engineers for a one‑off investigation. Data engineers see a reduction in support tickets but must maintain the agent catalog and the LangGraph orchestration logic. AWS sellers get a showcase of Bedrock AgentCore’s managed runtime, yet the story also highlights that a newer model is not a drop‑in upgrade – a caution for any organization that plans to chase the latest AI model without testing tool compatibility.

Companies that already run multi‑model pipelines and have an internal catalog of APIs may find ADE’s pattern reusable. Organizations that rely on a single model or have no need for natural‑language interaction can skip the multi‑agent overhead.

A quick experiment you can run today

  1. Sign up for an Amazon Bedrock trial and enable AgentCore.
  2. Write a tiny LangGraph graph that routes a user prompt to either a RAG agent (use Titan Text Embeddings V2 on a small S3 bucket) or a tool‑call agent that invokes a public OpenAPI (e.g., a weather API).
  3. Deploy the agents via a GitHub Action that pushes a container image to ECR and lets AgentCore run it.
  4. Add a simple CloudWatch metric that increments on tool_call_error and set an alarm for >0 in a five‑minute window.
  5. Test the system with a question like "What was the temperature in Paris on 2023‑09‑01?" and observe the end‑to‑end latency.
    You’ll see how the isolated runtime, the gateway‑scoped tool catalog, and the checkpoint store interact – the same pieces Bayer relied on, but on a scale you can manage in an afternoon.

Sources

Read next

We count page views without cookies — no identifier, nothing stored on your device. Accept to allow cookies for analytics.