人工智能
Amazon Bedrock Agent Core上建一个代理AI平台
若你想让agent投入生产，主要瓶颈是周围的一切：有多少团队可以在安全的环境中建设，哪个团队拥有每个模型和工具，AgentOps和错误处理如何停留在预先确定的边界内，以及平台，工作流，和财务团队如何看待跨账户的成本和健康。 对于一个希望支持许多代理使用案例的平台团队，这是一个设计和运行的平台产品。 在此帖子中，我们将管理平台的团队称为平台团队，并将在此基础上建立的团队称为工作流团队。 工作流团队是在平台上建立和拥有agents的域或产品团队。
每个工作流小组都需要铺设一条道路，包括经核准的模型和工具、短期工作量识别、孤立运行时间和内存、自动评价、回滚、遥测和成本归属。 随着工作流团队自定义提示，工具，数据访问和应用行为，这些控制需要保持一致性。 每个团队集合后，控制漂移，共享服务成为瓶颈，所有权难以审计。
在这个帖子中，我们走过Amazon Bedrock和Amazon Bedrock Agent Core上的企业代理AI平台的架构和参考执行。 我们覆盖多账户操作模式，平台控制平面，可重复的每个工作流部署模式，单独的推论和工具网关，以及一个在晋升到生产前将每个agent打开的评价管道。 最终，您应该能够从配套蓝图中部署一个受管理的工作流，验证其安全和生命周期合同，并将其作为您自己在组织中的代理AI平台的基础。
Amazon Bedrock Agent Core为agents规模的建设，部署和运行提供模块化服务，包括运行时间，网关，身份，内存，政策，注册和评价。 企业代理AI平台蓝图以代理Core，新增为基础，将周围企业合同作为可部署的基础设施作为代码：所有权、账户界限、软件交付、可观察性、成本治理和退休。
建筑原则
在潜入解决方案细节之前，它有助于理解驱动平台架构的组织需求。 我们从客户那里听到的建立agent平台的共同挑战属于这五个类别：
- 管理模式访问：所有不可信的推断请求都必须通过一个核准的推断网关。 该网关应用组织的护栏(例如Amazon Bedrock Guardrails或第三方供应商)，限制每个工作流可以使用的AWS区模型和推论，并强制执行每个工作流的费率限制、象征性配额和预算，以使任何单一团队都无法耗尽共享能力。 该系统还载有工作量识别和归属数据。
- 管理工具访问：Agents必须通过经认证的示范背景协议(MCP)网关，发现和援引经批准的工具，并有确切的目标、最低优先的执行作用、政策决定和可审计的所有人。
- 委托交付：工作流程团队(如产品团队)需要在预先批准的边界内独立运送和回滚，而不必等待平台团队部署每个应用程序或给予开发者直接的基础设施写路径。
- 车队业务和费用：有几个人需要各账户的能见度，而无需书面查阅团队工作量。 Agent操作工程师需要日志，度量衡，痕迹，和配额。 工作流程所有人需要按agent计算其预算的费用。 FinOps和财务团队需要团队或业务单位通过AWS成本探索器和AWS成本和使用报告(CUR)进行收费。 安全和治理领导需要证据，说明哪些工作量需要哪种模式和工具。
- 边界证据和寿命周期：每释放agent，每一边界都需要证明：
- 模式访问：核准的模式呼叫成功，对未经核准的模式或区域的呼叫被拒绝。
- 工具访问：一个订阅工具调用成功，对agent订阅以外的工具的调用因预期错误而被拒绝。
- 身份：来自另一工作流程账户或身份的请求被拒绝。
- 发布：可以恢复先前的agent运行时版本。
- 退休：Deardown将agent的运行时间、内存、工具网关和工具赠与按依赖顺序删除，并证实没有任何东西留下。
该蓝图通过四个连接的飞机满足这些需求：开发者经验，平台控制，工作流执行，以及保证和操作。 规模单位是工作流单元格，而不是一个手动配置的agent或一个共享工作量账户。 该蓝图详细记录了每架飞机的责任。 您将阅读主要平面：代理AI平台控制平面和可重复工作流单元格在后面的段落。
运营模式和平台组件
企业通常采用代理AI三种操作模式之一：
- 集中化：一个单一的人工智能和机器学习(AI/ML)小组建立和运行每个agent. 治理是始终如一的，但随着使用案件数量的增加，该小组很快成为瓶颈。
- 权力下放：每个业务单位建立和运营自己的agents。 团队可以迅速行动，但如果没有共同的标准，控制往往会漂移，努力会重复，成本能见度会受到影响。
- 联邦：一个中央平台小组提供共享、管理服务，而域小组保留对其agents、工具和数据的所有权。 这一模式平衡了团队自主权与连贯的护栏，是大多数企业登陆的地方。
- 关于选择的援助，见关于治理模式的AWS说明性指导页。
按照我们在客户聘用中观察到的模式，蓝图采用了联邦模式。 平台团队是枢纽，一般是平台产品经理，建筑师，平台工程师，agent操作工程师，以及安全和治理领头人。 工作流团队是演讲者，由agent开发者，一个域技术领跑者和AI/ML工程师组成。 一个执行赞助人和CISO都坐在上面。
在这个蓝图中，平台团队拥有每个组成部分的定义：模板，版本，政策和招生。 每个工作流账户都运行着自己的每组组件实例(运行时、内存、工具网关)，因此失败或回滚会留在一个团队的边界内。
解决方案概述
这个解决方案提供了一个受管，多账户的Agentic AI平台，平台团队运行，工作流程团队如内部产品和工程团队通过版本，自助界面消耗。
在企业规模中，开发者体验平面是组织批准，版本agent模板的目录。 Strands, LangGraph，和 CrewAI 的蓝图船参照模板，但是当模板保存了相同的推断网关，工具网关，身份，政策，评价和交付合同时，您可以使用您选择的框架。 应用团队拥有提示，agent逻辑，工具，和评价案例。 平台团队拥有共同的控制和发布要求。
在四架飞机中，两架飞机承载了大部分建筑：
- Agentic AI平台控制平面：平台账户发布版本模板和界面，运行AWS Agent注册治理记录和共享推论网关，接受模型和Guardrails，管弦乐团审查发布，以及聚合机队信号。 团队通过代码、描述符和管道而不是管理员会话或部署门票消耗这些能力。
- 可重复工作流细胞：每个产品或域都接收一个隔离的边界，有一个团队拥有的源寄存器，一个Workload管道，以及三个Amazon Bedrock Agent Core能力：Agent Core Runtime,Agent-scoped Agent Core Memory，以及一个使用AWS IAM授权的AgentCore Gateway，只曝光被批准的工具目标。 手机还持有本地客户管理的AWS KMS密钥，标记，提醒，预算，以及云表可观察访问管理器(OAM)源链接。 一个小组可以部署、失败、退缩或退休，而不与另一个小组的释放进行协调。
主要组成部分
以下图表说明了该溶液的操作模式和调节流。
该架构由以下账户层组成：
- 管理和治理基金会。 AWS组织，AWS IAM身份中心，预防政策，审计，保留，成本政策确定企业界限。 这些逻辑责任可以映射到现有的AWS控制塔着陆区，而不需要重复的账户结构。
- 安全、审计和可观察层。 AWS CloudTrail,AWS Config,AWS安全枢纽，Amazon GuardDuty，日志存档，以及Amazon Cloud Watch OAM Swink提供独立的控制飞机证据和机队能见度。 中央运营商可以查询共享信号，而无需获得Workstream资源的写入权限。
- Agentic AI平台的平台层。 单独的平台环境拥有金色路径，治理目录，Guardrails，共享推论网关，精确工具化名，管道，兼容性，定额，以及共同的操作界面。 平台变化在更广阔的推出之前会针对代表性细胞进行测试。
- 工作流舰队层。 每个产品、域或受管制的边界都接收一个或多个非生产和生产电池。 团队拥有运行时间，内存，工具通道，工具，数据，提示，评价案例，应用事件，以及服务级目标(SLO). 在许多单元格中可以重复同样的基线，同时保留账户级隔离。
解决方案走过
以下各节追踪关键设计决定：账户地形学，预防和侦探控制，AgentCore执行路径，以及交付管道。
账户地形和组织单位
蓝图定义了将企业治理、共享平台服务和团队自主执行分开的逻辑账户作用：
这种地形学融合到现有的着陆区，一种预先配置，安全，可伸缩的多账户AWS环境，其中管理，平台，和工作流标签描述的是责任而不是固定的三账户产业。 一个组织可以运行多个经验证的平台环境和许多工作流账户对联。 从一个代表性的细胞开始，在重复基准之前证明登机，生产推广，回滚，集中观察，零剩余退休。
服务控制政策
服务控制政策限制了平台和工作流账户的最大权限。 它们补充而不是取代IAM、网关授权、护栏、资源政策、网络控制和管道证据。 蓝图规定并审查关于准确帐户和区域的有效政策，而不只是依赖源代码的意图。
- 模式和区域接纳：组织政策和网关执行作用仅限于对核定模式和支持的区域的推断。 增加一个模型或区域需要具备服务、居住、IAM、质量、成本、回滚、可观察性和拒绝验证。
- Guardrail和推论执行：Agents不直接呼叫模型提供者。 推论横跨受管网关，在此应用舞台护栏和模型允许列表。
- 仅管式工作流变异：工作流团队打开牵引请求，使用工作负荷管道。 直接开发商部署到工作流账户不在支持的操作模式之外，它使经过审查的发布和证据路径无法通过。
- 莱吉斯
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
Building an Agentic AI Platform on Amazon Bedrock AgentCore
If you’ve tried to get an agent into production, the model and tool use are not the blocker. The main bottleneck is everything around them: how many teams can build within a secure environment, which team owns each model and tool, how AgentOps and error handling stay inside a pre-defined boundary, and how platform, Workstream, and finance teams see cost and health across accounts. For a Platform team that wants to support many agentic use cases, that’s a platform product to design and operate. In this post, we refer to the team that manages the platform as the Platform team, and to the teams that build on it as Workstream teams. Workstream teams are the domain or product teams that build and own agents on the platform.
Each Workstream team needs a paved road with approved models and tools, short-lived workload identity, isolated runtime and memory, automated evaluation, rollback, telemetry, and cost attribution. These controls need to remain consistent as Workstream teams customize prompts, tools, data access, and application behavior. When every team assembles them, controls drift, shared services become a bottleneck, and ownership is difficult to audit.
In this post, we walk through the architecture and reference implementation of an enterprise Agentic AI Platform on Amazon Bedrock and Amazon Bedrock AgentCore. We cover the multi-account operating model, the Platform control plane, a repeatable per-Workstream deployment pattern, separate inference and tool gateways, and an evaluation pipeline that gates each agent before promotion to production. By the end, you should be able to deploy a governed Workstream from the companion blueprint, validate its security and lifecycle contracts, and use it as the foundation for your own agentic AI platform in the organization.
Amazon Bedrock AgentCore provides modular services for building, deploying, and operating agents at scale, including runtime, gateway, identity, memory, policy, registry, and evaluations. The Enterprise Agentic AI Platform Blueprint, built on AgentCore, adds the surrounding enterprise contracts as deployable infrastructure as code: ownership, account boundaries, software delivery, observability, cost governance, and retirement.
Architectural principles
Before diving into the solution details, it helps to understand the organizational needs that drive the platform architecture. The common challenges we have heard from customers who establish an agent platform fall into these five categories:
- Governed model access: Every untrusted inference request must pass through an approved inference gateway. The gateway applies the organization’s guardrails (for example, Amazon Bedrock Guardrails or a third-party provider), restricts which models and inference AWS Regions each Workstream can use, and enforces per-Workstream rate limits, token quotas, and budgets so that no single team can exhaust shared capacity. It also carries workload identity and emits attribution data.
- Governed tool access: Agents must discover and invoke only approved tools through an authenticated Model Context Protocol (MCP) gateway, with exact targets, least-privilege execution roles, policy decisions, and an auditable owner.
- Delegated delivery: Workstream teams (for example, product teams) need to ship and roll back independently inside pre-approved boundaries, without waiting for the platform team to deploy each application or granting developers a direct infrastructure write path.
- Fleet operations and cost: Several personas need visibility across accounts without gaining write access to team workloads. Agent operations engineers need logs, metrics, traces, and quotas. Workstream owners need cost per agent against their budgets. FinOps and finance teams need chargeback by team or business unit through AWS Cost Explorer and the AWS Cost and Usage Report (CUR). Security and governance leads need evidence of which workload called which model and tool.
- Bounded evidence and lifecycle: Every agent release needs proof at each boundary it touches:
- Model access: An approved model call succeeds, and a call to an unapproved model or Region is denied.
- Tool access: A subscribed tool call succeeds, and a call to a tool outside the agent’s subscription is denied with the expected error.
- Identity: A request from another workstream’s account or identity is rejected.
- Release: The previous agent runtime version can be restored.
- Retirement: Teardown removes the agent’s runtime, memory, tool gateway, and tool grants in dependency order, and confirms nothing is left behind.
The blueprint addresses these needs through four connected planes: developer experience, platform control, Workstream execution, and assurance and operations. The unit of scale is the Workstream cell, not a manually configured agent or one shared workload account. The blueprint README documents the responsibilities of each plane in detail. And you will read the main planes: Agentic AI Platform control plane and Repeatable Workstream cell in the later paragraphs.
Operating models and platform components
Enterprises usually adopt one of three operating models for agentic AI:
- Centralized: A single artificial intelligence and machine learning (AI/ML) team builds and runs every agent. Governance is consistent, but that team quickly becomes a bottleneck as the number of use cases grows.
- Decentralized: Each business unit builds and operates its own agents. Teams can move quickly, but without shared standards, controls tend to drift, effort gets duplicated, and cost visibility suffers.
- Federated: A central Platform team provides shared, governed services while domain teams retain ownership of their agents, tools, and data. This model balances team autonomy with consistent guardrails and is where most enterprises land.
- For assistance choosing, see the AWS Prescriptive Guidance page on Governance Models.
Following patterns we have observed in customer engagements, the blueprint implements the federated model. The Platform team is the hub, typically a Platform product manager, architect, platform engineers, agent operations engineers, and a security and governance lead. Workstream teams are the spokes, made up of agent developers, a domain tech lead, and AI/ML engineers. An executive sponsor and the CISO sit above both.
In this blueprint, the Platform team owns the definition of each component: templates, versions, policies, and admission. Each Workstream account runs its own instance of the per-team components (Runtime, Memory, Tool Gateway), so a failure or rollback stays inside one team’s boundary.
Solution overview
This solution delivers a governed, multi-account Agentic AI Platform that platform teams operate, and workstream teams such as internal product and engineering teams consume through versioned, self-service interfaces.
At enterprise scale, the developer experience plane is a catalog of organization-approved, versioned agent templates. The blueprint ships reference templates for Strands, LangGraph, and CrewAI, but you can use your choice of framework when the template preserves the same inference gateway, tool gateway, identity, policy, evaluation, and delivery contracts. Application teams own prompts, agent logic, tools, and evaluation cases. The Platform team owns the common controls and release requirements.
Out of the four planes, two carry most of the architecture:
- Agentic AI Platform control plane: The Platform account publishes versioned templates and interfaces, operates AWS Agent Registry governance records and shared Inference Gateways, admits models and Guardrails, orchestrates reviewed releases, and aggregates fleet signals. Teams consume these capabilities through code, descriptors, and pipelines rather than administrator sessions or deployment tickets.
- Repeatable Workstream cell: Each product or domain receives an isolated boundary with a team-owned source repository, a Workload pipeline, and three Amazon Bedrock AgentCore capabilities: AgentCore Runtime, actor-scoped AgentCore Memory, and an AgentCore Gateway that uses AWS_IAM authorization and exposes only the approved tool targets. The cell also holds local customer managed AWS KMS keys, tags, alarms, budgets, and a CloudWatch Observability Access Manager (OAM) source link. One cell can deploy, fail, roll back, or retire without coordinating with another team’s release.
Key components
The following diagram illustrates the operating model and governed flow of the solution.
The architecture consists of the following account layers:
- Management and governance foundation. AWS Organizations, AWS IAM Identity Center, preventive policy, audit, retention, and cost policy establish the enterprise boundary. These are logical responsibilities that can map to an existing AWS Control Tower landing zone rather than requiring a duplicate account structure.
- Security, audit, and observability layer. AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty, log archive, and an Amazon CloudWatch OAM sink provide independent control-plane evidence and fleet visibility. Central operators can query shared signals without gaining write access to Workstream resources.
- Platform layer of Agentic AI Platform. Separate Platform environments own golden paths, the governance catalog, Guardrails, shared Inference Gateways, exact tool aliases, pipelines, compatibility, quotas, and common operational interfaces. Platform changes are tested against representative cells before wider rollout.
- Workstream fleet layer. Each product, domain, or regulated boundary receives one or more nonproduction and production cells. Teams own Runtime, Memory, Tool Gateway, tools, data, prompts, evaluation cases, application incidents, and service-level objectives (SLOs). The same baseline can be repeated across many cells while preserving account-level isolation.
Solution walkthrough
The following sections trace the key design decisions: account topology, preventive and detective controls, the AgentCore execution path, and the delivery pipeline.
Account topology and organizational units
The blueprint defines logical account roles that separate enterprise governance, shared Platform services, and team-owned execution:
This topology integrates into an existing landing zone, a pre-configured, secure, and scalable multi-account AWS environment, where the Management, Platform, and Workstream labels describe responsibilities rather than a fixed three-account estate. An organization can operate multiple validated Platform environments and many Workstream account pairs. Start with one representative cell and prove onboarding, production promotion, rollback, centralized observability, and zero-residual retirement before repeating the baseline.
Service control policies
Service control policies constrain the maximum permissions available to Platform and Workstream accounts. They complement, rather than replace, IAM, gateway authorization, Guardrails, resource policies, network controls, and pipeline evidence. The blueprint renders and reviews the effective policies for the exact account and Region instead of relying on source-code intent alone.
- Model and Region admission: Organization policy and Gateway execution roles restrict inference to approved models and the supported Region. Adding a model or Region requires service availability, residency, IAM, quality, cost, rollback, observability, and denial validation.
- Guardrail and inference enforcement: Agents do not call model providers directly. Inference crosses the governed gateway, where the stage Guardrail and model allow-list are applied.
- Pipeline-only Workstream mutation: Workstream teams open pull requests and use the Workload pipeline. Direct developer deployment into Workstream accounts is outside the supported operating model, which keeps the reviewed release and evidence path non-bypassable.
- Regis
Auto-fetched and translated by AI Atlas. All rights belong to the original author.