人工智能
拜耳作物科学公司如何在Amazon Bedrock Agent Core上建造了具有AWS统一操作的代理决策引擎
植物育种决定取决于涉及基因组学、实地试验、图像、环境条件和模型产出的数据。 Bayer Crop Science根据这些数据在作物，区域和团队中运行了数百个机器学习(ML)模型配置，每个运行需要重复和规范。 为了满足这一要求，拜耳公司建立了连接决策引擎(CDE)，这是一个用于部署、协调、监测和再利用ML工作流程的系统。 CDE给予育种者，分析者，研究人员，数据科学家，以及数据工程师一个一致的方法来进行分析，同时保留执行历史和操作控制。
随着收养的增长，瓶颈从运行工作流程转向理解它们。 解释一个结果意味着从API、文档、元数据储存、仪表板和日志中将上下文拼凑在一起。 一个用户想知道一个工作流程为什么会失败，一个模型做了什么，或者结果从何而来，仍然需要知道要检查哪个系统。 为了缩小这一差距，拜耳在CDE上建造了代理决策引擎(ADE)，这是一个多agent，自然语言界面。 一名主管agent将每个问题分别传递给一名专家agent，专家从相关系统检索上下文，用户得到一个答案而不导航操作堆栈。 在第一阶段，ADE解决了大约80%的用户问题，没有工程师参与循环。
ADE运行在Amazon Bedrock Agent Core,AWS服务上，以任何框架或模型的规模构建，连接，并优化agents. Agent Core让团队专注于agent的行为，而不是建立和运行自己的agent托管，会话隔离，以及工具访问层。 三种AgentCore能力驱动了这一选择：一个管理下的运行时间将每个用户会话隔离，AWS身份和访问管理(IAM)-扫描工具通过AgentCore Gateway访问，一个Amazon Bedrock AgentCore的能力将认证和授权保留在agent代码之外，以及一个框架-不可知的设计，让团队带来自己的LangGraph编曲和模型的选择。
为了做好发布的准备，并在之后运行ADE，拜耳参与了AWS统一操作。 聘用人员包括一名指定的技术账户管理人和一名基因化的AI域专家工程师(DSE)，他们从设计到生产都是ADE团队的延伸。 TAM作为拜尔的战略顾问，对拜尔的经营模式和业务重点有了既定的理解。 DSE带来了关于AWS的基因AI域专业知识。 在每周三次技术性对峙中，小组审查并作出设计决定。 DSE构建了ADE工作量和Bayer团队如何运作的工作知识，因此技术指导既反映了AWS服务行为，也反映了Bayer的背景。 此帖沿用了这一旅程：ADE架构，建设期间作出的5项设计决定，制作平台的准备工作，以及发布之后如何运行。
结构概览
ADE分为四层：用户体验，agent管弦乐，专家agents，以及agents调用的工具和数据来源(图1). 用户通过React网络前端到达ADE，请求在到达agents之前通过Microsoft Entra ID的身份代理。 GitHub动作制造agent容器图像，将其推至Amazon弹性容器注册处(Amazon ECR)，并将其部署到Agent Core runtime，这是Amazon Bedrock Agent Core的能力。
Amazon Bedrock Agent Core runtime主机agents，由于运行时间是框架-不可知的，因此球队直接在它上运行自己的基于LangGraph的管弦乐。 团队选择了LangGraph来进行其明确的基于图表的控制流量和对多步工作流程的检查。 LangGraph主持工作流程，由主管Agent作为切入点，对每个请求进行分类，选择一名专家，并在一个问题跨越域时综合结果。 数据平面由责任分离。 Amazon DynamoDB商店朗格拉夫检查站州。 Amazon Aurora PostgreSQL存储会话记录，用户反馈，以及分析。 Amazon ElastiCache 缓存 agent 响应有时间存在(TTL). Amazon简单存储服务(Amazon S3)中的域内容与Amazon Titan文字嵌入V2并索引为Amazon OpenSearch Serverless，用于检索增强生成(RAG). Amazon Cloud Watch捕捉运行时间和应用遥测。 Agent Core Gateway将后端API暴露于agents作为模型上下文协议(MCP)工具，并在agent代码之外保持认证和授权。
ADE在生产中运行着22个专家agents，每个范围都以自己的工具和数据源为一个域。 例如域专家Agent通过RAG解答概念问题。 业务Agent检索到现场工作流程状态和CDE结果。 Agent故障解析操作遥测。 可视化Agent生成图表或返回现有的仪表板。 作为技能模式的客户特异性模型将模型代码和文件转换为存储在中央登记册中的技能定义，因此agents解答了模型执行中而不是通用模型知识中的特定模型问题。
当一个育种者问到“昨天我的工作流程为何失败？” 时，主管将意图归为一类，并将请求引向“解决Agent问题”。 agent通过代理Core Gateway从CDE API读取工作流程在Cloud Watch中的遥测及其状态，识别故障点，并通过主管返回诊断(图2). 繁殖者不直接搜索日志。 Agent的诊断一次用了一小时的人工采集日志等待工程师的支持现在需要不到10分钟
关于生产之路的五项设计决定
TAM和DSE统一行动作为工作组成员参与了下列决定，而不是事后的升级点。 这让拜尔在承诺之前，先对AWS服务行为进行每个设计测试，同时保留架构和最终调用的所有权。
1. 将管弦乐状态外部化而不将运行时间视为无国籍状态
AgentCore 运行时间提供孤立的会话，在会话的周期内保存执行语境。 这并非多步骤工作流程的持久储存。 ADE将LangGraph检查站写到DynamoDB，这样图就可以在扩展事件、重启或会话边界之后恢复，而不取决于一个执行环境。
原则：使用运行时间会话进行主动执行，并坚持在持久服务中恢复或重建工作流程所需的状态。
2. 单独的企业身份、网关接入和下游授权
Bayer在Microsoft Entra ID上实现用户身份标准化，而ADE的服务则以AWS-内在机制相互授权。 小组没有强行跨越每一个信任边界，而是赋予每一个边界自己的机制。
Entra ID仍然是用户身份的来源。 AWS身份和访问管理(IAM)授权服务呼叫。 Agent Core Gateway外出授权处理下游CDE服务的访问。 请求截取器AWS Lambda功能进行自定义验证，并传递下游工具所需的授权属性。 球队通过每一次跳台的象征性合同与DSE合作。
原理：在用户身份，agent身份和工具身份之间的过渡中，agent系统集群中的身份失败。 定义每跳一次的发行者，观众，声称，瞄准镜，和证书寿命，而不是重用对下一个边界有效的符号。
3. 将模型选择视为接口合同
在建设期间，团队评价了较新的模型版本，并启用了推理模式。 对于该版本，ADE所依赖的工具使用和结构化输出的组合与其agents的实现方式不兼容。 DSE确认了限制，团队保留了当前发布模式。
原理：对于工具使用agents，模型选择受到全接口的限制：工具调用，结构化输出，流动行为，推理特征，耐久性，配额可用性，以及模型特定请求语义。 较新的模型不是自动的即时替换。
4. 控制工具表面，然后控制提示
CDE管理超过500个模型配置。 每个API配备一个专用的MCP服务器将增加部署、认证和版本管理费。 ADE转而将OpenAPI规格与Agent Core Gateway注册，这暴露了REST操作作为MCP工具。 添加或更改一个 API 成为一个图案和网关配置变化，而不是一个新的服务器部署。
工具的图案和描述也会消耗输入符，与用户的请求和检索上下文竞争。 ADE 瞄准镜工具由专家 agent 而不是给每个 agent 完整的目录。 对于更大的目录，Agent Core Gateway支持语义工具搜索，因此agent可以找到相关的工具，而不在每个回合上加载整个目录。
原理：工具目录范围为每agent. 每个工具定义新增符号并拓宽模型的决定空间。
5. 促进从工具到agents的复杂能力
可视化开始作为其他agents引用的工具。 随着它的成长，它需要自己的数据检索，图表选择逻辑，重试，错误处理，以及决定是否生成图表还是返回现有的仪表板。 团队将其移动至专业视觉Agent. agent在AgentCore Code International中以matplotlib和Plotly生成点播图，这是Amazon Bedrock AgentCore提供沙箱代码执行环境的能力，并通过Amazon S3与其交换数据。 当一个预建的仪表板是更好的答案时，agent返回现有的Amazon快速或Power BI资产。
原则：一个工具执行有界限的操作。 当一个能力开始拥有状态，重试，规划，政策，或演示决定时，将其模拟为agent.
准备ADE生产
随着建筑向发布移动，重心从设计转向可操作性：发现agent故障，将推论成本归结为推论成本，并硬化部署。
观察性：衡量任务失败，而不仅仅是例外
一个主管架构将一个用户请求变成一个模型调用，工具调用，和agent交接的链条。 即使每个HTTP请求都成功，最后的答案也可能是错误的。 ADE直接遇到这一点：应用程序例外处理器捕获了agent错误，并返回了被监测算成成功的响应。 在与DSE重现这个问题后，团队在agent特定条件下添加了自定义的Cloud Watch 度量衡和提醒：工具调用错误，节奏，模型超时，以及结构化的输出验证失败。 追踪和引用记录在主管和专家的每一个请求之后。
原则：将运输成功与任务成功区分开来。 Agent可观察性应显示任务是否完成，哪个agent或工具改变了结果，以及响应是否使用了预期的来源。
费用归属：将收费归属与请求一级的遥测相结合
一个ADE请求可以引用几个模型和工具，所以账户级的Amazon Bedrock支出并不能解释单位经济学。 团队与DSE一起设计了归属方法，使用三种机制回答不同的问题。 Amazon Bedrock应用推论将计费模型的使用归属于应用程序或工作量。 请求元数据和模型引用 loging 关联符使用，并带有特定的 agent，特性，或请求。 IAM 主要归属新增 a
本文由 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 Atlas. All rights belong to the original author.