Real-World Architectures on Amazon Bedrock AgentCore

Amazon Bedrock AgentCore is a modular, serverless platform for deploying and operating AI agents at scale on Amazon Web Services (AWS). It launched in preview on July 16, 2025, reached General Availability (GA) on October 13, 2025, and has since evolved at an extraordinary pace — roughly 40 significant feature releases in its first 12 months — into a 13-service platform.

That velocity is the first thing any builder needs to internalize: a source three months old can describe a fundamentally different platform than the one that exists today. The second thing is subtler, and it’s the single most important finding of this report: AgentCore is infrastructure, not a framework. Comparing it to LangGraph or CrewAI is a category error. It’s the deployment, identity, memory, observability, and tool-gateway layer that wraps those frameworks’ code.

This report synthesizes ten parallel research perspectives — architecture, practitioner experience, open-source survey, human-in-the-loop, framework comparison, DevOps, skeptic, security, cost, and platform evolution — to answer one practical question: what do real-world AgentCore implementations actually look like, and what patterns emerge from the code practitioners are writing?

The short answer: a platform that is architecturally distinctive but operationally immature. Its defining property is composability — it is framework-agnostic (Strands, LangGraph, CrewAI, Google’s Agent Development Kit (ADK), the OpenAI Agents SDK, and custom code all work) and model-agnostic (any Large Language Model (LLM), not just those hosted in Amazon Bedrock). But it ships real gaps in human-in-the-loop control, a genuinely unresolved security surface, and cost defaults that can quietly bankrupt a naive deployment.

Figure 1 — AgentCore is a portfolio of 13 modular services, each with independent APIs, that can be used together or à la carte.

The Architecture: How AgentCore Works Under the Hood

A composable platform, not a monolith

AgentCore isn’t one service — it’s thirteen: Runtime, Harness, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy, and Registry. The architectural philosophy is “bring your own framework and model.” Every service exposes independent APIs and integrates through protocol contracts rather than being a single monolithic agent runtime. You can adopt Memory without Runtime, or Gateway without either.

microVM-per-session compute

Each user session in AgentCore Runtime gets a dedicated Firecracker microVM — a lightweight virtual machine — with isolated CPU, memory, and filesystem. This is VM-level isolation, not container-level: after a session ends, the entire microVM is terminated and its memory sanitized, eliminating cross-session data contamination. A microVM persists for up to 8 hours of total runtime with a default idle timeout of 15 minutes (remember that number — it comes back in the cost section as the most expensive default in the platform).

Harness vs. Runtime: two deployment models

The most important architectural distinction is who writes the orchestration loop:

Figure 2 — Runtime hosts your loop; Harness provides one. The Harness runs inside Runtime.

• Runtime is a serverless host: you bring the agent code (any framework, or none), wrap it with the SDK’s BedrockAgentCoreApp entrypoint, package it into an ARM64 container or zip, and deploy. The loop is yours.
• Harness is a managed agent harness: the loop itself is provided (powered by Strands Agents, an open-source AWS framework). You declare what the agent is — model, system prompt, tools, memory, limits — as configuration. No code.

Nearly every feature follows this pattern: Harness = configuration, Runtime = you write code. The exceptions are telling — Harness does not support framework choice, bidirectional streaming, non-agent-loop patterns (graph/workflow), or lifecycle hooks. Those are Runtime-only.

Four protocol contracts

Runtime speaks four protocols, each with its own port and message format:

All support both AWS Signature Version 4 (SigV4) and OAuth 2.0 authentication. The container must be built for linux/arm64 and bind to 0.0.0.0. The /ping endpoint is the health contract: {"status": "Healthy"} means idle and waiting; {"status": "HealthyBusy"} keeps the session alive past the idle timeout for background work.

Gateway, Memory, and Policy

Gateway is a fully-managed AI gateway — a single, secure entry point for agentic traffic. It aggregates MCP targets into one virtual MCP server, proxies HTTP targets, and (since June 2026) routes LLM traffic to model providers via unified inference targets. It also handles inbound auth, credential injection per tool, and semantic tool selection to keep prompts small.

Memory is two-tier: short-term (turn-by-turn within a session) and long-term (persists across sessions, extracting user preferences, facts, and summaries). Three strategy tiers trade cost against control, from fully built-in extraction ($0.75 per 1,000 records/month) down to self-managed pipelines ($0.25). Memory stores are shareable across agents — the substrate for multi-agent state sync.

Policy is where the architecture gets genuinely interesting. It intercepts all agent traffic through Gateway and evaluates each request against policies written in Cedar (AWS’s open-source policy language) before allowing tool access. Policy sits as a boundary outside the agent’s code — every tool call is intercepted and evaluated deterministically, no matter how the agent is implemented. This prevents policy bypass through agent manipulation. But hold that thought: as the security section shows, Cedar constrains what tools can be called, not what reasoning leads the agent to call them.

Figure 3 — A production request: authenticate with an Identity Provider, invoke Runtime, run the loop in a microVM, and route every tool and model call through the Cedar-policed Gateway — all traced via OpenTelemetry to CloudWatch.

The Developer Experience: Building with AgentCore

The BedrockAgentCoreApp pattern

Every code-based agent wraps a single class from the bedrock_agentcore Python SDK. It extends Starlette (a Python web framework) and exposes three routes — POST /invocations, GET /ping, and a WebSocket. You register your logic with the @app.entrypoint decorator:

1
from bedrock_agentcore import BedrockAgentCoreApp
2
from strands import Agent
3

4
app = BedrockAgentCoreApp()
5

6
@app.entrypoint
7
async def handler(request):
8
    prompt = request.get("prompt")
9
    agent = Agent()
10
    async for event in agent.stream_async(prompt):
11
        yield event
12

13
app.run()

Return an async generator and the response streams as SSE; return a plain dict and it’s a JSON response. The entrypoint optionally receives a context object carrying session_id and request headers — the hook for session-aware, multi-user agents.

The deployment loop is agentcore create → agentcore dev (local hot-reload with a browser-based inspector) → agentcore deploy → agentcore invoke. One caveat that bites newcomers: the older Python bedrock-agentcore-starter-toolkit is deprecated in favor of the Node.js @aws/agentcore CLI, yet most tutorials online still use the deprecated toolkit. Both share the agentcore command name, which causes collisions.

The “meta tool” multi-agent pattern

The most sophisticated real-world pattern comes from the aws-samples/sample-multi-agent-on-agentcore repo: a central orchestrator that dynamically discovers sub-agents from the AgentCore Registry and generates typed tools from their JSON schemas at startup.

1. Discovery — query the Registry for approved agents and fetch their MCP tool descriptors.
2. Dynamic tool generation — for each agent, use exec() to synthesize a Python function whose signature matches the schema, then apply the @tool decorator.
3. Invocation — each generated tool opens a temporary MCP session to the Gateway and calls the sub-agent.
4. Semantic search — past ~10 agents, a search_agents tool backed by Registry semantic search is added.

The payoff: adding a new sub-agent requires zero orchestrator code changes — register it in the Registry with an MCP descriptor and it’s automatically available.

Memory that’s transparent to the agent

The canonical practitioner pattern integrates Memory through Strands lifecycle hooks: a MessageAddedEvent hook retrieves relevant memories and injects them before processing a query, and an AfterInvocationEvent hook saves the interaction afterward. The agent code never changes — conversations are persisted and recalled automatically.

Human-in-the-Loop: Patterns and Gaps

Here’s the most consequential operational finding: AgentCore has no native construct that pauses agent execution, waits for human input, and resumes. Unlike LangGraph’s interrupt() or AWS Step Functions’ callback patterns, AgentCore’s services are built around synchronous or streaming execution with deterministic policy enforcement. Human-in-the-loop (HITL) must be composed from other services or handled at the framework layer.

The aws-samples/sample-human-in-the-loop-patterns repo offers four deployable methods:

Cedar can help — it can enforce input conditions like context.input.amount < 1000 to gate high-risk actions. But it evaluates synchronously and returns only permit or deny; it cannot pause to request human approval for gray-zone actions (a refund between $1,000 and $10,000 needing manager sign-off). For asynchronous approval, AWS Step Functions with the .waitForTaskToken callback pattern is the canonical answer.

Three gaps remain unfilled: no “approval required” response code (Gateway is binary permit/deny), no AWS-published end-to-end “pause, review, resume” reference architecture, and no interruption API to pause a running invocation mid-execution.

A financial-services architecture decision record adds a sharp warning: the requireConfirmation flag “can be bypassed by prompt formulation.” If the system prompt tells the agent to “be proactive and execute without unnecessary confirmation,” the model may rationalize skipping it. The recommendation: defend with the Gateway flag and an explicit system-prompt instruction.

The Comparison: Escaping the Category Error

The correct mental model bears repeating: AgentCore is a hosting layer, not a competing framework. “AgentCore vs. LangGraph” is malformed. The right comparisons are AgentCore vs. Azure AI Foundry Agent Service (both managed hosting layers) and LangGraph vs. CrewAI (both frameworks). AWS’s own Strands Agents is the framework that competes with LangGraph; AgentCore is the platform that hosts them all.

Against its closest peer, Azure AI Foundry:

Azure has deeper enterprise distribution and a no-code agent tier; AgentCore has more framework choices, native payments, and Cedar policy. Choose AgentCore if you’re on AWS and want managed infrastructure with policy enforcement across any framework; choose Azure for Microsoft-stack distribution; choose LangGraph or CrewAI directly when you want maximal control over the agent graph itself.

Security: The Unresolved Attack Surface

This is the section that should give architects pause. Researchers from Sonrai Security, Palo Alto Networks Unit 42, BeyondTrust Phantom Labs, the Cloud Security Alliance (CSA), and Zenity have documented a series of vulnerabilities — most of which AWS classifies as “expected design behavior” rather than defects, placing the mitigation burden on customers.

Three findings deserve elaboration:

• Privilege escalation via Code Interpreter. Any principal holding bedrock-agentcore:InvokeCodeInterpreter can execute code under the agent’s IAM role, not their own — effectively assuming the agent’s permissions. AWS doesn’t support resource-based policies on AgentCore resources, so Service Control Policies (SCPs) are the only centralized prevention.
• Sandbox escape. BeyondTrust published a working Proof of Concept (PoC) showing that the Code Interpreter’s “Sandbox” mode — marketed as “complete isolation with no external access” — permits unrestricted outbound DNS, enabling a full reverse shell and exfiltration of S3, Secrets Manager, and DynamoDB data. AWS updated the docs; it applied no service-side fix.
• Memory poisoning. Unit 42 showed that indirect prompt injection can write adversary-controlled instructions into long-term memory, which persist across sessions as trusted context. The CSA confirmed no memory-integrity verification is documented. AWS calls this “an unsolved security challenge in the LLM,” not a platform vulnerability.

The Cedar caveat, made concrete: policies gate which tools an agent may call, not why it calls them. An injected instruction that manipulates the agent’s reasoning to use a permitted tool for an unintended purpose is invisible to Cedar. The CSA’s warning is blunt: “Enterprise teams should not interpret Cedar Policy adoption as a comprehensive mitigation for prompt injection risk.”

Exactly one CVE in this set was promptly patched — CVE-2026-12530, an argument-injection flaw in the SDK’s install_packages(), fixed in bedrock-agentcore 1.6.1. Notably, it was the one reported by an independent researcher rather than a security vendor.

Cost and Performance: Real-World Numbers

AgentCore’s cost model rewards expertise and punishes naivety. Two case studies frame the range.

The $14.50 → $0.40 optimization. A real enterprise ran a browser-operation agent whose naive implementation re-sent the full conversation history every loop, costing $14.50 per process. Three levers, applied in order: prompt caching ($14.50 → $2.10), prompt tuning (→ $1.00), and model right-sizing from Claude Sonnet to Haiku (→ $0.40). The order matters — caching first for the biggest absolute dollar impact, model swap last because it carries the most quality risk. Critically, the savings landed almost entirely on the model token line, not AgentCore’s per-component pricing.

The $6,500/month observability trap. AWS’s own pricing example produces $6,500/month in telemetry alone, before any inference. AgentCore Observability is a CloudWatch pass-through with no native cap. The fix — percentage-based span sampling (10% captures enough for anomaly detection) — cuts it ~90%. This is the single most underestimated line in practitioner bills.

Two defaults dominate the bill:

• The 15-minute idle timeout is the most expensive default in the platform. CPU drops to zero during idle (I/O-wait is free), but memory keeps billing at peak for every second the session is alive. Practitioners drop it to 2–5 minutes for interactive agents and 60 seconds for fire-and-forget jobs. This CPU/memory asymmetry, one practitioner said, “is the whole game” of AgentCore cost engineering.
• Model tiering is the largest lever at fleet scale. A modeled 100-agent fleet cost ~$12,396/month unoptimized versus ~$1,883 optimized — a ~$126K/year delta — and the dominant factor was moving from all-Sonnet to a tiered mix (10 Sonnet / 40 Haiku / 50 Nova Micro), an 87% cut on the biggest line.

One counterintuitive performance finding: the microVM is not the bottleneck — the LLM is. A stress test of 100 parallel tool calls kept the microVM at 0.8 vCPU average with zero throttles; 75% of total time was autoregressive LLM decode. More compute quota doesn’t help, because token generation is sequential per request.

Where the Sources Disagree

The platform’s velocity makes many “contradictions” merely temporal — two sources correct at different dates:

• VPC support for Runtime. An August 2025 source said “no VPC support (confirmed limitation)”; current docs detail full VPC configuration. Both were right — Virtual Private Cloud (VPC) support shipped in September 2025.
• Non-Bedrock models. A skeptic source claimed AgentCore is Bedrock-only; the docs say model-agnostic. The skeptic conflated AgentCore with the older Bedrock Agents Classic. AgentCore has always been model-agnostic — though the managed Gateway inference-target proxy only arrived June 2026, which likely fed the confusion.
• Multi-agent support. “No native multi-agent support” vs. “a sophisticated multi-agent orchestrator exists” — both partly true. There’s no first-class supervisor primitive, but the Registry, Gateway, and A2A protocol provide the infrastructure to build one. Multi-agent here is an emergent architecture, not a built-in feature.

Devil’s Advocate: The Case That This Report Is Overstated

Intellectual honesty demands the counter-argument:

• Temporal bias. Several findings drew on sources from August–September 2025, when the platform was weeks old. By July 2026, VPC support, the CLI, and the Harness are all GA, and many early bugs are fixed. The security and skeptic sections may paint a darker picture than the current platform deserves — check the release notes before assuming any specific criticism still applies.
• Security findings come from security vendors. Four of nine findings come from companies that sell security products. The research is rigorous and PoC-backed, but these vendors have a commercial interest in documenting mitigable vulnerabilities. And the privilege-escalation, sandbox-escape, and memory-poisoning issues are class-level challenges for any agent platform that executes code or stores memory — not unique to AgentCore.
• The open-source catalogue is AWS-dominated. Of 20+ repos surveyed, the vast majority live under aws-samples or awslabs. The one verified production deployment (a Costco price-match iOS app running for under $1/month) is by an individual, not an enterprise. Whether independent projects proliferate is the real test of ecosystem health — and it’s too early to tell.
• What if the thesis is wrong? The implicit claim is that real patterns are emerging from real code. But the platform is 12 months old; many “production” deployments may be prototypes that get rewritten, and the Harness (GA only in June 2026) may obsolete many of the code-based patterns documented here. Read this as a snapshot of an early-adopter ecosystem, not a mature field.

The honest bottom line: AgentCore is production-capable for teams with strong AWS expertise who can navigate its security and operational complexity — not the “deploy in one command” experience the marketing implies. The infrastructure is real and genuinely distinctive; the maturity bar for using it safely is higher than it looks.