AgentCore on AWS: The Enterprise Agentic AI Platform Explained

AWS Guidance for Enterprise Agentic AI Platform on AWS is an opinionated, deploy-ready reference platform published in the official aws-solutions-library-samples org for running production AI agents on Amazon Bedrock AgentCore. The repo, authored by Mehdi Nemlaghi and Cristian Balint and released under the permissive MIT-0 license in June 2026, takes a problem that every enterprise hits the moment it tries to move an agent past a demo and solves it with infrastructure: how you isolate workloads across accounts, how you promote an agent from dev to staging to prod with evaluation gates in between, how you centralize observability, and how you keep secrets out of agent code. It does this by standing up the full AgentCore component stack, Runtime, Identity, Gateway, Memory, and Code Interpreter, behind a single deploy script that can run in either a one-account tier for prototyping or a seven-account tier for production. This deep dive walks through what the repo actually ships, why the multi-account design matters, and how AgentCore’s native pieces fit together.

The starting problem is well documented in the repo’s overview. Organizations building production AI agents face four recurring challenges: secure multi-account isolation, repeatable deployments, evaluation gates, and centralized observability. Most teams solve the first one badly, by running everything in one account, and skip the other three entirely. This Guidance is AWS’s answer to all four at once. It ships a reference Strands agent, Gateway tool integration, conversation memory, a Code Interpreter for sandboxed Python, and an end-to-end CI/CD promotion pipeline that moves an agent across dev, staging, and prod accounts with automated evaluation gates on every deploy. The bet the repo makes is that these concerns are not features you bolt on later, they are the platform, and AgentCore is the substrate they are built on.

Amazon Bedrock AgentCore itself is young. It reached general availability on October 13, 2025, and has since expanded from the nine regions it launched in to twenty AWS regions. It is consumption-based and serverless: the Runtime scales to zero, the Gateway tools are Lambda functions, and memory sits on DynamoDB on-demand. The pricing message AWS puts behind it is blunt, I/O wait and idle time is free, which is the property that makes a seven-account enterprise layout affordable at low traffic. AgentCore is not a single product but a family of services, and the Guidance repo is built specifically against the five that an agent platform depends on.

The Five AgentCore Components The Repo Stands Up

The platform deploys all five core AgentCore components, and understanding what each one does is the fastest way to understand why the repo is shaped the way it is. AgentCore Runtime is the execution surface: a containerized Strands agent that handles multi-turn conversations and tool orchestration, the thing that actually runs your agent code. AgentCore Identity handles authentication, and its credential provider feature is what lets the Runtime talk to the Gateway securely using OAuth2 machine-to-machine credentials. The repo README refers to this as the Token Vault and OAuth2 Credential Provider, but it is worth being precise: Token Vault is the repo’s term for what AgentCore Identity’s credential provider feature does, not a separate official AWS product name. The official AWS documentation frames the capability as credential providers, and that is the more durable way to think about it.

The remaining three components complete the agent loop. AgentCore Gateway is an MCP-protocol gateway that exposes Lambda-based tools with JWT authorization, which is how the agent calls out to anything beyond the model. AgentCore Memory stores conversation history with session summarization, so an agent can remember what was said across turns without the context window growing unbounded. AgentCore Code Interpreter runs Python in an isolated sandbox for the cases where the model needs to compute something a tool cannot express, with the documented limitation that executions are stateless and each invocation starts fresh. Since GA, the broader AgentCore platform has grown beyond these five core services to include Harness, Browser, Observability, Payments, Evaluations, Optimization, Policy, and Registry, but this repo only consumes the original five because they are the ones an enterprise deployment platform needs.

Single-Account Versus Seven-Account: Two Tiers, One Script

The most opinionated decision in the repo is that it ships two deployment tiers from a single script. Running ./scripts/deploy.sh single collapses every component into one account for rapid prototyping, demos, and proofs of concept. Running ./scripts/deploy.sh enterprise from a management account stands up a seven-account layout designed for production. The single-account tier is what you use to learn the platform, validate an agent pattern, and confirm the cost profile. The enterprise tier is what you use when isolation, audit, and promotion discipline actually matter. The tradeoff is not subtle: the single tier is cheap and fast, the enterprise tier is correct and slow, and the repo refuses to pretend you can have both from one configuration.

Inside The Seven-Account Enterprise Design

The enterprise layout distributes responsibility across seven accounts, and the README documents each one’s role explicitly. A management account orchestrates provisioning via CloudFormation StackSets, which is the only account that needs organizations-level permissions and the ability to assume roles in member accounts. A shared-tooling account hosts the CI/CD pipelines, Amazon Cognito, and the CodeCommit agent repository, keeping the build and identity surfaces out of the workload path. Three workload accounts, dev, staging, and prod, each run isolated AgentCore stacks covering Runtime, Gateway, Memory, and Code Interpreter, so a bad deploy in dev can never reach prod by accident.

The remaining two accounts exist for cross-cutting concerns that benefit from isolation. A dedicated observability account aggregates CloudWatch logs, metrics, and AWS X-Ray traces from every other account via CloudWatch Observability Access Manager, OAM, so the team watching production is not the team that can mutate it. A security account centralizes CloudTrail, service control policies, and KMS key administration, which is where the secure-by-default posture actually lives. The result is a layout where blast radius is bounded by account boundaries, every workload tier is independently deployable, and the audit and observability planes are structurally separate from the planes they observe. For a cloud architect or DevOps engineer responsible for an agent rollout, this is the part of the repo worth studying most closely, because the account topology is the part that is hardest to retrofit later.

The CI/CD Promotion Chain: CodeCommit To CodePipeline To CodeBuild

The second pillar of the enterprise tier is the promotion pipeline, scaffolded out of the box as a CodeCommit to CodePipeline to CodeBuild chain. The shared-tooling account holds the CodeCommit repository that stores the agent code. CodePipeline watches that repository and orchestrates the promotion across the workload accounts, moving an agent from dev to staging to prod in a controlled sequence rather than a manual deploy. CodeBuild does the heavy lifting of building the Docker image, running the evaluation cases, and producing the artifact that gets promoted.

The reason this chain exists, and the reason it is worth the added complexity, is the evaluation gate. The repo wires AgentCore’s native evaluators, named Helpfulness and GoalSuccessRate, to run against every agent on every deploy, with configurable per-agent evaluation cases that live alongside the agent code. A deploy is not considered promoted until the evaluation gates pass, which converts agent quality from a subjective review into a pipeline checkpoint. This is the part most teams leave until after their first production incident. The Guidance ships it on day one, and it is the single feature that most distinguishes a deploy-ready platform from a starter template. Without an evaluation gate wired into promotion, a CI/CD pipeline for agents is just a faster way to ship a regression.

Secure By Default: Auth, Secrets, And The Credential Provider

The secure-by-default posture is built from concrete primitives rather than aspirational language. End users authenticate through Amazon Cognito with JWT tokens, and machine-to-machine traffic between the Runtime and the Gateway uses OAuth2 Client Credentials mediated by AgentCore Identity’s credential provider. The enterprise tier layers on service control policies, KMS encryption, and org-wide CloudTrail in the security account. The README lists these as distinct capabilities, JWT auth for end users, OAuth2 M2M between Runtime and Gateway via AgentCore Identity Token Vault, SCPs, KMS, and org-wide CloudTrail, and the framing matters because it locates each control at the right boundary. User auth is a Cognito concern, service-to-service auth is an AgentCore Identity concern, and organizational controls are an account-topology concern. Conflating them is how teams end up with a Gateway that trusts any caller or a Runtime that holds long-lived secrets it should not have.

The credential provider framing deserves a second mention because it is easy to misread. When the README says AgentCore Identity Token Vault, it is describing the same capability that official AWS documentation calls credential providers, the mechanism that issues and rotates the OAuth2 credentials the Runtime uses to call the Gateway. Treating Token Vault as a standalone AWS product name will lead you to search for a service that does not exist under that label. Treating it as the repo’s name for what AgentCore Identity already does will lead you to the right documentation.

Centralized Observability Across Accounts

Observability in a multi-account agent platform is a harder problem than in a monolithic service, because the traces, metrics, and logs you need are spread across accounts that cannot all see each other. The Guidance solves this with CloudWatch Observability Access Manager, which aggregates CloudWatch Logs, Metrics, and X-Ray traces from the workload and shared-tooling accounts into the dedicated observability account. This is an enterprise-tier feature, the single-account tier does not need cross-account aggregation because there is only one account, and it is what makes the platform operable rather than merely deployable. An agent that fails in the prod workload account leaves its traces in the observability account, not stranded behind an account boundary the on-call engineer cannot cross. For a DevOps engineer, the value is concrete: a single pane for X-Ray traces across dev, staging, and prod, without the IAM gymnastics that cross-account CloudWatch normally demands.

The Reference Agent, The Default Model, And Pluggable Patterns

Out of the box the repo ships a single reference agent pattern called strands-single-agent, which runs on the default model anthropic.claude-haiku-4-5. The Strands agent handles multi-turn conversations and tool orchestration, and the Gateway exposes Lambda-based tools that the agent can call through the MCP protocol. The default deployment type is zip with a public network mode, though a VPC mode is available for private network deployments by setting network_mode: VPC in the CDK configuration.

The repo is designed to be extended rather than forked. A pluggable agent system means you can drop a new pattern into the agentcore/patterns/ directory and the deploy script scaffolds the repository structure, the Docker image, the Gateway tools, and the evaluation cases for it. The documented limitation is that the current release ships only the one pattern, so teams wanting a multi-agent or routing topology have to follow the existing structure and build it themselves. Changing the model is a configuration edit, updating model_id in the agent code or passing modelId in the request payload, provided the target account has Bedrock model access enabled for that model in the region where it deploys.

Cost: Honest Numbers For A Light Workload

The README includes a sample cost table for the single-account tier with light usage, roughly one thousand agent invocations per month in the EU Ireland region, and the total lands at about $5.06 per month as of June 2026. The breakdown is useful because it shows where the money actually goes. Amazon Bedrock inference on Claude Haiku dominates at around $1.25, the AgentCore Runtime costs about $0.50 for a thousand pay-per-request invocations, the Gateway adds about $0.20 for two thousand tool calls, and Memory is roughly $0.10 for a thousand stored sessions. Cognito sits in its free tier, the Lambda tools run effectively free at low volume, the DynamoDB on-demand cost is negligible, and CloudWatch logs, metrics, and traces add about $3.00, which is the largest single line after inference.

Two caveats belong with those numbers. First, the figure is dated, the README frames it as of June 2026, and AWS pricing shifts, so treat it as an order-of-magnitude anchor rather than a quote. Second, the enterprise tier adds cross-account CloudWatch OAM, CodePipeline, CodeBuild, and CodeCommit costs on top, and the README notes that costs scale linearly with agent invocations and model token usage. The structural point is that there is no always-on compute to pay for: the Runtime scales to zero, the tools are Lambda, and memory is DynamoDB on-demand. The platform is cheap when idle and predictable when loaded, which is the property that makes a seven-account enterprise layout economically viable for a team that is not yet at scale.

Prerequisites And What It Takes To Run It

The deployment is optimized for macOS or Amazon Linux 2023, with Windows requiring additional steps such as WSL2. The toolchain is specific: AWS CLI v2, Node.js 18 or higher, Python 3.12 or higher, Docker running locally for building the agent container image, and AWS CDK v2 for the infrastructure. The AWS account side requires Bedrock model access enabled for anthropic.claude-haiku-4-5, or whichever model the chosen pattern uses, in every region where you deploy. For the enterprise tier, six target accounts must be pre-provisioned under an AWS Organization from the management account, each with an assumable OrganizationAccountAccessRole, and the CDK must be bootstrapped in each workload account and the shared-tooling account. The region constraint is straightforward: any region where AgentCore is available, defaulting to eu-west-1 and configurable through infra/config.yaml. These prerequisites are not ornamental. Docker must be running before deployment because the agent container image is built locally and pushed to ECR, and CDK bootstrap must be complete or the deploy script will error out.

Who This Repo Is For, And Who It Is Not

The intended audience is explicit in the design choices. Cloud architects who need a defensible multi-account topology for an agent rollout will find the seven-account layout immediately useful as a reference, even if they never deploy it verbatim. DevOps engineers responsible for agent promotion and observability will find the CodeCommit to CodePipeline to CodeBuild chain with evaluation gates a working template rather than a diagram. Teams already committed to AgentCore as their agent substrate get a deploy-ready path that removes the first three months of platform engineering. The repo is not for a team that wants a no-code agent builder, nor for one that needs a multi-agent orchestration framework out of the box, since the only shipped pattern is a single Strands agent. And it is not a community standard with a long track record. It is a new, AWS-published official Solutions Library sample, released in June 2026, and it should be evaluated as an opinionated starting point from AWS rather than as a battle-tested platform with years of production hardening. Read it for the architecture, borrow the parts that fit, and treat the Strands single-agent pattern as a reference implementation rather than a finished product.

The AWS Guidance for Enterprise Agentic AI Platform on AWS is worth reading because it converts the messy problem of running agents in production into a concrete, deploy-ready topology. The five AgentCore components, Runtime, Identity, Gateway, Memory, and Code Interpreter, are wired together behind a single script that can run as a one-account prototype or a seven-account enterprise layout with a management account, shared-tooling account, three workload accounts, an observability account, and a security account. The CI/CD promotion chain from CodeCommit through CodePipeline to CodeBuild, with AgentCore’s native Helpfulness and GoalSuccessRate evaluators gating every deploy, is the feature that separates a real platform from a starter template. At roughly $5.06 per month for a light single-account workload as of June 2026, the cost profile is honest about being serverless and consumption-based, with the Runtime scaling to zero and idle time free. Authored by Mehdi Nemlaghi and Cristian Balint under MIT-0, it is a new official Solutions Library sample, not a mature standard, and the right way to use it is as a reference architecture for any team standardizing on AgentCore. Open the AWS Guidance for Enterprise Agentic AI Platform repo on GitHub, or browse it alongside the other entries in our AI agents repos and resources roundup.