AWS blueprint: one agent platform, team cells, denial-tested releases

On 28 October 2026 AWS published a reference architecture for running many AI agents inside one company, written by Omar Elkharbotly, Mia Chang and Siva Shanmugam, all AWS solutions architects. It describes an Enterprise Agentic AI Platform Blueprint, built on Amazon Bedrock AgentCore and released as deployable infrastructure as code in a companion GitHub repository. The post is vendor-published and describes a design, not a customer's results.

The problem it targets

The authors argue that the model and tool use are not what blocks agents in production. They say the bottleneck is the surrounding work: which team owns each model and tool, how error handling stays inside a boundary, and how platform and finance teams see cost and health across accounts. When every team assembles those controls itself, the post says, controls drift and ownership becomes hard to audit.

It names three operating models: centralised (one AI team builds every agent), decentralised (each business unit builds its own) and federated. It says the blueprint implements the federated one, which it describes as where most enterprises land: a central Platform team provides governed services and domain teams keep ownership of their agents, tools and data.

How the design is split

The Platform team owns templates, versions, policies and admission of models and guardrails. Each product or domain gets a Workstream cell: an isolated boundary with its own source repository, deployment pipeline, AgentCore Runtime, actor-scoped Memory and a Gateway that exposes only approved tools. The post says one cell can deploy, fail, roll back or retire without coordinating with another team's release. It advises starting with one representative cell and proving onboarding, promotion, rollback, central observability and retirement before repeating the baseline.

Inference and tools go through separate gateways. Every model request passes an inference gateway that applies guardrails, restricts which models and Regions a team may use, and enforces per-team rate limits, token quotas and budgets. Tool calls go through an MCP gateway using AWS IAM authorisation, least-privilege roles and Cedar policies. Pipeline-only deployment means developers do not get a direct write path into team accounts.

The release gate

The pipeline runs from pull request through build, policy checks, deployment to a nonproduction cell, and an evaluation of the deployed agent. That evaluation measures regression, quality, tool success, refusal behaviour, first-token latency and cost. The distinctive rule is that each authorised call is paired with an adversarial twin: the gate calls an approved model and expects success, then calls an unapproved one and expects a denial. The same pattern covers tools, cross-account identity and throttling. If an expected denial is missing, the build fails.

A human reviewer then examines the evidence and residual risk. Production promotion samples runtime sessions through update, cancellation, rollback and restore. Retirement runs in dependency order, revoking tool grants first and ending with a final inventory that must show nothing left behind.

Cost and ownership

For cost, the post says standard allocation tags, budgets, quotas and reconciliation against the AWS Cost and Usage Report assign ownership to teams, and that the agent is not given permission to rewrite its own attribution. It lists the personas who need different views: operations engineers need logs and traces, workstream owners need cost per agent, and finance needs chargeback by team or business unit.

What the post leaves out

It reports no dollar costs, latency overhead from the gateways, number of teams or agents, or incident data. It says the deployment and features are based on the eu-west-1 (Ireland) Region, and that another Region, a substituted component or a wider rollout needs its own availability, security, load and rollback evidence. The design is also tied to AWS services, including Organizations, CloudTrail, KMS and the AgentCore stack.

What a team can take from it

Two ideas travel beyond AWS. First, write a negative test for every control you rely on, and fail the release when the expected refusal does not happen. Second, make rollback and teardown part of the release criteria, not an afterthought. If you run agents across several teams, list who can currently change a model, a tool grant or a budget without a pipeline.