Bayer Crop Science在Amazon Bedrock Agent Core和AWS统一操作上建造了代理决策引擎。

中文版正在随流水线自动整理，稍后刷新即可；可先阅读下方英文原文。

本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

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

Auto-fetched and translated by AI Gem Box. All rights belong to the original author.