AWS Outlines AgentCore Platform Blueprint

AWS published an enterprise Agentic AI Platform blueprint on Amazon Bedrock and Amazon Bedrock AgentCore for organizations that need multiple teams to build and operate agents. The reference implementation uses a federated operating model: a central Platform team supplies shared, governed services, while Workstream teams retain ownership of their agents, tools, and data. AWS says the blueprint is intended to support self-service deployment, security controls, operations, cost governance, and retirement across multiple accounts.

The blueprint organizes the platform into developer experience, platform control, Workstream execution, and assurance and operations planes. Its scaling unit is an isolated Workstream cell, with each team receiving its own account boundary, source repository, workload pipeline, AgentCore Runtime, actor-scoped AgentCore Memory, and AgentCore Gateway. The Platform account publishes versioned templates and interfaces, governs the model and tool catalog, operates shared inference gateways, reviews releases, and aggregates operational signals. Reference templates are provided for Strands, LangGraph, and CrewAI; teams may use another framework if it preserves the same gateway, identity, policy, evaluation, and delivery contracts.

For model access, every untrusted inference request must pass through an approved gateway, which applies guardrails, restricts models and AWS Regions, enforces per-team rate limits, token quotas and budgets, and records attribution. Agents discover and invoke approved tools through an authenticated Model Context Protocol (MCP) gateway with least-privilege roles and auditable ownership. Teams deploy and roll back through reviewed pipelines rather than direct infrastructure access. Operations staff can inspect logs, metrics, traces, and quotas across accounts without write access; owners can track agent costs, while finance teams can assign charges by team or business unit using AWS Cost Explorer and the Cost and Usage Report.

The blueprint pairs allowed actions with denial checks: approved model and tool calls must succeed, while unapproved models, Regions, tools, and identities must be rejected. Release evidence must show that a previous runtime version can be restored. Retirement must remove runtime, memory, tool gateways, and tool grants in dependency order and confirm that nothing remains. AWS recommends proving onboarding, production promotion, rollback, centralized observability, and retirement with one representative cell before repeating the setup across more teams.

The design also places the platform within an organization’s existing AWS landing zone, using management, security and log archive, observability, platform, and Workstream account roles. Service control policies set maximum account permissions alongside IAM, gateway authorization, guardrails, resource policies, network controls, and pipeline evidence. Model or Region additions require checks for service availability, residency, IAM, quality, cost, rollback, observability, and denial behavior. Platform and Workload pipelines pin reviewed source revisions, build and scan agents, validate policies and deployment templates, grant exact tool aliases to specific gateway roles, and deploy to nonproduction before evaluating an agent. The article’s supplied text ends during the description of that evaluation gate.

AWS published an enterprise Agentic AI Platform blueprint on Amazon Bedrock and Amazon Bedrock AgentCore for organizations that need multiple teams to build and operate agents. The reference implementation uses a federated operating model: a central Platform team supplies shared, governed services, while Workstream teams retain ownership of their agents, tools, and data. AWS says the blueprint is intended to support self-service deployment, security controls, operations, cost governance, and retirement across multiple accounts.

The blueprint organizes the platform into developer experience, platform control, Workstream execution, and assurance and operations planes. Its scaling unit is an isolated Workstream cell, with each team receiving its own account boundary, source repository, workload pipeline, AgentCore Runtime, actor-scoped AgentCore Memory, and AgentCore Gateway. The Platform account publishes versioned templates and interfaces, governs the model and tool catalog, operates shared inference gateways, reviews releases, and aggregates operational signals. Reference templates are provided for Strands, LangGraph, and CrewAI; teams may use another framework if it preserves the same gateway, identity, policy, evaluation, and delivery contracts.

For model access, every untrusted inference request must pass through an approved gateway, which applies guardrails, restricts models and AWS Regions, enforces per-team rate limits, token quotas and budgets, and records attribution. Agents discover and invoke approved tools through an authenticated Model Context Protocol (MCP) gateway with least-privilege roles and auditable ownership. Teams deploy and roll back through reviewed pipelines rather than direct infrastructure access. Operations staff can inspect logs, metrics, traces, and quotas across accounts without write access; owners can track agent costs, while finance teams can assign charges by team or business unit using AWS Cost Explorer and the Cost and Usage Report.

The blueprint pairs allowed actions with denial checks: approved model and tool calls must succeed, while unapproved models, Regions, tools, and identities must be rejected. Release evidence must show that a previous runtime version can be restored. Retirement must remove runtime, memory, tool gateways, and tool grants in dependency order and confirm that nothing remains. AWS recommends proving onboarding, production promotion, rollback, centralized observability, and retirement with one representative cell before repeating the setup across more teams.

The design also places the platform within an organization’s existing AWS landing zone, using management, security and log archive, observability, platform, and Workstream account roles. Service control policies set maximum account permissions alongside IAM, gateway authorization, guardrails, resource policies, network controls, and pipeline evidence. Model or Region additions require checks for service availability, residency, IAM, quality, cost, rollback, observability, and denial behavior. Platform and Workload pipelines pin reviewed source revisions, build and scan agents, validate policies and deployment templates, grant exact tool aliases to specific gateway roles, and deploy to nonproduction before evaluating an agent. The article’s supplied text ends during the description of that evaluation gate.