What is new

AWS has published an architecture and companion GitHub repository called the Enterprise Agentic AI Platform Blueprint, built on top of Amazon Bedrock AgentCore. AgentCore is AWS's set of managed building blocks for running AI agents at scale: a runtime to execute them, a gateway to connect them to tools, an identity service, a memory store, policy and evaluation services, and a registry of approved components. The new blueprint does not add AI capability on top of these; instead it addresses the organizational problem of letting many teams build agents on shared infrastructure without losing control of security, cost and ownership.

The post argues that once a company has an agent that can call a model and use tools, the hard part is everything around it: which team can deploy where, who owns which tool and model, how errors and costs are tracked, and how a central team keeps oversight without becoming a bottleneck. AWS frames this as a platform product problem, distinct from building a single agent.

How it works

The blueprint separates two groups of people. A central Platform team defines the shared rules: which AI models and tools are approved, how releases are reviewed, and what evidence is required before an agent reaches production. Workstream teams are the product or domain teams that actually build and run individual agents, inside the boundaries the Platform team sets. This split mirrors a pattern called the federated operating model, one of three options AWS describes: centralized (one team builds everything, consistent but slow), decentralized (every team builds its own agents, fast but inconsistent), and federated, which AWS says is where most large organizations end up.

Technically, the architecture rests on AWS's multi-account structure (AWS Organizations), where each Workstream team gets its own isolated AWS account, or "cell", containing its own copy of the AgentCore Runtime, Memory and Tool Gateway. A failure or a rollback in one team's agent stays inside that team's account and cannot affect another team's systems. All model calls from any agent must pass through a shared, centrally managed inference gateway that applies safety guardrails, restricts which models and regions can be used, and enforces rate limits and budgets per team. Tool calls go through a separate gateway, authenticated with AWS identity mechanisms, that only allows agents to invoke tools they have been explicitly approved to use; this uses the Model Context Protocol (MCP), an open standard that lets an AI agent discover and call external tools or data sources in a structured way.

Deploying or updating an agent goes through a pipeline with several mandatory gates before it can reach production:

  • A pull request fixes the exact source code version being deployed, preventing unreviewed changes from slipping in
  • The pipeline builds the code, scans the container image, and checks that only approved tools and models are referenced
  • The agent is deployed to a non-production environment and evaluated on real runs, measuring regression, answer quality, tool success rate, refusal behaviour, response latency and cost
  • Each authorized test call is paired with a deliberately unauthorized one: the pipeline checks that a call to an approved model succeeds and a call to an unapproved model or tool is denied; if an expected denial does not happen, the build fails
  • A human reviewer examines the evidence before the agent is promoted to production
  • After promotion, the pipeline tests that the agent can be rolled back to a previous version
  • When an agent is retired, the pipeline removes its runtime, memory, tool access and permissions in a fixed order and confirms nothing is left behind

Security relies on short-lived credentials issued through AgentCore Identity and Amazon Cognito rather than long-lived keys, authenticated tool calls using AWS's IAM and SigV4 signing mechanisms, and Cedar policies (a policy language for fine-grained authorization) to decide what each agent is allowed to do. Memory storage is encrypted with customer-managed keys and is scoped so that one team's data stays separate from another's. Cost and usage tracking rely on AWS Cost Explorer and the AWS Cost and Usage Report, with standard tags so finance teams can see how much each team's agents cost without needing write access to their systems.

Why it matters

For organizations trying to move agentic AI pilots into production, the bottleneck described here is a common one: once more than one team wants to build agents, consistent access control, auditability and cost attribution become harder to maintain than the agents' own logic. By publishing a reference implementation rather than just a diagram, AWS is giving platform engineering teams a tested starting point - including the governance and release pipeline code - instead of requiring every company to design these controls from scratch. The blueprint also supports multiple agent-building frameworks (Strands, LangGraph and CrewAI are named as reference templates), so teams are not locked into a single way of writing agent logic as long as they preserve the same gateway, identity and evaluation contracts.

Limits and open questions

AWS describes this explicitly as a reference implementation that organizations are expected to adapt, not a finished product with guaranteed support beyond the scenarios it tests. The deployment and features described are based on the eu-west-1 (Ireland) AWS region; using a different region, swapping a component, or rolling the architecture out more widely requires separately validating availability, security, performance, rollback and teardown behaviour. The post does not provide performance numbers, cost figures, or case studies from organizations that have deployed this blueprint in production, so readers cannot yet judge how it performs at scale or how much operational overhead it adds compared with simpler setups.

How to try it

AWS points readers to the Enterprise Agentic AI Platform Blueprint on GitHub, alongside related AWS Prescriptive Guidance on multi-account architectures for agentic AI and a workshop for building the platform on Bedrock AgentCore. The recommended first step is to deploy a single representative Workstream cell from the repository, validate its full lifecycle - onboarding, promotion to production, rollback, observability and clean teardown - and only then replicate the same baseline across additional teams.

Sources