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 Runtim