« Phase 20 README · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 20 Warmup — Amazon Bedrock AgentCore

Who this is for: someone who can build an agent (a LangGraph graph, a ReAct loop, a CrewAI crew) and now has to run it in production on AWS — securely, multi-tenant, observable, at scale. By the end you will understand AgentCore not as "another framework to learn" but as the operational layer beneath the framework you already use, service by service, and you will have built faithful miniatures of its three load-bearing parts. No AWS account, no boto3, no network — everything here is mechanism.

Table of Contents

  1. What AgentCore is (and is not)
  2. Why an operational layer exists: the productionization gap
  3. AgentCore vs the older Bedrock Agents
  4. The Runtime and the entrypoint contract
  5. Session isolation and microVMs: the security foundation
  6. Cold start, warm sessions, streaming, and the extended runtime
  7. Gateway: the MCP tool factory
  8. Identity: agent identity and OAuth against any IdP
  9. Policy: Cedar deterministic guardrails
  10. Memory: short-term, long-term, and strategies
  11. Retrieval and namespaces
  12. Observability: OTEL traces of every step
  13. Code Interpreter, Browser, and Harness
  14. When to choose AgentCore (and when not to)
  15. Common misconceptions
  16. Lab walkthrough
  17. Success criteria
  18. Interview Q&A
  19. References

1. What AgentCore is (and is not)

Amazon Bedrock AgentCore is a framework-agnostic, serverless platform for building, deploying, and operating AI agents securely at scale — using any framework and any foundation model. Read that sentence twice, because every word is load-bearing.

  • Framework-agnostic — you keep your agent framework. AgentCore explicitly supports agents written with LangGraph, CrewAI, LlamaIndex, Strands, the Google Agent Development Kit (ADK), the OpenAI Agents SDK, and hand-rolled loops. It supports any model (Bedrock-hosted or not) and the open agent protocols MCP (Model Context Protocol, Phase 03) and A2A (Agent-to-Agent).
  • Serverless — you do not manage servers, autoscaling, or containers-in-a-cluster. You hand AgentCore a packaged agent and it runs it, scaling to zero and up to many concurrent sessions.
  • Operating, at scale, securely — this is the product. Not "help me write the agent" but "help me run the agent I already wrote": host it, isolate tenants, give it memory, expose its tools, authenticate it, authorize its actions, and trace every step.

The single most important framing for an interview: AgentCore is not an agent framework; it is the operational layer underneath one. LangGraph decides what the agent does next. AgentCore decides how that agent is hosted, isolated, remembered, authorized, and observed in production. They are complementary layers, not competitors. If you catch yourself comparing "AgentCore vs LangGraph," you have the mental model wrong — it is "AgentCore hosting LangGraph."

It is delivered as a set of modular services — Runtime, Gateway, Memory, Identity, Code Interpreter, Browser, Observability, Policy — that you can adopt together or independently. You can use only the Gateway with a non-AWS agent; you can use only Memory; you can use all of them. That composability is the deliberate design, and it is what §3 contrasts with the older Bedrock Agents.

2. Why an operational layer exists: the productionization gap

Recall the Phase 00 lesson: most of agent engineering is distributed systems with extra anxiety. An agent that works in a notebook is maybe 20% of the job. The other 80% — the part that pages you — is:

  • Multi-tenancy and isolation. A shared agent service holds many customers' data in flight. If session A's scratchpad, files, or memory can leak into session B, you have a breach, not a bug (Phase 13).
  • Tool access at the boundary. The agent needs to call real APIs — a CRM, a payments Lambda, a search service. Every integration is bespoke glue (the M×N problem, Phase 03), and every call is a privilege-escalation risk if the model is prompt-injected (Phase 10).
  • Memory that survives. A real assistant must remember across sessions — a user's preferences, prior tickets — without you hand-rolling a database schema and a retrieval pipeline (Phase 04).
  • Identity and auth. The agent must authenticate as itself to downstream systems, and users must authenticate to the agent, against the enterprise's existing identity provider.
  • Observability. When an agent misbehaves at 2 a.m., you need a trace of every reasoning step and tool call, in your existing dashboards (Phase 14).
  • Secure code and web execution. Agents that run generated code or browse the web need a sandbox, or they are a remote-code-execution vector (Phase 09).

Every serious team rebuilds these same seven things. AgentCore's thesis is that these are horizontal infrastructure — the same for a LangGraph agent and a CrewAI agent — so AWS should provide them as managed primitives, and you should spend your time on the agent logic. That is exactly the "clean integration boundary between agents, APIs, and enterprise data" the enterprise JDs ask for, offered as a platform instead of a framework.

3. AgentCore vs the older Bedrock Agents

AWS shipped an earlier product literally called Bedrock Agents (also "Agents for Amazon Bedrock"). Do not confuse it with AgentCore. Knowing the difference is a fast credibility signal.

Bedrock Agents (the older thing) is a fully-managed, opinionated agent: you configure it in the console — a foundation model, an instruction prompt, "action groups" (tools, often backed by Lambda), and knowledge bases for RAG — and AWS runs the agent loop for you, its way. It is convenient and low-code, but you adopt AWS's agent shape: its orchestration, its prompt structure, its loop. You cannot bring a LangGraph graph and run it unchanged.

AgentCore unbundles that monolith into composable primitives and inverts the control:

Bedrock Agents (older)Bedrock AgentCore (2025)
What it gives youa whole managed agent (model + loop + tools + KB)separate primitives (Runtime, Gateway, Memory, …)
Who owns the agent loopAWSyou — any framework, any model
Adoptionall-or-nothing, one agent constructà la carte — use one service or all
FrameworkAWS's built-in orchestrationframework-agnostic (LangGraph/CrewAI/Strands/…)
Best forquick, low-code assistants inside AWSproductionizing your agent at enterprise scale

The one-liner: Bedrock Agents is a managed agent; AgentCore is a managed agent platform. The first is a product you configure; the second is infrastructure you compose around an agent you built. This mirrors a general industry move from "here is our agent" to "here is the runtime and plumbing for your agent" — the same reason the framework-agnostic pitch matters.

4. The Runtime and the entrypoint contract

The Runtime is the service that actually hosts your agent. Its contract is deliberately tiny, which is what makes it framework-agnostic: you package the agent behind a single entrypoint.

With the bedrock-agentcore SDK that looks like:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload, context):
    # `payload` is the request JSON; `context` carries request metadata (e.g. session_id).
    result = my_langgraph_app.invoke({"messages": [payload["prompt"]]})
    return {"result": result}

Then the CLI packages and deploys it:

agentcore configure   # containerize the app, create an IAM execution role, set up the runtime
agentcore launch      # deploy to the managed AgentCore Runtime
agentcore invoke '{"prompt": "hello"}'   # call it (or use the InvokeAgentRuntime API)

The mechanism to internalize:

  1. An invocation arrives for some session_id.
  2. The Runtime routes it to an isolated environment for that session (§5), and calls your entrypoint(payload, context).
  3. context gives the entrypoint the session_id and per-request metadata; the return value (a dict for a normal call, or a generator that yields chunks for a streaming agent) becomes the response.

Because the contract is just entrypoint(payload, context), the agent inside it can be anything — a LangGraph CompiledGraph (Phase 18), a CrewAI crew (Phase 07), a raw ReAct loop (Phase 01). The Runtime neither knows nor cares. Lab 01 builds exactly this: a BedrockAgentCoreApp with @app.entrypoint, and a Runtime that drives it — and because the entrypoint is an injected pure function, the whole thing is deterministic and testable without a model.

5. Session isolation and microVMs: the security foundation

Here is AgentCore Runtime's headline property and the reason enterprises trust it for multi-tenancy: each session runs in complete isolation, in its own dedicated microVM.

A microVM is a lightweight virtual machine — think AWS Firecracker, the same technology under Lambda and Fargate. It boots in milliseconds, has its own kernel, memory, CPU, and filesystem, and is torn down when the session ends. Crucially, it is a hardware-virtualization boundary, not a process or container boundary: one session literally cannot address another session's memory or read its files, because they are different virtual machines.

Why does this matter more for agents than for ordinary web requests? Because agents:

  • Accumulate state during a session — a scratchpad, downloaded files, partial results, tool outputs. That state is exactly what must not leak across tenants.
  • Run untrusted-ish code and content — generated code, fetched web pages, tool results that may contain prompt injections. If two users share a process, a compromise in one can reach the other. A per-session microVM contains the blast radius to one session.
   Session A                     Session B                 Session C
 ┌──────────────┐             ┌──────────────┐          ┌──────────────┐
 │  microVM      │            │  microVM      │          │  microVM      │
 │  own kernel   │   NO       │  own kernel   │   NO     │  own kernel   │
 │  own memory   │  ◄──╳──►   │  own memory   │  ◄──╳──► │  own memory   │
 │  own filesys  │  leakage   │  own filesys  │ leakage  │  own filesys  │
 │  A's state    │            │  B's state    │          │  C's state    │
 └──────────────┘             └──────────────┘          └──────────────┘
        the Runtime routes each session_id to its own isolated environment

This is the Phase 00 trust boundary and Phase 13 tenant isolation made physical: isolation is architectural, enforced by the hypervisor, not by careful coding or a prompt. Lab 01 proves the no-leak invariant in miniature: each session_id gets its own store, session B cannot see session A's data, and there is no API to reach another session's state — isolation is structural, exactly as the microVM makes it structural in production.

6. Cold start, warm sessions, streaming, and the extended runtime

Four operational behaviours ride on top of the isolation model, and each maps to a Phase 00 number.

  • Cold start. The first invocation for a new session_id boots a fresh microVM — a cold start. AgentCore is engineered for fast cold starts, but a cold start is still latency you pay once per new session. In Lab 01 this is the cold_start=True flag on a session's first invoke.
  • Warm sessions. A reused session_id keeps its environment warm: the microVM (and the state inside it) survives between the turns of a conversation, so follow-up invocations are fast and can see prior in-session state. This is why short-term memory (§10) naturally lives in the warm session. Lab 01 models this: a session's store persists across invocations, and is_warm reports it.
  • Streaming. For a chat agent you want tokens as they are produced, not one blob at the end. If your entrypoint is a generator that yields chunks, the Runtime streams them (server-sent events). Lab 01's stream() yields chunk-by-chunk from a generator entrypoint.
  • The extended / async runtime. Some agent work is long-running — a research task, a batch job, a multi-step workflow that takes minutes or hours. AgentCore's Runtime supports long-running, asynchronous invocations (sessions can persist for a long duration), so an agent can keep working and report progress rather than being bound to a short request timeout. Conceptually this is the same streaming/warm machinery extended over time.

The latency lesson from Phase 00 applies directly: cold start adds to the tail (p95/p99), so a service that spins up a new session per request pays cold-start latency constantly, while one that reuses warm sessions amortizes it. Where you keep state (warm session vs long-term Memory) is a latency and cost decision, not just a correctness one.

7. Gateway: the MCP tool factory

An agent is only useful if it can do things, and doing things means calling tools. The Gateway is AgentCore's answer to "how do agents get tools, securely, without M×N glue."

Recall the M×N problem from Phase 03: with M agents and N backends, naive integration is M×N bespoke connectors. MCP turns that into M+N by standardizing the protocol. Gateway is the factory that produces the N side automatically. It takes things you already have and converts them into MCP-compatible tools exposed behind a single Gateway endpoint:

  • a plain function → a tool,
  • a Lambda function → a tool,
  • an OpenAPI spec (a described REST API) → one tool per operation,
  • an existing service / API → tools,
  • and it can also connect to existing MCP servers, federating them behind the same endpoint.

Any MCP client — which means any agent framework — then lists the tools (tools/list) and calls them (tools/call) over one protocol, regardless of what the backend actually is. The Gateway also adds production niceties like semantic tool search (when you have hundreds of tools, the agent searches for relevant ones instead of being handed all of them, which bloats context — Phase 04).

   OpenAPI spec ─┐
   Lambda fn  ───┤                                          ┌─ any LangGraph agent
   Python fn  ───┼──►  GATEWAY  ──►  one MCP endpoint  ◄────┼─ any CrewAI agent
   REST API   ───┤   (tool factory)   tools/list, tools/call└─ any MCP client
   MCP server ───┘

Lab 02 builds this: FunctionTarget, LambdaTarget, and OpenAPITarget adapt each backend into a GatewayTool, and the Gateway serves list_tools/call_tool in the exact MCP shapes from Phase 03. The point that lands: Gateway is framework-agnostic on both sides — any agent, any backend, one protocol.

8. Identity: agent identity and OAuth against any IdP

Before a tool call runs, two identity questions must be answered: who is asking (the user or the agent) and is the agent allowed to authenticate to the downstream system as itself. Identity is the AgentCore service for both.

  • Inbound auth — a user or calling app authenticates to the agent. Identity integrates with any standard identity provider over OAuth: Amazon Cognito, Okta, Microsoft Entra ID, Auth0, and others. You do not hand-roll token validation.
  • Outbound auth / credential providers — the agent must call downstream APIs (the CRM, GitHub, a payments service) as a workload with its own identity, using OAuth flows or API-key credential providers, without you pasting secrets into prompts or code. Identity brokers those credentials securely.

The principle is the Phase 00 trust boundary again: authentication establishes the principal on the trusted side before any action is authorized. In the tool-call pipeline (§9) authentication comes first — an unauthenticated caller never reaches the policy check, let alone execution. Lab 02 models this with a small Identity that validates a principal's credential (an injected verifier or a token map) as the first gate of call_tool; a missing or invalid credential is rejected before Policy runs.

9. Policy: Cedar deterministic guardrails

An LLM guardrail that asks a model "should this tool call be allowed?" is itself stochastic — it can be talked out of a "no." Policy is AgentCore's deterministic control: it intercepts every tool call at the Gateway, before execution, and allows or denies it by evaluating rules. Those rules can be written in natural language or, for precision, in Cedar — AWS's open-source authorization language, the same engine behind Amazon Verified Permissions and Verified Access.

Cedar's model is a request of four parts — principal, action, resource, context — evaluated against a set of policies. Two rules make it safe by construction, and you must be able to recite them:

  1. Default-deny. A request is denied unless some permit policy explicitly allows it. The absence of a permit is a denial. (You never accidentally allow something by forgetting a rule.)
  2. Forbid-overrides. If any forbid policy matches, the request is denied — no matter how many permits also match. Forbid always wins. (A blanket "never allow X" cannot be undone by a narrower allow.)

A Cedar policy reads like:

permit(principal == Agent::"support", action == Action::"callTool", resource == Tool::"refund")
when { context.amount <= 100 };

forbid(principal, action == Action::"callTool", resource == Tool::"refund")
when { context.amount >= 1000 };

Evaluation order for a request: gather matching forbids → if any, deny; else gather matching permits → if any, allow; else deny (default). That is the entire algebra, and it is what Lab 02's PolicyEngine implements: permit/forbid rules over (principal, action, resource) with an injected when predicate over the context, evaluated with forbid-overrides and default-deny. Critically, the Gateway runs the policy before it calls the target, so a denied call has no side effect — the lab proves this with an audit log that stays empty on deny.

This is least-privilege (Phase 10) enforced in code on the trusted side of the boundary. The model proposes a refund; a Cedar forbid on the amount disposes of it, and no prompt injection can argue with a deterministic rule.

10. Memory: short-term, long-term, and strategies

An agent with no memory greets you as a stranger every turn. Memory gives AgentCore agents two tiers, and the split is the whole design.

Short-term memory is the current session's event log — every turn (the user said X, the agent did Y), appended in order, scoped to one session_id. It is what multi-turn context is built from within a conversation, and it lives naturally in the warm session (§6). It is ephemeral: when the session ends, the raw turns are gone.

Long-term memory is what persists across sessions. You do not keep raw turns forever; instead you run strategies that extract durable records from the event log and file them under namespaces. AgentCore ships three built-in strategy types:

  • summary — a running summary of a session (e.g. namespace /summaries/{sessionId}).
  • semantic — extracted facts (e.g. /facts/{actorId}): "the user is allergic to peanuts," "the account is on the enterprise plan."
  • user_preference — learned preferences (e.g. /preferences/{actorId}): "prefers window seats," "wants terse answers."

Two properties follow from keying records by actor (the user) rather than by agent:

  • Shareable across agents. A booking agent and a concierge agent that use the same memory store both read and write /preferences/{user} — one agent's learning benefits the other.
  • Persists across sessions. Because records live in long-term namespaces independent of any session, a brand-new session retrieves what earlier sessions learned. This is the "learns from experience" claim: consolidation turns transient turns into durable memory.

The extraction step — turning turns into records — is the "intelligent" part; in production a model does it. Lab 03 injects it as a pure function (a summarizer / fact extractor), exactly the Phase-00 "inject the model" seam: the store's mechanics (event log, namespaces, dedup, consolidation, retrieval) are deterministic and testable independent of how clever the extractor is. Consolidation is idempotent (re-running it does not duplicate records), so it is safe to run repeatedly — a small but real production property.

11. Retrieval and namespaces

Storing long-term records is half the job; getting the right few back at the right moment is the other half. Retrieval in AgentCore Memory is by namespace + relevance: you ask a namespace (say /facts/{user}) for the records most relevant to a query, and it returns the top matches by semantic similarity.

The namespace is the organizing key. It scopes and shares memory: /facts/{actorId} groups a user's facts (shared across agents and sessions for that user); /summaries/{sessionId} groups a session's summaries. Templating the namespace with {actorId} / {sessionId} is how you decide the granularity of sharing — per-user, per-session, per-agent. Lab 03 models this: strategies whose namespace template contains {actor} group events per actor before extracting, so each user's records land in their own namespace.

Relevance in production is vector similarity over learned embeddings. Lab 03 uses a stdlib bag-of-words cosine so the mechanism is visible and deterministic: tokenize, build term-frequency vectors, normalized dot product, rank descending, tie-break by insertion order for stability. It is the same shape as a real vector retriever (Phase 05) — a normalized dot product over the query and each candidate — with a transparent similarity function instead of an opaque embedding model. The lesson carries: retrieval quality is a function of the similarity signal and the ranking, and you test the ranking, not the embeddings.

12. Observability: OTEL traces of every step

You cannot operate what you cannot see. Observability in AgentCore emits OpenTelemetry (OTEL) traces for each step an agent takes — each model call, each tool invocation, each memory read — as spans, which flow into CloudWatch and any OTEL-compatible backend you already run.

Why OTEL specifically matters: it is the vendor-neutral tracing standard (Phase 14), so an AgentCore agent's traces land in the same dashboards as the rest of your microservices — no special agent-only tooling. A trace of an agent invocation is a tree of spans: the top span is the invocation, children are the reasoning steps and tool calls, each with timing, inputs/outputs (subject to redaction), and errors. That is exactly what you need at 2 a.m. to answer "why did this agent loop / stall / call the wrong tool / cost so much," and it is what turns the Phase 00 cost and latency math into observed reality: token counts per step, p95 per tool, where the chain spent its time.

This lab track builds the trace/meter mechanics in Phase 14; here the point is that AgentCore gives you step-level OTEL for free, which is a real reason to run agents on it rather than wiring tracing by hand.

13. Code Interpreter, Browser, and Harness

Three more primitives round out the platform; you should know what each is for, even though the labs focus on Runtime/Gateway/Policy/Memory.

  • Code Interpreter — a sandboxed environment where the agent can execute code (data analysis, calculations, file transforms) safely. This is the Phase 09 secure-sandbox lesson as a managed service: generated code runs in isolation, so it cannot touch your systems even if the model is manipulated into writing something hostile.
  • Browser — a managed, cloud-based headless browser the agent can drive to navigate and extract from web pages. Web content is untrusted input (a classic prompt-injection vector, Phase 10), so running the browser in AgentCore's isolation, not on your app server, is the safe design.
  • Harness — a managed agent loop that runs inside an isolated microVM. Where the Runtime hosts your loop, the Harness offers a managed loop for cases where you want AWS to drive the reason→act→observe cycle for you, still inside the same isolation model. It is the bridge back toward "managed agent" convenience without giving up the isolation and primitives.

The through-line across all of these is the same as §5: isolation is the product. Whether it is a session, generated code, or a browser tab, AgentCore's answer is "run it in its own isolated environment so a compromise stays contained."

14. When to choose AgentCore (and when not to)

The senior skill is not "AgentCore is good," it is knowing when it is the right tool.

Reach for AgentCore when:

  • You are an AWS shop and want to productionize agents you built in any framework without rebuilding hosting, isolation, memory, tool access, identity, and tracing yourself.
  • You need strong multi-tenant isolation (per-session microVMs) for a shared agent service — a regulated or enterprise setting where a state leak is unacceptable.
  • You want deterministic authorization (Cedar Policy) on every tool call, not an LLM guardrail.
  • You want to adopt these capabilities incrementally — e.g. just the Gateway today, Memory later — rather than committing to a whole agent product.

Do not reach for AgentCore when:

  • You need a quick, low-code assistant entirely inside AWS and are happy with AWS's agent shape — that is what Bedrock Agents (the older managed agent) is for (§3).
  • You are not on AWS, or you are avoiding cloud lock-in — AgentCore is AWS-specific. The concepts (session isolation, an MCP gateway, Cedar-style policy, memory strategies) are portable and worth knowing regardless, which is the point of building the miniatures; the service is not.
  • Your "agent" is really a workflow (Phase 00) — hard-code it; you may still use AgentCore primitives (Gateway, Identity) around it, but you don't need the autonomous-agent machinery.

The honest framing for an interview: AgentCore is newer (GA'd in 2025), so knowing it is a differentiator, but be candid that it is AWS-specific and relatively young — you are betting on the primitives, which are the right abstractions, more than on any one API surface that may still evolve.

15. Common misconceptions

  • "AgentCore is an agent framework like LangGraph." No — it is the operational layer beneath the framework. It hosts your LangGraph/CrewAI/Strands agent; it does not replace it.
  • "AgentCore is just the new name for Bedrock Agents." No — Bedrock Agents is a single managed agent (AWS owns the loop); AgentCore is composable primitives (you own the loop, any framework).
  • "Session isolation is a container boundary." It is a microVM (hardware-virtualization) boundary — stronger than a container, which shares the host kernel. That distinction is the whole security argument.
  • "Policy is an LLM checking the tool call." No — Policy is deterministic (Cedar). Same request, same decision, every time; no prompt can argue with it. That is the entire point of using it instead of a model-based guardrail.
  • "Memory just stores the chat history." Short-term does; long-term runs strategies that extract durable, namespaced facts/preferences/summaries that persist across sessions and are shareable across agents. The extraction is the interesting part.
  • "You must adopt all of AgentCore." The services are independently adoptable — use only the Gateway, or only Memory, with a non-AWS agent if you like.
  • "Gateway is a proxy." It is a tool factory: it converts backends (functions, Lambdas, OpenAPI) into MCP tools and can federate MCP servers — not merely forward requests.

16. Lab walkthrough

Build the three miniatures in order; each isolates one AgentCore service and injects the model so it stays deterministic.

  1. Lab 01 — Runtime & session isolation. Implement BedrockAgentCoreApp (@app.entrypoint, @app.ping), a RequestContext, an isolated Session, and a Runtime whose invoke/stream run the entrypoint in the session's own store. Prove no cross-session leakage, warm-vs-cold start, streaming, and LRU session eviction (the microVM pool). 25 tests.
  2. Lab 02 — Gateway & Policy. Implement FunctionTarget/LambdaTarget/OpenAPITarget → GatewayTool, a Gateway serving list_tools/call_tool (MCP shapes), a Cedar-style PolicyEngine (default-deny, forbid-overrides, when conditions), and an Identity gate. Prove that deny happens before execution (no side effect). 24 tests.
  3. Lab 03 — Memory strategies. Implement create_event (short-term), consolidate (strategy extraction into namespaces, idempotent), and retrieve (bag-of-words cosine). Prove cross-session persistence and cross-agent sharing. 25 tests.

Run each with LAB_MODULE=solution pytest test_lab.py -v first (green reference), then fill your lab.py to match, then read solution.py's main() output.

17. Success criteria

  • You can explain, in one sentence each, what Runtime, Gateway, Memory, Identity, Policy, Observability, Code Interpreter, Browser, and Harness do.
  • You can state why AgentCore is not an agent framework and how it differs from Bedrock Agents.
  • You can explain microVM session isolation and why it is stronger than container isolation.
  • You can recite Cedar's two rules (default-deny, forbid-overrides) and why Policy is deterministic.
  • You can explain short-term vs long-term memory and what a strategy extracts into a namespace.
  • All three labs pass under both lab and solution (74 tests total).

18. Interview Q&A

Q: Is AgentCore a competitor to LangGraph? A: No — they are different layers. LangGraph is an agent framework: it decides what the agent does next (nodes, edges, state). AgentCore is the operational layer that hosts that agent in production: serverless runtime with per-session microVM isolation, a tool gateway, cross-session memory, identity, deterministic policy, and OTEL observability. You run your LangGraph graph on AgentCore. If someone frames it as "vs," they have the mental model wrong.

Q: How does AgentCore differ from Bedrock Agents? A: Bedrock Agents is a single fully-managed agent — you configure a model, instructions, action groups, and knowledge bases, and AWS runs its loop. AgentCore unbundles that into composable, independently adoptable primitives and inverts control: you own the agent loop in any framework, and AgentCore provides the horizontal infrastructure (runtime, gateway, memory, identity, policy, observability). Managed agent vs managed agent platform.

Q: What makes AgentCore's session isolation trustworthy for multi-tenancy? A: Each session runs in its own dedicated microVM (Firecracker-class), with its own kernel, memory, and filesystem, torn down at session end. It is a hardware-virtualization boundary, not a process or container boundary that shares a host kernel, so one tenant's session cannot address another's state even under a compromise. Isolation is architectural, not a matter of careful coding — which is exactly what you want when a single service holds many customers' in-flight data.

Q: Why is AgentCore Policy better than an LLM guardrail for tool authorization? A: Because it is deterministic. Policy uses Cedar — permit/forbid over (principal, action, resource, context) with default-deny and forbid-overrides — and evaluates on every tool call before execution. The same request always yields the same decision, and no prompt injection can argue it out of a forbid, unlike a model asked "is this safe?" You put the deterministic check on the trusted side of the boundary; the model only ever proposes.

Q: Walk me through AgentCore Memory. A: Two tiers. Short-term is the session's event log — raw turns, scoped to one session, ephemeral. Long-term persists across sessions: strategies (summary, semantic facts, user_preference) extract durable records from the event log into namespaces keyed by actor. Because records are keyed by user, not agent, memory is shareable across agents; because they live in long-term namespaces, they persist across sessions — the "learns from experience" property. Retrieval is by namespace plus relevance. The extraction is model-driven in production, which is exactly the seam you stub to make the pipeline testable.

Q: The Gateway — what problem does it actually solve? A: The M×N tool-integration problem. It converts functions, Lambdas, OpenAPI specs, and existing services into MCP-compatible tools behind one endpoint, and can federate existing MCP servers. Any MCP client — any agent framework — lists and calls tools over one protocol regardless of the backend, so you write the integration once and every agent reuses it. It also adds semantic tool search for large tool sets so you don't dump hundreds of schemas into context.

Q: When would you not use AgentCore? A: If you're not on AWS or you're avoiding lock-in (the concepts are portable, the service isn't); if a quick low-code assistant inside AWS suffices (that's Bedrock Agents); or if the task is really a workflow, not an agent (hard-code it). AgentCore earns its keep when you're productionizing a real, framework-built agent at enterprise scale and want isolation, deterministic authz, memory, and observability as managed primitives.

Q: It's new — why should I bet on it? A: I'm betting on the primitives, which are the right abstractions — per-session isolation, an MCP tool factory, Cedar-style deterministic policy, memory strategies. Those ideas are correct regardless of vendor, which is why I can build faithful miniatures of them offline. The specific AWS API surface is young and will evolve; the mental model is durable, and it maps cleanly onto MCP, guardrails, and multi-tenant isolation I already know.

19. References

  • Amazon Bedrock AgentCore — documentation. https://docs.aws.amazon.com/bedrock-agentcore/
  • Amazon Bedrock AgentCore — product / overview page (framework-agnostic, serverless pitch). https://aws.amazon.com/bedrock/agentcore/
  • bedrock-agentcore Python SDK & agentcore starter toolkit (the @app.entrypoint / configure/launch/invoke surface). https://github.com/aws/bedrock-agentcore-sdk-python
  • Agents for Amazon Bedrock (the older, fully-managed Bedrock Agents) — for the §3 contrast. https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html
  • Cedar policy language (the Policy engine's semantics: permit/forbid, default-deny, forbid-overrides). https://www.cedarpolicy.com/ and https://docs.cedarpolicy.com/
  • Model Context Protocol (the Gateway's tool protocol; Phase 03). https://modelcontextprotocol.io/
  • A2A (Agent-to-Agent) protocol. https://a2a-protocol.org/
  • Firecracker microVMs (the isolation technology). https://firecracker-microvm.github.io/
  • OpenTelemetry (the Observability trace standard; Phase 14). https://opentelemetry.io/
  • Anthropic, Building Effective Agents (workflow-vs-agent framing; Phase 00). https://www.anthropic.com/research/building-effective-agents