← Agent Frameworks 🕐 17 min read
Agent Frameworks

Amazon Bedrock AgentCore — Managed Agent Runtime for Enterprise Production

Brandon Sneider · May 2026

> **Source credibility: MEDIUM** — AWS awslabs engineering repos — official AWS engineering output, open-source (Apache 2.0 / MIT). Architecture claims are reproducible.

See also (wiki): wiki/enterprise-agent-runtime-infrastructure.md · wiki/agentic-ai-governance.md · wiki/hitl-deployment-pattern.md · wiki/data-readiness.md · wiki/mlops-ai-platform-engineering.md · wiki/vendor-security-questionnaires.md · wiki/ai-platform-selection.md · wiki/model-risk-management.md · wiki/semantic-observability.md

Source credibility: MEDIUM — AWS awslabs engineering repos — official AWS engineering output, open-source (Apache 2.0 / MIT). Architecture claims are reproducible. Sources: agentcore-samples, agentcore-rl-toolkit, fullstack-solution-template-for-agentcore, agents-for-amazon-bedrock-blueprints official repos plus AWS documentation as of May 2026. No independent n= survey data. These case studies are vendor-published and represent selected wins with no control group and no independent verification. Cross-reference against: METR RCT (experienced developers 19% slower), CMU study (40.7% code complexity increase), Atlan 200-deployment analysis (median +159.8% ROI requires workflow redesign first).

TIER 1

Executive Summary

Amazon Bedrock AgentCore is a managed agent execution infrastructure layer — distinct from Bedrock Agents — that lets enterprises deploy agents written in any framework (LangGraph, Strands, CrewAI, OpenAI SDK, raw boto3) to production without building session isolation, identity management, memory, observability, or policy enforcement from scratch. Its eight components — Runtime, Gateway, Identity, Memory, Tools, Observability, Evaluation, and Policy (Cedar) — address the primary engineering blockers that prevent AI agent prototypes from reaching production in regulated enterprises. Cedar policy enforcement at the Gateway boundary moves access control outside of agent code, making it resistant to prompt injection attacks. The AgentCore RL Toolkit (ART) enables RL fine-tuning on production agents using the same container, without separate RL infrastructure. Framework agnosticism is real; operational lock-in (memory, identity, Cedar policies) accumulates over time.

Key Data Points

Finding Value Source Date Tier
AgentCore Runtime extended execution limit Up to 8 hours per session AWS documentation May 2026 TIER 1
Session isolation model MicroVM per session, memory sanitized on completion AWS documentation May 2026 TIER 1
Payload size supported 100MB (text, images, audio, video) AWS documentation May 2026 TIER 1
AgentCore CLI install npm install -g @aws/agentcore AWS documentation May 2026 TIER 1
Frameworks supported out-of-box Strands, LangGraph, Google ADK, OpenAI SDK, and more AWS documentation May 2026 TIER 1
Cedar policy — automated reasoning validation Formal verification before deployment AWS documentation May 2026 TIER 1
ART decorator swap to enable RL training @app.entrypoint → @app.rollout_entrypoint agentcore-rl-toolkit README May 2026 TIER 1
Token capture mechanism (RL) rllm-model-gateway proxy; no retokenization drift agentcore-rl-toolkit README May 2026 TIER 1
FAST template deployment path cdk bootstrap → cdk deploy → python scripts/deploy-frontend.py awslabs/fullstack-solution-template-for-agentcore May 2026 TIER 1
Primary lock-in surface Memory stores, Cedar policies, Identity configuration — not model or framework layer Derived from architecture analysis May 2026 TIER 2

Positioning: The Layer Above Bedrock Agents

The existing research file aws-bedrock-enterprise-agent-blueprints-2026.md covers Bedrock Agents — AWS’s first-generation managed agent service built on action groups, knowledge bases, and guardrails configured through the console. AgentCore is a different product class entirely.

Bedrock Agents is a configured service: you define agent behavior through prompts, action groups, and knowledge bases in the AWS console or API, and Bedrock Agents orchestrates the loop. It is opinionated about how agents are structured and what LLMs they use (Bedrock models only).

AgentCore is a managed execution infrastructure: you bring your own agent code (in any framework, calling any model), and AgentCore handles the production runtime concerns — secure isolation, scaling, identity, memory, tool connectivity, observability, and policy enforcement. It does not care whether your agent was written with Strands, LangGraph, CrewAI, LlamaIndex, Google ADK, or raw boto3. The only requirement is that the agent container exposes the AgentCore HTTP service contract (/invocations, /ping).

AgentCore is what allows enterprises to promote a prototype (running locally, calling Claude or GPT-4) to production without rewriting the agent as a Bedrock Agents configuration.

1. AgentCore Components — The Eight Pillars

1.1 Runtime — Secure Serverless Execution

AgentCore Runtime is the compute foundation. Key specifications:

  • MicroVM isolation per session: each user session runs in a dedicated microVM with isolated CPU, memory, and filesystem. Different session IDs use entirely separate microVMs. After session completion, the microVM is terminated and memory is sanitized.
  • Extended execution: supports workloads up to 8 hours. This is critical for agentic workflows that involve long reasoning chains, multi-step tool use, or waiting for async processes. Standard Lambda has a 15-minute limit; this removes that ceiling.
  • Session continuity: requests with the same session ID route to the same container, enabling multi-turn conversations with persistent in-process state.
  • Auto-scaling: new runtime sessions spin up instantly on demand. The RL Toolkit README describes this property explicitly as what makes AgentCore suitable for online RL training — parallel agent rollouts at scale without infrastructure coordination.
  • Protocol support: MCP (Model Context Protocol) and A2A (Agent-to-Agent) are both supported natively. Agents can act as MCP servers or MCP clients; they can communicate with other agents via A2A.
  • Persistent filesystem: state can persist across session stop/resume cycles. Installed packages, build artifacts, and files survive without external storage.
  • Payload handling: 100MB payloads supported, covering text, images, audio, and video for multimodal agent workloads.
  • Streaming: both HTTP API calls and WebSocket connections for bidirectional streaming.
  • Consumption-based pricing: charges only for active processing time, not I/O wait. Because agents spend significant time waiting for LLM responses, this is structurally cheaper than allocation-based compute for agent workloads.

The AgentCore CLI (npm install -g @aws/agentcore) is the primary toolchain. agentcore create scaffolds projects; agentcore dev runs a local development server; agentcore deploy pushes to production. The CLI handles Dockerfile generation automatically for most standard frameworks.

1.2 Gateway — APIs and Lambda Functions Become MCP Tools

AgentCore Gateway converts existing enterprise APIs — REST endpoints, Lambda functions, existing MCP servers — into MCP-compatible tools that any AgentCore-deployed agent can discover and call. The significance: enterprises do not need to re-implement their existing service layer to give agents access to it.

Gateway sits between agents and tools. When combined with the Policy component (section 1.8), Gateway becomes the enforcement point for what agents can and cannot do. The FAST template (section 4) shows a concrete implementation: Lambda-based tools behind Gateway with Cognito authentication and Cedar policies evaluating each request before any tool call executes.

1.3 Identity — Agent Identity Across AWS and Third Parties

AgentCore Identity handles two distinct authentication flows:

Inbound auth: authenticating users into agents. Integrates with Okta, Microsoft Entra ID, Amazon Cognito, and other standard IdPs. A Fortune 500 that already runs Entra for its employees can gate AgentCore agent access with the same identity provider without building custom auth middleware.

Outbound auth: agents authenticating to downstream services. When an agent needs to call Slack, GitHub, Zoom, Salesforce, or any other service, Identity manages OAuth flows and API key injection. The agent code does not handle credentials directly — Identity injects them at runtime.

M2M (machine-to-machine) auth: for runtime-to-gateway communication (as shown in the FAST architecture), the Runtime authenticates via OAuth2 Client Credentials with user identity propagated through Cognito’s V3 Pre-Token Lambda. This means the Gateway Cedar policy can evaluate the human user’s identity claims even though the technical request is coming from the agent.

This identity propagation chain — human user → JWT → agent runtime → M2M token with user claims → Gateway Cedar evaluation — is the mechanism that makes fine-grained, user-context-aware access control possible for agents.

1.4 Memory — Managed Persistent Context

AgentCore Memory addresses the fundamental statelessness problem of LLM agents. Two memory types:

Short-term memory: turn-by-turn context within a single session. Agents can resolve references like “what about tomorrow?” to the previously mentioned topic without the client re-sending full context on every turn.

Long-term memory: automatically extracts and stores key insights across sessions — user preferences, important facts, session summaries. A customer service agent that learns a user prefers window seats can surface that preference in future interactions without the user repeating it.

The infrastructure complexity — storage backends, extraction pipelines, retrieval logic — is fully managed. Agent code calls Memory APIs; the service handles everything else. This eliminates a common prototype-to-production gap where developers build conversation history in-process and then discover it breaks under concurrent sessions or doesn’t persist across deployments.

1.5 Tools — Code Interpreter and Browser Tool

Code Interpreter: sandboxed Python execution with file operations, session-persisted state, and pre-installed common libraries. Agents can write and execute code without the enterprise managing sandbox infrastructure.

Browser Tool: secure website interaction at scale. Compatible with the Nova Act model. Enables agents to navigate web interfaces, extract information from live pages, and complete form-based workflows.

Both are built-in managed tools — no infrastructure to stand up. Combined with Gateway (which surfaces custom enterprise tools), these give agents a production-ready tool surface out of the box.

1.6 Observability — OpenTelemetry Native

AgentCore Observability provides specialized tracing for agent workloads. Unlike generic APM that captures request latency, agent observability must capture:

  • Agent reasoning steps
  • Tool invocations and their results
  • Model interactions
  • Decision pathways

All instrumented via OpenTelemetry, making traces portable to Grafana, Datadog, Dynatrace, and any OTel-compatible backend. The LLM evaluation system (covered in the companion file) can instrument any AgentCore agent with zero code modification via OTel.

The FAST template includes test scripts for observability validation (test-scripts/test-agent.py, test-scripts/test-gateway.py) and documents production monitoring patterns.

1.7 Evaluation — On-Demand and Online

AgentCore Evaluation provides two modes:

  • On-demand evaluation: run evaluators against a batch of agent traces. Used during development and before promotion gates.
  • Online evaluation: continuous evaluation of production agent behavior. The CLI command agentcore add online-eval enables this on any deployed agent.

The agentcore add evaluator command adds LLM-as-judge evaluation to any running agent, making systematic quality assessment available without building evaluation infrastructure separately. This integrates with the broader AWS LLM evaluation tooling (covered in the companion file).

1.8 Policy — Cedar Fine-Grained Access Control

Cedar is an open-source authorization policy language developed by AWS. In AgentCore, Policy intercepts all agent traffic through Gateway and evaluates every request against Cedar policies before tool access is granted.

What Cedar enables for agents:

  • Specify exactly which tools an agent can call
  • Define precise conditions under which each action is permitted (user identity, input parameters, time of day, data classification labels)
  • Enforce deterministically — outside of agent code, so a compromised or manipulated agent cannot bypass the policy layer
  • Author in natural language (the system translates to Cedar and validates automatically) or write Cedar directly

Why this matters for enterprise governance: The fundamental weakness of agent security architectures that embed guardrails in the prompt or in agent code is that the agent itself can be manipulated into ignoring them (prompt injection, jailbreaking). Cedar enforcement happens at the infrastructure boundary, not inside the agent. An agent that is successfully prompt-injected to “ignore your restrictions” cannot override a Cedar policy that prohibits calling the payment processing tool for non-finance department users.

Automated reasoning validation: before policies are deployed, AgentCore runs formal verification to check for overly permissive rules, overly restrictive rules, and conditions that can never be satisfied. This catches policy logic errors before they reach production.

The FAST implementation: the FAST template ships a working Cedar policy (gateway/policies/policy.cedar) implementing department-based access control. It also includes dedicated Lambda functions for the Cedar Policy Engine lifecycle (infra-cdk/lib/lambdas/cedar-policy/).

2. Framework Agnosticism — What It Means for Lock-In Decisions

The AgentCore README leads with this: “framework-agnostic and model-agnostic.” The AgentCore CLI scaffolds new projects with Strands Agents, LangGraph, Google ADK, OpenAI SDK, and more. Existing agent code requires only:

  1. Add the AgentCore Python SDK (bedrock_agentcore.runtime.BedrockAgentCoreApp)
  2. Decorate the entrypoint function (@app.entrypoint)
  3. Run the container

The agent’s internal logic — which model it calls, which orchestration framework it uses, how it constructs prompts — does not change.

Lock-in analysis: The runtime, identity, memory, and policy infrastructure is AWS-proprietary. An enterprise using AgentCore Memory is storing long-term agent context in an AWS-managed service — migrating that state to another platform requires building an extraction and migration path. The model and framework layers remain portable; the operational infrastructure (identity providers, memory stores, observability pipelines, Cedar policies) accumulates AWS-specific configuration over time.

The pragmatic case for accepting that lock-in: before AgentCore, enterprises building production agent infrastructure had to assemble equivalent capabilities from disparate components — a session management layer, an identity proxy, a memory database, an observability pipeline, a policy enforcement point. Each component required integration work and ongoing maintenance. AgentCore bundles all eight capabilities with a single SDK and managed service SLA. For enterprises that are already AWS-committed and where agent infrastructure complexity is the bottleneck, that tradeoff is often rational.

3. AgentCore RL Toolkit (ART) — RL Training Without Infrastructure Rewrite

The AgentCore RL Toolkit (ART) is a research-to-production bridge for reinforcement learning on production agents. The core insight: RL training on LLM agents requires running hundreds of parallel rollouts (the agent completing a task), collecting rewards, and updating model weights. Doing this at scale requires secure parallel execution — exactly what AgentCore Runtime provides.

The Decorator Swap Pattern

A production agent deployed on AgentCore:

@app.entrypoint
def invoke_agent(payload):
    response = agent(payload.get("prompt"))
    return response.message["content"][0]["text"]

The same agent adapted for RL training:

@app.rollout_entrypoint
def invoke_agent(payload: dict):
    model = OpenAIModel(client_args={"base_url": payload["_rollout"]["base_url"]}, ...)
    agent = Agent(model=model, ...)
    response = agent(payload.get("prompt"))
    rewards = reward_fn(response_text=..., ground_truth=payload.get("answer"))
    return {"rewards": rewards}

Three changes: decorator swap, model instantiation inside the function (to accept runtime training configuration), and returning rewards instead of text. Everything else — the agent’s tools, system prompt, reasoning logic — stays identical.

Async Fire-and-Forget Architecture

LLM agent rollouts can run for minutes to hours. ART manages this with an async model:

  • @rollout_entrypoint returns HTTP 200 immediately; the agent runs in the background saving results to S3
  • RolloutClient.invoke() submits requests and returns a RolloutFuture immediately
  • future.result(timeout=600) polls S3 with exponential backoff until results appear
  • Automatic session cleanup when results are fetched or timeout is reached

The run_batch() method handles batch evaluation with managed concurrency, timeouts, and polling — covering the common evaluation use case without custom orchestration code.

Token Capture Without Retokenization Drift

A non-obvious problem in RL training on agents: the training loop needs exact token IDs sampled by the model. Re-tokenizing the text output introduces drift (three sources: non-unique tokenization, tool-call serialization changes, chat template misalignment). ART solves this through rllm-model-gateway, a transparent HTTP proxy between the agent and the inference server (vLLM/SGLang) that captures token IDs directly from the server, scoped by session ID. Agents use a standard OpenAI-compatible model client and are unaware of the capture.

Why this matters for enterprise AI teams: enterprises with production agents can run RL training loops on real production workloads (not synthetic training data) without standing up separate RL infrastructure. The same agent container runs in production and in training. After training, the fine-tuned model deploys to the same AgentCore stack with minimal code changes.

Supported Training Libraries

ART integrates with rLLM (which supports veRL and Tinker backends). The math agent example demonstrates GRPO training on a Strands math agent with GSM8K rewards.

4. FAST Template — Fullstack AgentCore for “Vibe-Coding”

The Fullstack AgentCore Solution Template (FAST) is an open-source reference application (awslabs/fullstack-solution-template-for-agentcore) that provides a production-ready full-stack application combining a React frontend with an AgentCore backend. Its design philosophy: handle the infrastructure and security scaffolding so development teams can focus on agent logic.

What Ships Out of the Box

  • React frontend with TypeScript, Vite, Tailwind CSS, and shadcn components
  • Cognito User Pool authentication with OAuth2 support
  • AgentCore Runtime backend with Gateway-connected Lambda tools
  • Code Interpreter integration
  • CDK deployment stack (Terraform alternative also included)
  • Amplify Hosting for the frontend
  • Memory integration
  • Cedar policy-based access control

Deployment path: cdk bootstrap → cdk deploy → python scripts/deploy-frontend.py. Weeks of infrastructure assembly reduced to three commands.

The “Vibe-Coding” Development Model

FAST codifies security best practices and architecture patterns in documentation rather than in opinionated code constraints. The documentation in vibe-context/ (AGENTS.md, coding-conventions.md, development-best-practices.md) is designed to be loaded into an AI coding assistant’s context. The developer describes what they want to build; the coding assistant follows the FAST conventions and best practices automatically. The result is that delivery scientists and engineers who don’t have frontend or infrastructure expertise can customize the full-stack application for arbitrary use cases.

This pattern — AI-coding-assistant-aware documentation as the abstraction layer — is a structural shift in how AWS thinks about enterprise developer tools. The target user is a data scientist or ML engineer who wants to deploy an agent, not a full-stack engineer.

Authentication Flow Architecture

The FAST authentication chain shows how AgentCore components compose:

  1. User authenticates with Cognito (Authorization Code flow) → gets JWT
  2. Frontend sends JWT in Authorization header to AgentCore Runtime → Runtime validates against Cognito
  3. Runtime calls Gateway with OAuth2 Client Credentials + user identity propagated via Cognito V3 Pre-Token Lambda
  4. Gateway evaluates Cedar policies against user claims before any tool executes

This is a complete, production-auditable identity chain. Each hop is authenticated; user identity is propagated end-to-end; tool access is governed by deterministic Cedar policies rather than LLM discretion.

5. Comparison to NVIDIA AIQ — Managed vs. Self-Hosted

The nvidia-aiq-deep-research-agent-2026.md file covers NVIDIA AI-Q as the primary alternative. The comparison is not simply AWS vs. NVIDIA — it is managed infrastructure vs. self-hosted infrastructure.

Dimension AgentCore NVIDIA AIQ
Deployment model Fully managed AWS service Self-hosted on NVIDIA hardware or cloud
Session isolation MicroVM per session (managed) Container-level isolation (self-managed)
Identity integration Built-in (Okta, Entra, Cognito) Bring your own
Memory management Managed service Bring your own
Policy enforcement Cedar policies (managed) Bring your own
RL training support ART + AgentCore Runtime native Separate training infrastructure
Model flexibility Any model (Bedrock, Anthropic, OpenAI, Gemini, self-hosted) Optimized for NIM-served models
Hardware dependency AWS cloud only On-prem capable, GPU-optimized
Lock-in surface AWS operational layer (memory, identity, policy) NVIDIA GPU stack + NIM format
Primary use case Enterprises already on AWS, wanting fast production deployment Enterprises with on-prem NVIDIA infrastructure, needing inference control

When CIOs choose AgentCore: existing AWS commitment; need for rapid production deployment without infrastructure team; regulatory requirement for audit-logged, policy-enforced agent access; no on-prem GPU investment.

When CIOs choose NVIDIA AIQ: existing NVIDIA hardware investment; need for air-gapped deployment; primary constraint is inference cost/latency rather than operational complexity; already running NIM-served models for other workloads.

The two architectures are not mutually exclusive. An enterprise can run NVIDIA NIMs as the inference backend (pointing AgentCore agents at an on-prem vLLM endpoint) while using AgentCore for the operational layer. The ART training architecture explicitly shows this pattern: AgentCore Runtime for agent execution, NVIDIA vLLM/SGLang for inference, rllm-model-gateway for token capture.

6. CDK Construct — Infrastructure as Code for Bedrock Agents

The agents-for-amazon-bedrock-blueprints repo (awslabs) provides an L3 AWS CDK construct (BedrockAgentBlueprintsConstruct) that abstracts Bedrock Agents configuration into a typed, composable TypeScript API.

Note: this construct targets Bedrock Agents (the first-generation configured service), not AgentCore Runtime. It is the IaC layer for teams deploying Bedrock Agents, not teams deploying arbitrary framework agents via AgentCore.

Key Abstractions

AgentDefinitionBuilder: fluent builder for agent properties — name, instruction, foundation model, prompt overrides from a prompt library. Single object encapsulates what the console wizard spreads across multiple screens.

AgentActionGroup: defines agent actions with associated Lambda function code and OpenAPI schema. Handles Lambda deployment, IAM permissions, and schema registration automatically.

AgentKnowledgeBase: automated provisioning of an Amazon OpenSearch Serverless (AOSS) cluster, S3 data source, knowledge base creation, and data sync. The skipKBCreation=true CDK context flag allows teams to skip the AOSS cost during development.

BedrockGuardrailsBuilder: fluent API for content filtering, PII handling, topic blocking, and profanity filtering. Supports KMS encryption, PII anonymization, and topic-specific allow/deny rules.

Why This Matters for IaC-First Enterprises

Enterprises with mature IaC posture (everything defined in code, reviewed in PRs, deployed through pipelines) cannot use console-configured services for regulated workloads. The CDK construct converts Bedrock Agents configuration into version-controlled, reviewable, auditable infrastructure code. The npm package (@aws/agents-for-amazon-bedrock-blueprints) is installable as a standard CDK dependency.

The construct is published separately from the samples, meaning enterprise IaC teams can use it without inheriting the samples codebase.

7. Enterprise Governance Mapping

HITL Integration Points

AgentCore does not prescribe HITL architecture, but it provides the hooks:

  • Gateway Cedar policies can require human approval before certain tool calls by routing through an approval Lambda
  • The AgentCoreRLApp async model allows human reviewers to inspect rollout results before rewards are assigned
  • Bidirectional streaming enables real-time human oversight of agent reasoning

Audit Trail

Every Cedar policy evaluation is logged through CloudWatch. The combination of Gateway interception + Cedar evaluation logs + OpenTelemetry agent traces creates a three-layer audit record: what the agent attempted, whether it was permitted, and what it actually did.

Regulated Industry Considerations

  • Session isolation via microVM: satisfies regulatory requirements for tenant separation in multi-user agent deployments
  • Memory encryption: managed service handles encryption at rest and in transit
  • VPC integration: Runtime supports VPC security groups for network-level isolation
  • No persistent secrets in agent code: Identity manages credential injection at runtime

Model Risk Management

The online evaluation mode (continuous evaluation of production agent behavior) is the AgentCore mechanism most directly relevant to model risk management frameworks. Continuous behavioral monitoring with configurable evaluators provides the empirical basis for model performance attestation. Cross-reference: model-risk-management wiki for enterprise MRM requirements.

What This Means for Your Organization

The single biggest reason enterprise AI pilots don’t reach production is not model quality — it is the engineering work required to build session isolation, identity propagation, memory, observability, and policy enforcement from scratch. AgentCore removes that barrier for enterprises already committed to AWS.

Framework agnosticism is real but operational lock-in accumulates. Agents written in any framework deploy to AgentCore, but memory, identity, and policy configuration accumulates AWS-specific state over time. The honest evaluation question is not “can we move models later?” but “can we migrate memory stores, Cedar policies, and identity configuration to another runtime if needed?” Assess lock-in at the operational layer, not the model layer.

For CIOs in regulated industries, the Cedar policy enforcement pattern deserves specific attention. Moving access control outside of agent code — into deterministic, formally-validated policies evaluated at the Gateway boundary — is architecturally superior to prompt-based guardrails. An agent that is successfully prompt-injected cannot override a Cedar policy. That distinction matters for model risk management attestation.

If this raised questions about your organization’s path from agent prototype to production — specifically on the identity, governance, or infrastructure side — I’d welcome the conversation at brandon@brandonsneider.com.

Sources

Brandon Sneider | brandon@brandonsneider.com May 2026