拜耳作物科学如何基于 Amazon Bedrock AgentCore 与 AWS 统一运营构建 Agent 决策引擎

植物育种决策依赖于涵盖基因组学、田间试验、图像、环境条件以及模型输出的多维度数据。拜耳作物科学（Bayer Crop Science）跨作物、区域和团队针对这些数据运行着数百种机器学习（ML）模型配置，且每次运行都必须具备可重复性与治理合规性。为满足这一需求，拜耳构建了互联决策引擎（Connected Decision Engine，CDE），这是一个用于部署、编排、监控和复用 ML 工作流的系统。CDE 为育种家、分析师、研究人员、数据科学家和数据工程师提供了一致的分析运行方式，同时完整保留执行历史记录和运维管控能力。

随着系统被广泛采用，瓶颈从“运行工作流”转移到了“理解工作流”。解释一个分析结果，往往意味着需要从 API、文档、元数据存储、仪表板和日志中拼凑上下文。当用户想要知道某个工作流为何失败、模型执行了什么操作或结果源自何处时，仍然必须清楚具体去检查哪一个系统。为了消除这一鸿沟，拜耳构建了智能体决策引擎（Agentic Decision Engine，ADE），这是基于 CDE 构建的多 Agent 自然语言交互界面。由一个主管 Agent（Supervisor Agent）将每个问题路由给对应的专职 Agent，专职 Agent 从相关系统中检索上下文，最终用户无需在复杂的运维技术栈中来回穿梭即可获得答案。在第一阶段，ADE 在无需人工工程师介入的情况下解决了约 80% 的用户问题。

ADE 运行在 Amazon Bedrock AgentCore 之上，这是一项用于通过任意框架或模型大规模构建、连接和优化 Agent 的 AWS 服务。借助 AgentCore，团队得以专注于 Agent 本身的行为逻辑，而无需从零构建和维护底层的 Agent 托管、会话隔离与工具访问层。促成这一技术选型的关键在于 AgentCore 的三项能力：隔离每个用户会话的托管运行时；通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）实现受 AWS Identity and Access Management (IAM) 作用域限制的工具访问，从而将认证和授权逻辑保留在 Agent 代码之外；以及与框架无关的设计，允许团队集成自研的 LangGraph 编排机制并自由选择模型。

为了筹备系统上线及后续的运营运维，拜耳引入了 AWS Unified Operations。该服务为拜耳配备了一名专属技术客户经理（TAM）和一名生成式 AI 领域专家工程师（DSE），他们从系统设计到生产落地全程作为 ADE 团队的延伸成员协同工作。TAM 作为拜耳的战略顾问，深入理解拜耳的运营模式与业务优先级；DSE 则带来了 AWS 上的生成式 AI 领域专业知识。在每周三次的技术站会中，联合团队共同评审并制定设计决策。DSE 深度熟悉了 ADE 工作负载及拜耳团队的运作方式，确保所提供的技术指导既契合 AWS 服务底层行为，又紧密贴合拜耳的业务上下文。本文将详细回顾这一历程：ADE 架构、构建过程中制定的五大设计决策、面向生产环境的平台准备工作，以及上线后的运维实践。

架构概览

ADE 划分为四个层级：用户体验层、Agent 编排层、专职 Agent 层，以及这些 Agent 所调用的工具与数据源层（图 1）。用户通过 React Web 前端访问 ADE，请求在到达 Agent 之前需通过基于 Microsoft Entra ID 的身份代理。GitHub Actions 负责构建 Agent 容器镜像，将其推送到 Amazon Elastic Container Registry (Amazon ECR)，并部署至 Amazon Bedrock AgentCore 的核心功能——AgentCore runtime。

Amazon Bedrock AgentCore runtime 负责托管 Agent。由于该运行时与具体开发框架无关，团队可以直接在其上运行基于 LangGraph 的自研编排逻辑。团队选择 LangGraph 是看重其明确的基于图的控制流，以及针对多步骤工作流的检查点（checkpointing）机制。LangGraph 负责编排整个工作流，Supervisor Agent 作为统一入口，负责对每个请求进行意图分类、选择专职 Agent，并在问题涉及多个领域时聚合结果。数据平面则按职责进行了分离：Amazon DynamoDB 用于存储 LangGraph 的检查点状态；Amazon Aurora PostgreSQL 存储会话记录、用户反馈和分析指标；Amazon ElastiCache 负责对 Agent 响应结果设置生存时间（TTL）缓存；存储在 Amazon Simple Storage Service (Amazon S3) 中的领域内容通过 Amazon Titan Text Embeddings V2 进行向量嵌入，并索引至 Amazon OpenSearch Serverless 中以实现检索增强生成（RAG）；Amazon CloudWatch 负责采集运行时与应用级遥测数据；AgentCore Gateway 则将后端 API 以模型上下文协议（Model Context Protocol，MCP）工具的形式暴露给 Agent，并确保认证与鉴权逻辑始终独立于 Agent 代码之外。

图 1：基于 Amazon Bedrock AgentCore 的智能体决策引擎架构

ADE 在生产环境中运行着 22 个专职 Agent，每个 Agent 的作用域被限定在单一领域，拥有专属的工具和数据源。例如，领域专家 Agent（Domain Expert Agent）通过 RAG 回答概念性问题；运维 Agent（Operational Agent）从 CDE 检索实时工作流状态与结果；故障排查 Agent（Troubleshooting Agent）负责分析运维遥测数据；可视化 Agent（Visualization Agent）用于生成图表或返回既有仪表板。此外，拜耳定制的“模型即技能”（Models as Skill）模式将模型代码和文档转化为存储在中央注册表中的技能定义，使 Agent 能够依据模型的具体实现细节回答针对性问题，而非依赖宽泛泛化的模型常识。

当育种家询问“为什么我的表型分析工作流昨天运行失败了？”时，主管 Agent 会对意图进行分类，并将请求路由给故障排查 Agent。该 Agent 通过 AgentCore Gateway 读取 CloudWatch 中的工作流遥测数据以及来自 CDE API 的状态，定位故障点，并通过主管 Agent 返回诊断结果（图 2）。育种家无需亲自手动翻查日志。借助故障排查 Agent，以往需要耗费超过一小时的人工日志排查及等待工程师支持的诊断流程，现在可以在 10 分钟以内完成。

图 2：ADE 请求流程：意图分类、缓存查询、专职 Agent 路由与响应生成

迈向生产环境的五大设计决策

Unified Operations 的 TAM 和 DSE 作为工作团队的核心成员参与了以下决策，而非事后才介入的升级支持角色。这使得拜耳在正式采用前能够对照 AWS 服务底层行为充分验证每种设计方案，同时保持对整体架构的主导权和最终决策权。

1. 将编排状态外部化，同时不将运行时视为无状态

AgentCore runtime 提供了隔离的会话环境，可以在会话生命周期内的多次调用之间保留执行上下文。然而，这种上下文并不能作为多步骤工作流的持久化存储。ADE 将 LangGraph 的检查点持久化写入 DynamoDB，使得工作流执行图在经历横向扩缩容事件、重启或跨出会话边界时仍能平滑恢复，而不依赖于单一执行环境的持续在线。

原则： 将运行时会话用于当前活跃执行，而将恢复或重建工作流所需的状态持久化到高可用持久化服务中。

2. 分离企业身份、网关访问与下游授权

拜耳在用户身份层面统一采用 Microsoft Entra ID，而 ADE 的内部服务之间则通过 AWS 原生机制进行授权。团队并未强行在每个信任边界间传递同一个 Token，而是为每个边界设计了独立的机制。

Entra ID 始终作为终端用户身份的源头；AWS Identity and Access Management (IAM) 负责服务到服务调用的鉴权；AgentCore Gateway 的出站授权机制负责处理对下游 CDE 服务的访问；请求拦截器 AWS Lambda 函数执行自定义验证，并传递下游工具所需的授权属性。团队与 DSE 深入推敲了每一跳通信链路中的 Token 契约细节。

原则： Agent 系统中的身份认证故障多集中在用户身份、Agent 身份与工具身份之间的转换节点。应在每一跳明确定义签发者（issuer）、受众（audience）、声明（claims）、范围（scopes）及凭据有效期，而不是将适用于某一边界的 Token 直接复用到下一个边界。

3. 将模型选择视为接口契约

在构建过程中，团队曾评估开启了推理模式（reasoning mode）的较新版本模型。然而在该版本中，ADE 所依赖的工具调用（tool use）与结构化输出（structured output）组合与既有 Agent 的实现方式并不兼容。DSE 确认了这一约束限制，团队最终决定在首发版本中保留当前既有模型。

原则： 对于依赖工具调用的 Agent，模型选型受完整接口契约的约束：包括工具调用、结构化输出、流式行为、推理特性、延迟表现、配额可用性以及模型特定的请求语义。版本更新的模型并不自然等同于开箱即用的直接替代品。

CDE 管理着超过 500 种模型配置。若为每个 API 单独部署专用 MCP 服务器，将带来巨大的部署、身份验证和版本管理开销。ADE 改为将 OpenAPI 规范注册到 AgentCore Gateway，由后者统一将 REST 操作暴露为 MCP 工具。如此一来，新增或变更 API 仅需修改 Schema 及网关配置，而无需部署新的服务器。

此外，工具的 Schema 和描述信息同样会消耗输入 Token，并与用户的请求输入及检索到的上下文竞争上下文窗口。ADE 按照专职 Agent 划分工具作用域，避免为每个 Agent 都提供全局工具全量目录。对于规模更大的目录，AgentCore Gateway 提供了语义工具搜索能力，使得 Agent 在每轮交互中无需加载全量目录即可精确找到相关工具。

原则： 按 Agent 划分工具目录范围。每一个工具定义都会占用 Token 预算，并扩大模型的决策空间。

可视化最初只是作为被其他 Agent 调用的普通工具存在。但随着功能演进，它需要具备独立的数据检索、图表选型逻辑、重试机制、错误处理能力，并需要自主决策是动态生成图表还是直接返回既有仪表板。于是团队将其升级为一个独立的专职可视化 Agent。该 Agent 借助 AgentCore Code Interpreter（Amazon Bedrock AgentCore 提供的一种沙箱化代码执行环境功能），通过 matplotlib 和 Plotly 按需生成图表，并通过 Amazon S3 交换数据。而当预置仪表板能提供更佳答案时，该 Agent 则直接返回既有的 Amazon QuickSight 或 Power BI 资产。

原则： 工具应当只执行有界操作。当某项能力开始管理状态、重试机制、执行规划、业务策略或呈现决策时，应将其抽象建模为独立的 Agent。

ADE 的生产就绪准备

随着构建逐步进入上线阶段，团队的工作重心由架构设计转向了可运维性建设：检测 Agent 任务失败、归因推理成本以及强化部署环境。

可观测性：衡量任务失败，而不仅仅是捕获异常

在主管 Agent 架构下，单一用户请求会被展开为一系列由模型调用、工具调用和 Agent 移交组成的调用链。在这种情况下，哪怕底层每一个 HTTP 请求的状态码都是成功的，最终交付给用户的答案仍可能是错误的。ADE 在早期就遇到了此类问题：应用程序的异常处理程序捕获了 Agent 内部错误并返回降级响应，监控系统却将其误记为成功调用。与 DSE 共同复现该问题后，团队在失败执行路径中埋设了自定义 CloudWatch 指标，并针对 Agent 特有异常配置了告警机制：工具调用错误、限流拦截（throttling）、模型超时以及结构化输出校验失败。全链路追踪（Traces）与调用日志完整贯穿了请求在主管 Agent 与各专职 Agent 间的全生命周期。

原则： 明确区分传输层成功与任务层成功。Agent 的可观测性体系必须清晰呈现任务是否真正完成、具体由哪个 Agent 或工具导致了异常结果，以及最终响应是否采用了符合预期的权威信源。

成本归因：结合计费归因与请求级遥测

单个 ADE 请求可能会调用多个模型和外部工具，因此仅凭账户级别的 Amazon Bedrock 账单支出无法解释单元经济模型（unit economics）。团队与 DSE 共同设计了多维归因方案，通过三套机制回答不同维度的成本问题：Amazon Bedrock 应用推理配置文件（application inference profiles）将已计费的模型用量归属到特定应用或工作负载；请求元数据与模型调用日志将 Token 消耗精确绑定到具体的 Agent、功能模块或单次请求；IAM 主体归因则补充了身份维度的消费视图。三者结合，让团队能够精准估算单次交互成本、定位高消耗 Agent，并研判 Token 消耗究竟是由提示词、检索上下文还是工具定义所驱动。在生产实测中，重度依赖 MCP 工具及高频多轮工具调用的可视化 Agent 与运维 Agent 消耗的 Token 占比最高。

同样的遥测体系在上线准备阶段还捕获了一类特殊负载：其包含大量重复的输入前缀，却未命中 Prompt 缓存。对于受支持的模型，将静态指令与工具定义置于可缓存的 Prompt 前缀中，可显著减少重复输入处理开销，进而降低延迟与 Token 费用。在 ADE 的实际应用中，对静态 Prompt 前缀实施缓存成功削减了 20% 至 30% 的输入 Token 成本。

安全性与上线就绪

IAM 角色严格按每个 Agent 的职责范围进行权限收敛与隔离。故障排查 Agent 可以...

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.

Figure 1: Agentic Decision Engine architecture on Amazon Bedrock AgentCore

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.

Figure 2: ADE request flow: intent classification, cache lookup, specialist routing, and response

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.

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.

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.

---

About the authors

Subbu Dandamudi

Subbu is Head of MLOps for R&D at Bayer. He leads the development of scalable platforms and AI capabilities and has played a key role in building the Connected Decision Engine (CDE) and its evolution into the Agentic Decision Engine (ADE) to accelerate AI-driven innovation across R&D.

Dr. Leo de Melo

Leo is a Staff ML Engineer at Bayer Crop Science, where he helps shape the future of AI-powered R&D through scalable platforms, agentic systems, and advanced analytics. With a background in Computer Science and Computational Mathematics, he specializes in building AI and data platforms that enable researchers to transform complex data into actionable insights and accelerate scientific discovery.

Mahnoor Hussain

Mahnoor is a Senior Solutions Architect specializing in Generative AI and cloud architecture. She helps customers operationalize GenAI by translating emerging capabilities into production-ready solutions across agentic systems, governance, security, and cloud operations. Her work focuses on helping organizations move from experimentation to enterprise adoption. Outside of work, Mahnoor enjoys spending time with family and traveling.

Ram Pamidimukkala

Ram is a Senior Technical Account Manager at AWS, specializing in Generative AI, agentic workloads, data analytics, multi-cloud, and cloud operations. He helps organizations design, modernize, and migrate workloads to the AWS Cloud efficiently and securely. As part of Unified Operations his work focuses on building resilient architectures that balance performance, cost optimization, and long-term sustainability.

Sai Pavan Kasani

Sai is a Domain Specialist Engineer for Generative AI at AWS. As a technical advisor and customer advocate, he helps teams move generative AI proofs of concept into production, with particular focus on agentic AI workloads. He also works with customers on inference optimization and cost efficiency as their generative AI applications scale. Outside of work, Sai enjoys exploring new coffee shops and spending time with family.