AWS has published an open-source reference blueprint for building a governed agentic ai platform on Amazon Bedrock AgentCore. It is not a single agent, and it is not a demo of one clever workflow. It is a deployable design for the part of enterprise AI that usually breaks first: the surrounding platform that lets many teams build, run, govern and retire agents without each team reinventing the controls.
The distinction matters. A team can usually get one agent working. Getting fifty agents into production, across different business units, with clear ownership, auditable tool access and visible costs, is a different problem — and it is the problem this blueprint is built to solve.
What AWS released: a governed agentic ai platform blueprint
The Enterprise Agentic AI Platform Blueprint, built on Amazon Bedrock AgentCore, is a reference implementation for an enterprise agent platform. Amazon Bedrock AgentCore itself provides modular services for building, deploying and operating agents at scale, including runtime, gateway, identity, memory, policy, registry and evaluations. The blueprint adds the surrounding enterprise contracts as deployable infrastructure as code: ownership, account boundaries, software delivery, observability, cost governance and retirement.
In other words, AgentCore supplies the building blocks, and the blueprint shows how to assemble them into a platform an organisation can actually operate. It covers the multi-account operating model, the platform control plane, a repeatable per-team deployment pattern, separate inference and tool gateways, and an evaluation pipeline that gates each agent before promotion to production. Deployment prerequisites and the maturity of the reference implementation remain open questions.
Why getting agents into production is a platform problem
As AWS puts it, if you have tried to get an agent into production, the model and tool use are not the blocker. The 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 is a platform product to design and operate. Each team building on the platform needs a paved road: approved models and tools, isolated runtime and memory, automated evaluation, rollback, telemetry and cost attribution. Those controls need to remain consistent as teams customise prompts, tools, data access and application behaviour. When every team assembles them separately, controls drift, shared services become a bottleneck, and ownership becomes difficult to audit. The blueprint exists to stop that drift by making the paved road the default path.
The federated operating model
Enterprises usually adopt one of three operating models for agentic AI. In a centralised model, a single AI team builds and runs every agent; governance is consistent, but that team quickly becomes a bottleneck as use cases multiply. In a decentralised model, each business unit builds and operates its own agents; teams move quickly, but without shared standards, controls drift, effort is duplicated and cost visibility suffers. The blueprint implements the third option, the federated model: a central platform team provides shared, governed services while domain teams retain ownership of their agents, tools and data.
In this design, the team that manages the platform is called the Platform team, and the teams that build on it are Workstream teams — the domain or product teams that build and own agents on the platform. The Platform team owns the definition of each component — templates, versions, policies and admission — while application teams own prompts, agent logic, tools and evaluation cases. That split is the whole point: autonomy for the teams building agents, consistency for the controls around them.
Inside a Workstream cell
The unit of scale is the Workstream cell, not a manually configured agent or one shared workload account. 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 authorisation and exposes only the approved tool targets. The cell also holds local customer-managed encryption keys, tags, alarms, budgets and an observability link.
Isolation is what makes the cell repeatable. Each workstream account runs its own instance of the per-team components, so a failure or rollback stays inside one team’s boundary. One cell can deploy, fail, roll back or retire without coordinating with another team’s release. The same baseline can be repeated across many cells while preserving account-level isolation. A practical approach is to start with one representative cell and prove onboarding, production promotion, rollback, centralised observability and zero-residual retirement before repeating the baseline.
The platform control plane
Above the cells sits the 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 versioned interfaces and pipelines.
Two gateways carry most of the governance. Governed model access means every untrusted inference request passes through an approved inference gateway, which applies the organisation’s guardrails, restricts which models and regions each workstream can use, and enforces per-workstream rate limits, token quotas and budgets so no single team can exhaust shared capacity. Governed tool access means agents discover and invoke only approved tools through an authenticated Model Context Protocol gateway, with exact targets, least-privilege execution roles, policy decisions and an auditable owner. Reference templates ship for Strands, LangGraph and CrewAI, but another framework may be used if it preserves the same inference gateway, tool gateway, identity, policy, evaluation and delivery contracts.
Account topology reinforces the same separation, keeping shared platform services apart from team-owned cells.
Delivery, evaluation and lifecycle gates
Delivery runs through reviewed platform and workload pipelines, and workstream teams ship and roll back independently inside pre-approved boundaries, without waiting for the platform team to deploy each application.
Every agent release needs proof at each boundary it touches. A model-access proof shows an approved model call succeeding and a call to an unapproved model or region being denied. A tool-access proof shows an approved tool call succeeding and an unapproved tool call being denied. An identity proof shows an unauthorised request being rejected. A release proof shows the previous agent runtime version being restored. A retirement proof shows teardown removing the agent’s components and confirming nothing is left behind.
The evaluation pipeline sits in front of production promotion: each agent is gated by automated evaluation before it can be promoted. That combination — evaluated agents, approved tools, approved models, and evidence at every boundary — is what turns a collection of agents into a governed fleet.
Who should use it, and its limits
The blueprint fits organisations that already have, or clearly expect, many agent use cases across many teams — the point at which shared controls, cost attribution and fleet visibility stop being nice-to-haves. For a single agent built by a single team, the full multi-account platform is more machinery than the problem needs.
There are also questions the blueprint’s own material leaves open, and research should resolve them before adoption. The deployment prerequisites and maturity of the reference implementation, the cost of the AgentCore services at fleet scale, and which frameworks beyond the shipped templates have actually been validated against the gateway, identity, policy, evaluation and delivery contracts are all worth confirming against the blueprint itself rather than assuming. What the blueprint does establish clearly is the shape of the answer this blueprint offers for enterprise scaling: a platform, with governed cells, governed gateways and evidence at every boundary — not as a pile of one-off deployments.
