How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations

extract

Artificial Intelligence How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations Plant breeding decisions depend on data that spans genomics, field trials, imagery, environmental conditions, and model outputs. Bayer Crop Science runs hundreds of machine learning (ML) model configurations against this data across crops, regions, and teams, and each run needs 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. CDE gives breeders, analysts, researchers, data scientists, and data engineers a consistent way to run analytics while preserving execution history and operational controls. As adoption grew, the bottleneck moved from running workflows to understanding them. Explaining a result meant piecing together context from APIs, documentation, metadata stores, dashboards, and logs. A user who wanted to know why a workflow failed, what a model did, or where a result came from still had to know which system to inspect. To close that gap, Bayer built the Agentic Decision Engine (ADE), a multi-agent, natural language interface over CDE. A supervisor agent routes each question to a specialist agent, the specialist retrieves context from the relevant system, and the user receives an answer without navigating the operational stack. In its first phase, ADE resolves about 80 percent of user questions without an engineer in the loop. ADE runs on Amazon Bedrock AgentCore, an AWS service to build, connect, and optimize agents at scale with any framework or model. AgentCore let the team focus on agent behavior instead of building and operating its own agent hosting, session isolation, and tool access layer. Three AgentCore capabilities drove that choice: a managed runtime that isolates each user session, AWS Identity and Access Management (IAM)-scoped tool access through AgentCore Gateway, a capability of Amazon Bedrock AgentCore, that keeps authentication and authorization outside agent code, and a framework-agnostic design that let the team bring its own LangGraph orchestration and choice of models. To prepare for launch and to operate ADE afterward, Bayer engaged AWS Unified Operations. The engagement provided a designated Technical Account Manager (TAM) and a generative AI Domain Specialist Engineer (DSE), who worked as an extension of the ADE team from design through production. The TAM, as Bayer’s strategic advisor, brought an established understanding of Bayer’s operating model and business priorities. The DSE brought generative AI domain expertise on AWS. In three technical standups each week, the team reviewed and made design decisions. The DSE built working knowledge of the ADE workload and how the Bayer team operates, so technical guidance reflected both AWS service behavior and Bayer’s context. This post follows that journey: the ADE architecture, five design decisions made during the build, the work to prepare the platform for production, and how it is operated after launch. Architecture overview ADE is organized into four layers: the user experience, agent orchestration, specialist agents, and the tools and data sources those agents call (Figure 1). Users reach ADE through a React web front end, and requests pass through an identity proxy for Microsoft Entra ID before they reach the agents. GitHub Actions builds the agent container images, pushes them to Amazon Elastic Container Registry (Amazon ECR), and deploys them to AgentCore runtime, a capability of Amazon Bedrock AgentCore. Amazon Bedrock AgentCore runtime hosts the agents, and because the runtime is framework-agnostic, the team runs its own LangGraph-based orchestration on it directly. The team chose LangGraph for its explicit graph-based control flow and checkpointing for multi-step workflows. LangGraph orchestrates the workflow, with a Supervisor Agent as the entry point that classifies each request, selects a specialist, and combines results when a question spans domains. The data plane is separated by responsibility. Amazon DynamoDB stores LangGraph checkpoint state. Amazon Aurora PostgreSQL stores session records, user feedback, and analytics. Amazon ElastiCache caches agent responses with a time to live (TTL). Domain content in Amazon Simple Storage Service (Amazon S3) is embedded with Amazon Titan Text Embeddings V2 and indexed in Amazon OpenSearch Serverless for Retrieval Augmented Generation (RAG). Amazon CloudWatch captures runtime and application telemetry. AgentCore Gateway exposes backend APIs to agents as Model Context Protocol (MCP) tools and keeps authentication and authorization outside agent code. ADE runs 22 specialist agents in production, each scoped to one domain with its own tools and data sources. For example, 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. The Visualization Agent generates charts or returns existing dashboards. A customer-specific Models as Skill pattern converts model code and documentation into skill definitions stored in a central registry, so agents answer model-specific questions from the model’s implementation instead of generic model knowledge. When a breeder asks, “Why did my phenotyping workflow fail yesterday?”, the supervisor classifies the intent and routes the request to the Troubleshooting Agent. That agent reads the workflow’s telemetry in CloudWatch and its status from the CDE API through AgentCore Gateway, identifies the failure point, and returns a diagnosis through the supervisor (Figure 2). The breeder doesn’t search logs directly. With the Troubleshooting Agent, a diagnosis that once took over an hour of manual log-hunting and waiting for engineer support now takes under 10 minutes. Five design decisions on the path to production The Unified Operations TAM and DSE took part in the following decisions as members of the working team, not as an escalation point after the fact. That let Bayer test each design against AWS service behavior before committing to it, while keeping ownership of the architecture and the final call. 1. Externalize orchestration state without treating the runtime as stateless AgentCore runtime provides isolated sessions that preserve execution context across invocations within a session’s lifecycle. That context isn’t a durable store for a multi-step workflow. ADE writes LangGraph checkpoints to DynamoDB so the graph can resume after scale-out events, restarts, or session boundaries without depending on one execution environment remaining available. Principle: Use the runtime session for active execution, and persist the state required to resume or reconstruct the workflow in a durable service. 2. Separate enterprise identity, gateway access, and downstream authorization Bayer standardizes on Microsoft Entra ID for user identity, while ADE’s services authorize each other with AWS-native mechanisms. Rather than force one token across every trust boundary, the team gave each boundary its own mechanism. Entra ID remains the source of user identity. AWS Identity and Access Management (IAM) authorizes service-to-service calls. AgentCore Gateway outbound authorization handles access to downstream CDE services. A request interceptor AWS Lambda function performs custom validation and passes the authorization attributes that downstream tools require. The team worked through the token contract at each hop with the DSE. Principle: Identity failures in agent systems cluster at the transitions between user identity, agent identity, and tool identity. Define the issuer, audience, claims, scopes, and credential lifetime at every hop instead of reusing a token that is valid for one boundary at the next. 3. Treat model selection as an interface contract During the build, the team evaluated a newer model version with reasoning mode enabled. For that version, the combination of tool use and structured output that ADE depends on was not compatible with how its agents were implemented. The DSE confirmed the constraint, and the team retained the current model for the release. Principle: For tool-using agents, model choice is constrained by the full interface: tool calling, structured output, streaming behavior, reasoning features, latency, quota availability, and model-specific request semantics. A newer model is not automatically a drop-in replacement. 4. Control the tool surface before it controls the prompt CDE manages more than 500 model configurations. 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. Adding or changing an API becomes a schema and gateway configuration change instead of a new server deployment. Tool schemas and descriptions also consume input tokens and compete with the user’s request and retrieved context. ADE scopes tools by specialist agent instead of giving every agent the full catalog. For larger catalogs, AgentCore Gateway supports semantic tool search, so an agent can find relevant tools without loading the entire catalog on every turn. Principle: Scope the tool catalog per agent. Every tool definition adds tokens and widens the model’s decision space. 5. Promote complex capabilities from tools to agents Visualization started as a tool invoked by other agents. As it grew, it needed its own data retrieval, chart selection logic, retries, error handling, and a decision about whether to generate a chart or return an existing dashboard. The team moved it into a specialist Visualization Agent. The agent generates on-demand charts with matplotlib and Plotly in AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore that provides a sandboxed code execution environment, and exchanges data with it through Amazon S3. When a prebuilt dashboard is the better answer, the agent returns the existing Amazon Quick or Power BI asset. Principle: A tool performs a bounded operation. When a capability starts to own state, retries, planning, policy, or presentation decisions, model it as an agent. Preparing ADE for production As the build moved toward launch, the focus shifted from design to operability: detecting agent failures, attributing inference cost, and hardening the deployment. Observability: Measure task failures, not only exceptions A supervisor architecture turns one user request into a chain of model calls, tool calls, and agent handoffs. The final answer can be wrong even when every HTTP request succeeded. ADE encountered this directly: application exception handlers caught agent errors and returned responses that monitoring counted as successful. After reproducing the issue with the DSE, the team added custom CloudWatch metrics inside failure paths and alarms on agent-specific conditions: tool call errors, throttling, model timeouts, and structured output validation failures. Traces and invocation logs follow each request across the supervisor and specialists. Principle: Distinguish transport success from task success. Agent observability should show whether the task completed, which agent or tool changed the outcome, and whether the response used the expected source. Cost attribution: Combine billing attribution with request-level telemetry One ADE request can invoke several models and tools, so account-level Amazon Bedrock spend doesn’t explain unit economics. The team designed the attribution approach with the DSE using three mechanisms that answer different questions. Amazon Bedrock application inference profiles attribute billed model usage to an application or workload. Request metadata and model invocation logging associate token usage with a specific agent, feature, or request. IAM principal attribution adds an identity dimension. Together they let the team estimate cost per interaction, identify expensive agents, and determine whether prompts, retrieved context, or tool definitions drive token use. In practice, the Visualization and Operational agents, which rely on MCP tools and multiple tool calls, consumed the most tokens. The same telemetry surfaced a workload during launch preparation with a large repeated input prefix and no prompt cache activity. For supported models, placing stable instructions and tool definitions in a cacheable prompt prefix reduces repeated input processing, which lowers latency and token cost. For ADE, caching the stable prompt prefix cut input-token cost by 20–30 percent. Security and launch readiness IAM roles are scoped to each agent’s responsibility. The Troubleshooting Agent can read the operational data it needs for diagnosis but can’t modify workflows. The Domain Expert Agent can query its retrieval index but cannot call unrelated CDE APIs. In production today, ADE’s agent responses are governed by least privilege, read-only tool access scoped to each agent, structured output validation on agent responses, and answers grounded in retrieved CDE data and telemetry rather than open-ended generation. Bayer also plans to evaluate Amazon Bedrock Guardrails as an additional layer on these controls, complementing the custom safety checks already used in CDE multi-turn workflows. Before launch, Unified Operations ran a Critical Workload Review and a Well-Architected review with the Generative AI Lens alongside the ADE team. Because the DSE already knew the workload, both reviews targeted ADE’s specific failure modes, capacity risks, and deployment gaps rather than generic best practices. Findings included gaps in failure visibility across the supervisor and specialist agents, mutable container image tags, limited image traceability, and missing vulnerability scanning. The team responded with stronger alarms, immutable versioned images, scan on push in Amazon ECR, and lifecycle policies for unused images. The DSE also reviewed scaling and quota requirements with the team. Load testing validated both the application and its service quotas and exposed a networking failure mode that returned empty responses, which the team fixed before the production event. By launch, the team had tracked 35 blockers to resolution with Unified Operations. Launch, operations, and next steps Bayer launched ADE to a gated group rather than opening it to the whole organization at once. Since launch, more than 100 users across Bayer Crop Science have used ADE, including breeders, analysts, researchers, data scientists, and engineers. Alongside its 22 specialist agents, ADE exposes about 20 API tools and can host third-party agents as it expands. Exposing those APIs through AgentCore Gateway rather than a dedicated server per API cut per-API integration overhead by more than 99 percent. In its first phase, ADE has resolved about 80 percent of user questions without an engineer in the loop. CDE remains the governed execution layer for analytics. ADE adds a natural language layer over it, so users can ask about workflow status, results, model behavior, and failures without learning the location or interface of each underlying system. The engagement then shifted from launch readiness to ongoing operations. The DSE continues to meet with the team, so issue triage and operational reviews start from existing knowledge of ADE instead of a new ramp-up. ADE’s critical CloudWatch alarms, including the agent-specific alarms described earlier, are onboarded to AWS Incident Detection and Response. When one fires, AWS Incident Management Engineers engage within 5 minutes and start from the workload’s context rather than from scratch. On the security side, AWS Security Incident Response engineers support the team during potential or active security events, so ADE has AWS monitoring and response coverage for both operational and security issues. With agent-to-agent communication already in place, Bayer is focusing next on hybrid cloud agent interoperability. The team is exploring how agents running in different environments can discover and communicate with each other without manual configuration. Conclusion Bayer didn’t replace its analytics platform with ADE. It made CDE easier to query and operate. Most of the production work sat outside the prompts: durable state, identity boundaries, tool scoping, task-level observability, cost attribution, and launch readiness. Bayer owned the architecture and each of those decisions. Working with a designated DSE and TAM through AWS Unified Operations, the team tested those decisions against AWS service behavior during design and carried the same context into production. To learn more, explore Amazon Bedrock AgentCore, Amazon Bedrock cost attribution, AWS Well-Architected Generative AI guidance, and AWS Unified Operations. The authors would like to thank Sijie Shi, Jorge Gomes, Naveen Reddy, Iago Fonseca, Mateus Silva, and Sushimitha Jarugula for their contributions to the design, development, and launch of ADE.