基于 Amazon Bedrock AgentCore 构建企业级 Agentic AI 平台

如果你曾尝试将 Agent 推向生产环境，会发现模型与工具调用本身并不是真正的阻碍。核心瓶颈在于它们周围的一切机制：如何在安全环境中支持多团队协作开发、模型与工具的权属归属划分、如何将 AgentOps 与异常处理约束在预定义边界内，以及平台团队、工作流团队（Workstream teams）与财务团队如何跨账号监控成本与系统健康状况。对于希望支撑众多 Agent 业务场景的平台团队而言，这是一项需要专门设计和运营的平台产品。在本文中，我们将管理平台的团队称为“平台团队”（Platform team），将基于该平台进行构建的团队称为“工作流团队”（Workstream teams）。工作流团队是平台上构建并拥有 Agent 的领域或产品团队。

每个工作流团队都需要一条配备获批模型与工具的“标准化开发路径”（paved road），包含短生命周期工作负载身份、隔离的运行环境与记忆库（Memory）、自动化评估、回滚、遥测以及成本归因能力。即便工作流团队对 Prompt、工具、数据访问及应用行为进行定制，这些管控机制也必须保持一致。如果任由各个团队自行拼凑，就会出现控制漂移、共享服务沦为瓶颈，且责任归属难以审计的问题。

在本文中，我们将深入解析基于 Amazon Bedrock 和 Amazon Bedrock AgentCore 构建的企业级 Agentic AI 平台的架构与参考实现。我们将探讨多账号运营模型、平台控制平面、可复用的按工作流（per-Workstream）部署模式、独立的推理与工具网关，以及在 Agent 晋升至生产环境之前进行把关的评估流水线。阅读完本文后，你将能够基于配套蓝图部署一个受治理的工作流单元，验证其安全与生命周期契约，并将其用作企业内部构建自主 Agentic AI 平台的基础。

Amazon Bedrock AgentCore 提供了用于大规模构建、部署和运行 Agent 的模块化服务，涵盖运行环境（Runtime）、网关（Gateway）、身份（Identity）、记忆（Memory）、策略（Policy）、注册表（Registry）以及评估（Evaluations）。基于 AgentCore 构建的企业级 Agentic AI 平台蓝图（Enterprise Agentic AI Platform Blueprint）将周边企业级契约以可部署的基础设施即代码（IaC）形式补齐：包括权属归属、账号边界、软件交付、可观测性、成本治理以及资源退役。

架构原则

在深入探讨方案细节之前，有必要先了解推动该平台架构的企业组织需求。我们在与搭建 Agent 平台的客户沟通时，发现常见的挑战主要集中在以下五个方面：

1. 受治理的模型访问（Governed model access）： 每一个不受信任的推理请求都必须经过获批的推理网关。网关负责应用企业的防护机制（例如 Amazon Bedrock Guardrails 或第三方提供商），限制各工作流团队可使用的模型及推理 AWS 区域（Regions），并强制实施按工作流的速率限制、Token 配额和预算，防止单个团队耗尽共享容量。它还承载工作负载身份并输出归因数据。
2. 受治理的工具访问（Governed tool access）： Agent 必须通过经过身份验证的 Model Context Protocol (MCP) 网关来发现并调用经批准的工具，同时具备精确目标、最小权限执行角色、策略决策以及可审计的责任主体。
3. 授权交付（Delegated delivery）： 工作流团队（例如产品团队）需要在预先批准的边界内独立发布和回滚，无需等待平台团队逐个部署应用，也无需直接授予开发者基础设施的直接写入路径。
4. 集群运维与成本管控（Fleet operations and cost）： 多个角色需要具备跨账号的可视化能力，同时不能获得对团队工作负载的写入权限。Agent 运维工程师需要查看日志、指标、追踪和配额；工作流负责人需要对照预算查看每个 Agent 的成本；FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS Cost and Usage Report (CUR) 按团队或业务单元进行分摊计费（chargeback）；安全与治理负责人则需要获取具体工作负载调用了哪些模型与工具的审计凭据。
5. 边界化凭据与生命周期（Bounded evidence and lifecycle）： 每次 Agent 发布都需要在其触达的每个边界上提供凭据：
   1. 模型访问： 获批的模型调用成功，调用未获批的模型或区域被拒绝。
   2. 工具访问： 已订阅的工具调用成功，调用超出 Agent 订阅范围的工具会被拒绝并返回预期错误。
   3. 身份验证： 来自其他工作流账号或身份的请求会被拒绝。
   4. 版本发布： 能够恢复至先前的 Agent 运行时版本。
   5. 资源退役： 拆除操作按依赖顺序移除 Agent 的运行时、记忆库、工具网关以及工具授权，并确认无残留资源。

该蓝图通过四个互联的平面来满足这些需求：开发者体验平面、平台控制平面、工作流执行平面以及保障与运维平面。扩展单元是“工作流单元”（Workstream cell），而非手动配置的单个 Agent 或单一共享的工作负载账号。蓝图的 README 详细记录了各平面的职责。后文中你还将深入了解核心平面：Agentic AI 平台控制平面与可复用工作流单元。

运营模型与平台组件

企业在采用 Agentic AI 时通常会选择以下三种运营模型之一：

• 集中式（Centralized）： 由单一的人工智能与机器学习（AI/ML）团队构建并运行所有 Agent。治理高度一致，但随着用例数量增长，该团队会迅速成为瓶颈。
• 去中心化（Decentralized）： 各业务单元自行构建和运营其专属 Agent。各团队行动敏捷，但缺乏统一标准，容易导致控制漂移、重复劳动，且成本可见性较差。
• 联邦式（Federated）： 由中心化平台团队提供共享且受治理的服务，领域团队保留对其 Agent、工具和数据的所有权。该模型在团队自治与统一安全防线之间取得了平衡，是绝大多数企业最终采纳的模式。
• 如需辅助选型，请参考 AWS 规范指南中关于治理模型的页面（AWS Prescriptive Guidance page on Governance Models）。

结合我们在客户实践中观察到的模式，该蓝图采用了联邦式模型。平台团队作为枢纽（Hub），通常由平台产品经理、架构师、平台工程师、Agent 运维工程师以及安全与治理主管组成。工作流团队作为辐射节点（Spokes），由 Agent 开发者、领域技术主管和 AI/ML 工程师构成。执行赞助人与 CISO 统筹监督二者。

在该蓝图中，平台团队负责定义每个组件：包括模板、版本、策略与准入规范。每个工作流账号运行各自团队专属组件（Runtime、Memory、Tool Gateway）的实例，因此任何故障或回滚都能被严格限制在单个团队的边界内部。

方案概述

该方案交付了一个受治理的多账号 Agentic AI 平台，由平台团队负责运维，内部产品和工程等工作流团队则通过带版本控制的自助服务接口进行消费。

在企业级规模下，开发者体验平面是一个由组织批准且经过版本控制的 Agent 模板目录。蓝图提供了针对 Strands、LangGraph 和 CrewAI 的参考模板，只要模板遵守相同的推理网关、工具网关、身份、策略、评估和交付契约，你也可以自由选择其他框架。应用团队全权掌控 Prompt、Agent 逻辑、工具和评估用例。平台团队则统管通用控制项与发布规范要求。

在四个平面中，有两个承载了核心架构：

1. Agentic AI 平台控制平面： 平台账号发布带版本的模板与接口，运营 AWS Agent Registry 治理记录及共享推理网关，准入模型与 Guardrails，编排经过评审的发布流程，并聚合整个集群的信号。团队通过代码、描述文件（descriptors）和流水线消费这些能力，而非依赖管理员人工会话或部署工单。
2. 可复用工作流单元（Repeatable Workstream cell）： 每个产品或业务领域都会获得一个独立的边界，配备团队专属的代码仓库、工作负载流水线，以及三项 Amazon Bedrock AgentCore 核心能力：AgentCore Runtime、主体作用域（actor-scoped）的 AgentCore Memory，以及使用 AWS_IAM 授权且仅公开经批准工具目标的 AgentCore Gateway。该单元还持有本地客户托管的 AWS KMS 密钥、标签、告警、预算和 CloudWatch 可观测性访问管理器（OAM）源链接。单个单元可以在不与其他团队发布进行协调的情况下完成部署、故障处理、回滚或退役。

核心组件

下图展示了该方案的运营模型与受治理流程。

图 1：企业级 Agentic AI 平台运营模型，展示了治理基座、平台控制平面、可复用的团队所属工作流单元，以及它们之间的软件交付、推理、工具、遥测和权属流向。

该架构由以下账号层级组成：

1. 管理与治理基座（Management and governance foundation）： AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留策略和成本策略共同确立了企业边界。这些属于逻辑职责，可以直接映射到现有的 AWS Control Tower 落地分区（Landing Zone），而无需构建重复的账号结构。
2. 安全、审计与可观测性层（Security, audit, and observability layer）： AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档以及 Amazon CloudWatch OAM Sink 提供独立的控制平面凭证与集群可见性。中心运维人员能够查询共享信号，而无需获取工作流资源的写入权限。
3. Agentic AI 平台层（Platform layer of Agentic AI Platform）： 独立的平台环境负责管理标准化交付路径（Golden paths）、治理目录、Guardrails、共享推理网关、精确工具别名、流水线、兼容性、配额以及通用运维接口。在扩大推行范围之前，平台变更会先在具有代表性的单元上进行测试。
4. 工作流集群层（Workstream fleet layer）： 每个产品、领域或合规边界都会获得一个或多个非生产和生产单元。团队拥有 Runtime、Memory、Tool Gateway、工具、数据、Prompt、评估用例、应用事件以及服务等级目标（SLO）。同一套基线可以在多个单元中复用，同时保持账号级别的隔离。

方案深度解析

以下章节梳理了核心设计决策：账号拓扑结构、预防性与检测性控制、AgentCore 执行路径以及交付流水线。

账号拓扑与组织单元

蓝图定义了逻辑账号角色，将企业治理、共享平台服务和团队拥有的执行环境隔离开来：

角色	落地分区位置	用途
管理基座（Management foundation）	Root / Security and Management	Organizations、Identity Center、预防性策略、审计、保留与成本策略
安全与日志归档（Security and log archive）	Security	CloudTrail、AWS Config、Security Hub、GuardDuty 及保留的审计数据
可观测性（Observability）	Security or Operations	CloudWatch OAM Sink 与集群日志、指标、追踪及成本视图
Agentic AI 平台（Agentic AI Platform）	Agent Platform	标准化路径（Golden paths）、AWS Agent Registry、Guardrails、推理网关、流水线及集群控制
工作流单元（Workstream cell）	Agent Workstreams	团队专属的 Runtime、Memory、Tool Gateway、工具、数据、评估与应用 SLO
附加工作流单元（Additional Workstream cells）	Agent Workstreams	按产品、领域、环境或合规边界复用相同的基线

该拓扑结构能够集成到现有的落地分区（一种预配置、安全且可扩展的多账号 AWS 环境）中，其中“管理”、“平台”和“工作流”标签描述的是职责，而非固定的三个账号实体。企业可以运行多个经过验证的平台环境和多个工作流账号对。建议从一个代表性单元入手，在批量复用基线前，先行验证接入流程、生产晋升、回滚、集中可观测性以及无残留退役。

服务控制策略

服务控制策略（SCP）限制了平台和工作流账号可用的最大权限。它们与 IAM、网关鉴权、Guardrails、资源策略、网络控制和流水线凭证形成互补，而非替代关系。蓝图会渲染并审查特定账号和区域的实际有效策略，而不仅仅依赖源代码的设计意图。

1. 模型与区域准入（Model and Region admission）： 组织策略与网关执行角色将推理严格限制在获批的模型和受支持的区域内。引入新模型或区域需要验证服务可用性、数据驻留、IAM、质量、成本、回滚、可观测性以及拒绝策略验证。
2. Guardrail 与推理强制执行（Guardrail and inference enforcement）： Agent 不会直接调用模型提供商。推理请求必须经过受治理的网关，并在该层应用阶段 Guardrail 和模型白名单。
3. 仅限流水线的工作流变更（Pipeline-only Workstream mutation）： 工作流团队提交 Pull Request 并通过工作负载流水线（Workload pipeline）推进部署

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. Bounded evidence and lifecycle: Every agent release needs proof at each boundary it touches:
   1. Model access: An approved model call succeeds, and a call to an unapproved model or Region is denied.
   2. Tool access: A subscribed tool call succeeds, and a call to a tool outside the agent’s subscription is denied with the expected error.
   3. Identity: A request from another workstream’s account or identity is rejected.
   4. Release: The previous agent runtime version can be restored.
   5. 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:

1. 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.
2. 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.

Figure 1: Enterprise Agentic AI Platform operating model, showing the governance foundation, the Platform control plane, repeatable team-owned Workstream cells, and the software delivery, inference, tool, telemetry, and ownership flows between them.

The architecture consists of the following account layers:

1. 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.
2. 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.
3. 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.
4. 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:

Role	Landing-zone placement	Purpose
Management foundation	Root / Security and Management	Organizations, Identity Center, preventive policy, audit, retention, and cost policy
Security and log archive	Security	CloudTrail, AWS Config, Security Hub, GuardDuty, and retained audit data
Observability	Security or Operations	CloudWatch OAM sink and fleet logs, metrics, traces, and cost views
Agentic AI Platform	Agent Platform	Golden paths, AWS Agent Registry, Guardrails, Inference Gateways, pipelines, and fleet controls
Workstream cell	Agent Workstreams	Team-owned Runtime, Memory, Tool Gateway, tools, data, evaluation, and application SLOs
Additional Workstream cells	Agent Workstreams	Repeat the same baseline per product, domain, environment, or regulated boundary

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.

1. 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.
2. 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.
3. 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.
4. Registry and Gateway governance: Workstream Gateway synthesis fails when a subscribed Registry record is missing, changed, or not approved.
5. Scoped deployment roles: Bootstrap policies are generated per account and Region, validated with AWS Identity and Access Management Access (IAM) Analyzer, and checked through effective-policy simulation. Administrator access is reserved for initial setup rather than routine pipeline execution.
6. Separation of duties and adversarial proof: Platform controls model, Guardrail, Registry, and shared-service admission. Workstream teams control application behavior. Every denied path is paired with an authorized positive call and a mutation that proves the intended control caused the denial.

An administrator inside a Workstream account can’t create a supported fast path around these controls. New or changed organization policies need a sandbox or representative-cell soak, exact allow and deny tests, and a rollback plan before broad attachment.

CI/CD pipeline with evaluation gates

The blueprint uses reviewed Platform and Workload pipelines to enforce the following promotion sequence:

1. Source and review: A pull request establishes the immutable source revision. The pipeline pins the intended branch so an unmerged change can’t silently build the repository default branch.
2. Build and synth: The pipeline compiles code, runs tests and linting, creates the agent manifest, scans the digest-bound image, validates policies, resolves approved Registry descriptors, and inspects synthesized AWS CloudFormation and cdk-nag output.
3. Stable roles and permission handoff: The Workload pipeline creates stable Workstream roles and pauses. The Platform pipeline grants exact tool aliases to the exact Gateway role, live policies are verified, and only then does the Workload pipeline continue.
4. Deploy to nonproduction: The pipeline deploys Runtime, Memory, Tool Gateway, observability, alarms, budgets, tags, and application resources into the cell’s nonproduction boundary.
5. Evaluate the deployed agent: The gate invokes the real Runtime and measures regression, quality, tool success, refusal behavior, first-token latency, and cost. Every authorized call is paired with an adversarial twin: the gate calls an approved model and confirms success, then calls an unapproved model and confirms the denial. The same pattern applies to tools, cross-account identity, and throttling. If an expected denial is missing, the gate fails the build.
6. Human approval: A reviewer examines the deployed evidence, known limitations, and residual risk. A generic green build is not enough when a required probe, resource, or expected denial is missing.
7. Promote, observe, and roll back: Production promotion uses the reviewed revision and continuity checks. Runtime sessions are sampled through update, cancellation, rollback, restore, and re-run so the pipeline proves both the forward path and recovery path.

No Workstream deployment step has a manual fast track. The Platform team owns the release contract, but Workstream teams operate their own pipeline instances and deployment cadence. Retirement follows a strict dependency order: Platform alias grants are revoked first, then Workstream Gateway and tool roles, then Runtime, Memory, and application resources. Each step is verified before proceeding, and a final inventory confirms zero residual resources remain.

Security and governance

The blueprint implements defense in depth through reinforcing identity, policy, delivery, data, and evidence controls:

1. Identity and trust boundaries: AgentCore Identity, a capability of Amazon Bedrock AgentCore, and Amazon Cognito provide short-lived inference credentials. AWS_IAM and SigV4 authenticate tool traffic. Exact Runtime and Gateway roles, issuer and audience checks, account and Region context, and scoped bootstrap trust limit each principal to its intended path.
2. Model safety and admission: Inference flows through the governed gateway described in the Solution overview, applying Guardrails and model allow-lists before every call.
3. Tool authorization: The Tool Gateway invokes only Registry-approved aliases, as detailed in the Solution overview. Cedar policies provide authorization, with a retained AWS Lambda wrapper for defense in depth.
4. Tenant data protection: Workstream accounts isolate application state. AgentCore memory uses actor-scoped namespaces and customer-managed KMS keys. Tools and application data remain team-owned, and retention, deletion, and access policies are explicit rather than inherited from a shared mutable workload account.
5. Software supply chain and release: Reviewed source, manifest hashing, reproducible builds, digest-bound image scanning, policy validation, cdk-nag checks, deployed-runtime evaluation, human approval, rollback, and dependency-ordered teardown form one release contract. A missing check fails closed.
6. Audit, observability, and cost governance: CloudTrail and retained control-plane data corroborate pipeline evidence. OAM shares logs, metrics, and traces with central operators. Standard allocation tags, budgets, quotas, and AWS Cost and Usage Report reconciliation assign ownership without giving the agent permission to rewrite its own attribution.

The repository is a reference implementation. Developers can adjust it to address their needs. The deployment and available features are based on the eu-west-1 (Ireland) Region. A substituted component, another Region, or a wider organizational rollout requires its own availability, security, load, rollback, observability, and teardown evidence.

Conclusion

In this post, we walked through an enterprise Agentic AI Platform built on Amazon Bedrock AgentCore. The architecture separates a centrally governed Platform control plane from repeatable, team-owned Workstream cells, with distinct inference and tool gateways, and production promotion gated by deployed-runtime evaluation.

The companion repository includes a blueprint that validates these controls end to end, from pipeline gates and adversarial boundary tests through zero-residual teardown. The support claim stops at that tested boundary.

To get started, deploy one representative Workstream cell from the companion repository, prove its full lifecycle, and then automate additional cells from the same versioned baseline.

Related resources:

1. Enterprise Agentic AI Platform Blueprint on GitHub
2. Enterprise multi-account architecture for running agentic AI in production on AWS (Prescriptive Guidance)
3. Building an Enterprise Agentic AI Platform on Amazon Bedrock AgentCore Workshop
4. Amazon Bedrock AgentCore documentation

---

About the authors

Omar Elkharbotly

Omar is a Senior GenAI/ML Specialist Solutions Architect at AWS. He works with enterprise customers across the UK and Ireland to design and deploy generative AI and machine learning solutions using Amazon Bedrock and Amazon Bedrock AgentCore to build scalable, production-ready applications.

Mia Chang

Mia is a Specialist Solutions Architect for Agentic AI, based in Berlin, Germany. She helps enterprise customers across EMEA design, operationalize, and scale agentic AI workloads, from first agents to production on managed platforms; and hybrid architectures with self-managed infrastructure. Her expertise spans agentic application architecture, agent security and governance, Responsible AI, and platform engineering.

Siva Shanmugam

Siva is a Senior Solutions Architect at Amazon Web Services, specializing in AI/ML, Data, and cloud-native architecture. His expertise spans Generative and Agentic AI applications, Developer Experience Transformation — including Agentic Coding and AI-powered engineering practices — and end-to-end enterprise cloud solutions.