If you’ve tried to get an agent into production, the model and tool use are not the blocker. The main 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’s a platform product to design and operate. In this post, we refer to the team that manages the platform as the Platform team, and to the teams that build on it as Workstream teams. Workstream teams are the domain or product teams that build and own agents on the platform.
Each Workstream team needs a paved road with approved models and tools, short-lived workload identity, isolated runtime and memory, automated evaluation, rollback, telemetry, and cost attribution. These controls need to remain consistent as Workstream teams customize prompts, tools, data access, and application behavior. When every team assembles them, controls drift, shared services become a bottleneck, and ownership is difficult to audit.
In this post, we walk through the architecture and reference implementation of an enterprise Agentic AI Platform on Amazon Bedrock and Amazon Bedrock AgentCore. We cover the multi-account operating model, the Platform control plane, a repeatable per-Workstream deployment pattern, separate inference and tool gateways, and an evaluation pipeline that gates each agent before promotion to production. By the end, you should be able to deploy a governed Workstream from the companion blueprint, validate its security and lifecycle contracts, and use it as the foundation for your own agentic AI platform in the organization.
Amazon Bedrock AgentCore provides modular services for building, deploying, and operating agents at scale, including runtime, gateway, identity, memory, policy, registry, and evaluations. The Enterprise Agentic AI Platform Blueprint, built on AgentCore, adds the surrounding enterprise contracts as deployable infrastructure as code: ownership, account boundaries, software delivery, observability, cost governance, and retirement.
Architectural principles
Before diving into the solution details, it helps to understand the organizational needs that drive the platform architecture. The common challenges we have heard from customers who establish an agent platform fall into these five categories:
Governed model access: Every untrusted inference request must pass through an approved inference gateway. The gateway applies the organization’s guardrails (for example, Amazon Bedrock Guardrails or a third-party provider), restricts which models and inference AWS Regions each Workstream can use, and enforces per-Workstream rate limits, token quotas, and budgets so that no single team can exhaust shared capacity. It also carries workload identity and emits attribution data.
Governed tool access: Agents must discover and invoke only approved tools through an authenticated Model Context Protocol (MCP) gateway, with exact targets, least-privilege execution roles, policy decisions, and an auditable owner.
Delegated delivery: Workstream teams (for example, product teams) need to ship and roll back independently inside pre-approved boundaries, without waiting for the platform team to deploy each application or granting developers a direct infrastructure write path.
Fleet operations and cost: Several personas need visibility across accounts without gaining write access to team workloads. Agent operations engineers need logs, metrics, traces, and quotas. Workstream owners need cost per agent against their budgets. FinOps and finance teams need chargeback by team or business unit through AWS Cost Explorer and the AWS Cost and Usage Report (CUR). Security and governance leads need evidence of which workload called which model and tool.
Bounded evidence and lifecycle: Every agent release needs proof at each boundary it touches:
Model access: An approved model call succeeds, and a call to an unapproved model or Region is denied.
Tool access: A subscribed tool call succeeds, and a call to a tool outside the agent’s subscription is denied with the expected error.
Identity: A request from another workstream’s account or identity is rejected.
Release: The previous agent runtime version can be restored.
Retirement: Teardown removes the agent’s runtime, memory, tool gateway, and tool grants in dependency order, and confirms nothing is left behind.
The blueprint addresses these needs through four connected planes: developer experience, platform control, Workstream execution, and assurance and operations. The unit of scale is the Workstream cell, not a manually configured agent or one shared workload account. The blueprint README documents the responsibilities of each plane in detail. And you will read the main planes: Agentic AI Platform control plane and Repeatable Workstream cell in the later paragraphs.
Operating models and platform components
Enterprises usually adopt one of three operating models for agentic AI:
Centralized: A single artificial intelligence and machine learning (AI/ML) team builds and runs every agent. Governance is consistent, but that team quickly becomes a bottleneck as the number of use cases grows.
Decentralized: Each business unit builds and operates its own agents. Teams can move quickly, but without shared standards, controls tend to drift, effort gets duplicated, and cost visibility suffers.
Federated: A central Platform team provides shared, governed services while domain teams retain ownership of their agents, tools, and data. This model balances team autonomy with consistent guardrails and is where most enterprises land.
For assistance choosing, see the AWS Prescriptive Guidance page on Governance Models.
Following patterns we have observed in customer engagements, the blueprint implements the federated model. The Platform team is the hub, typically a Platform product manager, architect, platform engineers, agent operations engineers, and a security and governance lead. Workstream teams are the spokes, made up of agent developers, a domain tech lead, and AI/ML engineers. An executive sponsor and the CISO sit above both.
In this blueprint, the Platform team owns the definition of each component: templates, versions, policies, and admission. Each Workstream account runs its own instance of the per-team components (Runtime, Memory, Tool Gateway), so a failure or rollback stays inside one team’s boundary.
Solution overview
This solution delivers a governed, multi-account Agentic AI Platform that platform teams operate, and workstream teams such as internal product and engineering teams consume through versioned, self-service interfaces.
At enterprise scale, the developer experience plane is a catalog of organization-approved, versioned agent templates. The blueprint ships reference templates for Strands, LangGraph, and CrewAI, but you can use your choice of framework when the template preserves the same inference gateway, tool gateway, identity, policy, evaluation, and delivery contracts. Application teams own prompts, agent logic, tools, and evaluation cases. The Platform team owns the common controls and release requirements.
Out of the four planes, two carry most of the architecture:
Agentic AI 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 code, descriptors, and pipelines rather than administrator sessions or deployment tickets.
Repeatable Workstream cell: 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 authorization and exposes only the approved tool targets. The cell also holds local customer managed AWS KMS keys, tags, alarms, budgets, and a CloudWatch Observability Access Manager (OAM) source link. One cell can deploy, fail, roll back, or retire without coordinating with another team’s release.
Key components
The following diagram illustrates the operating model and governed flow of the solution.
Figure 1: Enterprise Agentic AI Platform operating model, showing the governance foundation, the Platform control plane, repeatable team-owned Workstream cells, and the software delivery, inference, tool, telemetry, and ownership flows between them.
The architecture consists of the following account layers:
Management and governance foundation. AWS Organizations, AWS IAM Identity Center, preventive policy, audit, retention, and cost policy establish the enterprise boundary. These are logical responsibilities that can map to an existing AWS Control Tower landing zone rather than requiring a duplicate account structure.
Security, audit, and observability layer. AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty, log archive, and an Amazon CloudWatch OAM sink provide independent control-plane evidence and fleet visibility. Central operators can query shared signals without gaining write access to Workstream resources.
Platform layer of Agentic AI Platform. Separate Platform environments own golden paths, the governance catalog, Guardrails, shared Inference Gateways, exact tool aliases, pipelines, compatibility, quotas, and common operational interfaces. Platform changes are tested against representative cells before wider rollout.
Workstream fleet layer. Each product, domain, or regulated boundary receives one or more nonproduction and production cells. Teams own Runtime, Memory, Tool Gateway, tools, data, prompts, evaluation cases, application incidents, and service-level objectives (SLOs). The same baseline can be repeated across many cells while preserving account-level isolation.
Solution walkthrough
The following sections trace the key design decisions: account topology, preventive and detective controls, the AgentCore execution path, and the delivery pipeline.
Account topology and organizational units
The blueprint defines logical account roles that separate enterprise governance, shared Platform services, and team-owned execution:
Role Landing-zone placement Purpose
Management foundation Root / Security and Management Organizations, Identity Center, preventive policy, audit, retention, and cost policy
Security and log archive Security CloudTrail, AWS Config, Security Hub, GuardDuty, and retained audit data
Observability Security or Operations CloudWatch OAM sink and fleet logs, metrics, traces, and cost views
Agentic AI Platform Agent Platform Golden paths, AWS Agent Registry, Guardrails, Inference Gateways, pipelines, and fleet controls
Workstream cell Agent Workstreams Team-owned Runtime, Memory, Tool Gateway, tools, data, evaluation, and application SLOs
Additional Workstream cells Agent Workstreams Repeat the same baseline per product, domain, environment, or regulated boundary
This topology integrates into an existing landing zone, a pre-configured, secure, and scalable multi-account AWS environment, where the Management, Platform, and Workstream labels describe responsibilities rather than a fixed three-account estate. An organization can operate multiple validated Platform environments and many Workstream account pairs. Start with one representative cell and prove onboarding, production promotion, rollback, centralized observability, and zero-residual retirement before repeating the baseline.
Service control policies
Service control policies constrain the maximum permissions available to Platform and Workstream accounts. They complement, rather than replace, IAM, gateway authorization, Guardrails, resource policies, network controls, and pipeline evidence. The blueprint renders and reviews the effective policies for the exact account and Region instead of relying on source-code intent alone.
Model and Region admission: Organization policy and Gateway execution roles restrict inference to approved models and the supported Region. Adding a model or Region requires service availability, residency, IAM, quality, cost, rollback, observability, and denial validation.
Guardrail and inference enforcement: Agents do not call model providers directly. Inference crosses the governed gateway, where the stage Guardrail and model allow-list are applied.
Pipeline-only Workstream mutation: Workstream teams open pull requests and use the Workload pipeline. Direct developer deployment into Workstream accounts is outside the supported operating model, which keeps the reviewed release and evidence path non-bypassable.
Registry and Gateway governance: Workstream Gateway synthesis fails when a subscribed Registry record is missing, changed, or not approved.
Scoped deployment roles: Bootstrap policies are generated per account and Region, validated with AWS Identity and Access Management Access (IAM) Analyzer, and checked through effective-policy simulation. Administrator access is reserved for initial setup rather than routine pipeline execution.
Separation of duties and adversarial proof: Platform controls model, Guardrail, Registry, and shared-service admission. Workstream teams control application behavior. Every denied path is paired with an authorized positive call and a mutation that proves the intended control caused the denial.
An administrator inside a Workstream account can’t create a supported fast path around these controls. New or changed organization policies need a sandbox or representative-cell soak, exact allow and deny tests, and a rollback plan before broad attachment.
CI/CD pipeline with evaluation gates
The blueprint uses reviewed Platform and Workload pipelines to enforce the following promotion sequence:
Source and review: A pull request establishes the immutable source revision. The pipeline pins the intended branch so an unmerged change can’t silently build the repository default branch.
Build and synth: The pipeline compiles code, runs tests and linting, creates the agent manifest, scans the digest-bound image, validates policies, resolves approved Registry descriptors, and inspects synthesized AWS CloudFormation and cdk-nag output.
Stable roles and permission handoff: The Workload pipeline creates stable Workstream roles and pauses. The Platform pipeline grants exact tool aliases to the exact Gateway role, live policies are verified, and only then does the Workload pipeline continue.
Deploy to nonproduction: The pipeline deploys Runtime, Memory, Tool Gateway, observability, alarms, budgets, tags, and application resources into the cell’s nonproduction boundary.
Evaluate the deployed agent: The gate invokes the real Runtime and measures regression, quality, tool success, refusal behavior, first-token latency, and cost. Every authorized call is paired with an adversarial twin: the gate calls an approved model and confirms success, then calls an unapproved model and confirms the denial. The same pattern applies to tools, cross-account identity, and throttling. If an expected denial is missing, the gate fails the build.
Human approval: A reviewer examines the deployed evidence, known limitations, and residual risk. A generic green build is not enough when a required probe, resource, or expected denial is missing.
Promote, observe, and roll back: Production promotion uses the reviewed revision and continuity checks. Runtime sessions are sampled through update, cancellation, rollback, restore, and re-run so the pipeline proves both the forward path and recovery path.
No Workstream deployment step has a manual fast track. The Platform team owns the release contract, but Workstream teams operate their own pipeline instances and deployment cadence. Retirement follows a strict dependency order: Platform alias grants are revoked first, then Workstream Gateway and tool roles, then Runtime, Memory, and application resources. Each step is verified before proceeding, and a final inventory confirms zero residual resources remain.
Security and governance
The blueprint implements defense in depth through reinforcing identity, policy, delivery, data, and evidence controls:
Identity and trust boundaries: AgentCore Identity, a capability of Amazon Bedrock AgentCore, and Amazon Cognito provide short-lived inference credentials. AWS_IAM and SigV4 authenticate tool traffic. Exact Runtime and Gateway roles, issuer and audience checks, account and Region context, and scoped bootstrap trust limit each principal to its intended path.
Model safety and admission: Inference flows through the governed gateway described in the Solution overview, applying Guardrails and model allow-lists before every call.
Tool authorization: The Tool Gateway invokes only Registry-approved aliases, as detailed in the Solution overview. Cedar policies provide authorization, with a retained AWS Lambda wrapper for defense in depth.
Tenant data protection: Workstream accounts isolate application state. AgentCore memory uses actor-scoped namespaces and customer-managed KMS keys. Tools and application data remain team-owned, and retention, deletion, and access policies are explicit rather than inherited from a shared mutable workload account.
Software supply chain and release: Reviewed source, manifest hashing, reproducible builds, digest-bound image scanning, policy validation, cdk-nag checks, deployed-runtime evaluation, human approval, rollback, and dependency-ordered teardown form one release contract. A missing check fails closed.
Audit, observability, and cost governance: CloudTrail and retained control-plane data corroborate pipeline evidence. OAM shares logs, metrics, and traces with central operators. Standard allocation tags, budgets, quotas, and AWS Cost and Usage Report reconciliation assign ownership without giving the agent permission to rewrite its own attribution.
The repository is a reference implementation. Developers can adjust it to address their needs. The deployment and available features are based on the eu-west-1 (Ireland) Region. A substituted component, another Region, or a wider organizational rollout requires its own availability, security, load, rollback, observability, and teardown evidence.
Conclusion
In this post, we walked through an enterprise Agentic AI Platform built on Amazon Bedrock AgentCore. The architecture separates a centrally governed Platform control plane from repeatable, team-owned Workstream cells, with distinct inference and tool gateways, and production promotion gated by deployed-runtime evaluation.
The companion repository includes a blueprint that validates these controls end to end, from pipeline gates and adversarial boundary tests through zero-residual teardown. The support claim stops at that tested boundary.
To get started, deploy one representative Workstream cell from the companion repository, prove its full lifecycle, and then automate additional cells from the same versioned baseline.
Related resources:
Enterprise Agentic AI Platform Blueprint on GitHub
Enterprise multi-account architecture for running agentic AI in production on AWS (Prescriptive Guidance)
Building an Enterprise Agentic AI Platform on Amazon Bedrock AgentCore Workshop
Amazon Bedrock AgentCore documentation
About the authors