Amazon launches federated platform for enterprise AI agents

The challenge of agent scale

Many companies struggle to move AI agents from experimental prototypes into production environments. The primary bottleneck is often the infrastructure surrounding the model, such as how to manage security boundaries, model ownership, and error handling across different departments.

When every team builds their own agents independently, controls tend to drift and shared services become a bottleneck. This creates a situation where it is difficult for platform and finance teams to audit costs or see the health of the entire fleet.

To solve this, organizations need a way to provide a consistent experience for developers while maintaining strict oversight. The goal is to create a system where teams can customize their own prompts and data access without compromising the organization's safety standards.

A federated operating model

Amazon is introducing a federated model to balance these competing needs. In this setup, a central Platform team acts as the hub, providing shared services like approved models and guardrails. Meanwhile, individual Workstream teams act as the spokes, retaining ownership of their specific agents and data.

The Platform team is responsible for the high-level architecture, including the AWS Agent Registry and the shared inference gateways. They define the templates, versions, and policies that all other teams must follow to ensure consistency across the company.

Workstream teams, such as product or engineering groups, are given the autonomy to build and run their own agents. They own the specific logic, tools, and evaluation cases for their products, but they must operate within the boundaries set by the central platform.

Isolated workstream cells

The architecture relies on a concept called the Workstream cell. Instead of sharing a single workload account, each team receives an isolated boundary that includes its own runtime, memory, and tool gateway. This ensures that a failure or a rollback in one team's agent does not affect any other team.

Each cell includes specific Amazon Bedrock AgentCore capabilities. These include actor-scoped memory, which keeps data private to the specific agent, and a gateway that uses AWS_IAM authorization to expose only approved tool targets. This prevents agents from accessing unauthorized data or external services.

By using these isolated cells, companies can repeat the same baseline across many different products. This allows for rapid scaling because the platform team does not have to manually configure every new agent or deployment request.

Governance and security gates

Security is enforced through a series of gates that agents must pass through before they can interact with the world. For example, every inference request must pass through an approved gateway that applies organization-wide guardrails and restricts which AWS Regions a team can use.

The system also manages tool access through a Model Context Protocol (MCP) gateway. This ensures that agents can only discover and invoke tools that have been authenticated and assigned a specific, least-privilege execution role. This prevents an agent from performing actions outside of its intended scope.

Furthermore, the platform enforces

Infrastructure and deployment details

The blueprint is designed to integrate seamlessly into a company's existing infrastructure. Rather than requiring a completely duplicate account structure, the logical responsibilities of the platform can map directly to an existing AWS Control Tower landing zone. This allows organizations to maintain their current setup while layering on the specific requirements for agentic AI.

Each Workstream cell is equipped with specific administrative controls to ensure complete autonomy and visibility. These include local customer-managed AWS KMS keys, tags, alarms, and budgets. Additionally, the cell includes a CloudWatch Observability Access Manager source link, which allows for consistent monitoring across the entire fleet of agents.

When a company decides to add a new model or a specific AWS Region to their platform, the process is rigorous. The system requires a comprehensive validation of service availability, residency requirements, IAM permissions, quality standards, cost implications, rollback procedures, observability, and denial validation. This ensures that no new capability is introduced without meeting the organization's safety and operational contracts.