Amazon Bedrock AgentCore 기반 에이전트형 AI 플랫폼 구축

Building an Agentic AI Platform on Amazon Bedrock AgentCore

by Omar Elkharbotly , Mia Chang , and Siva Shanmugam on 28 OCT 2026 in Amazon Bedrock AgentCore , Intermediate (200) , Technical How-to Permalink Share

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.

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:

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:

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, producti

[스타트업스쿨 페이지 요약]

/ Amazon Bedrock AgentCore 기반 에이전트형 AI 플랫폼 구축 Amazon Bedrock AgentCore 기반 에이전트형 AI 플랫폼 구축 ( aws.amazon.com ) AWS Machine Learning Blog · 9시간 전 · AI 모델 Amazon Bedrock AgentCore를 활용해 보안, 거버넌스, 비용 관리가 통합된 엔터프라이즈급 AI 에이전트 플랫폼을 구축하는 아키텍처를 소개하며, 에이전트의 프로덕션 배포를 위한 운영적 병목 해결 방안을 제시합니다. 이 글의 핵심 포인트 1 AI 에이전트 프로덕션 배포의 핵심 병목은 모델 성능이 아닌 보안, 거버넌스, 비용 관리 등 운영 환경의 복잡성임 2 Amazon Bedrock AgentC