« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 20 — Framework Deep-Dive: Amazon Bedrock AgentCore

Answers these JD lines: the enterprise-AWS agent-platform roles you asked to target — where a team wants to productionize agents built in any framework (LangGraph, CrewAI, Strands) on AWS "securely at scale." AgentCore is the newest layer in that stack (GA'd in 2025), so being able to speak to its primitives — Runtime session isolation, the Gateway MCP factory, Cedar Policy, Memory strategies, Identity — is a concrete differentiator on top of the MCP (Phase 03), guardrails (Phase 10), and multi-tenant-isolation (Phase 13) work you have already done.

Why this phase exists

Every other framework phase teaches you to build the agent — the loop (Phase 01), the tool call (Phase 02), the graph (Phase 18). AgentCore is not another agent framework. It is the operational layer underneath whatever framework you chose: you bring the agent, and AgentCore gives you the boring-but-hard production surface — a secure serverless runtime, cross-session memory, a tool gateway, identity, deterministic policy, and observability — as composable, independently adoptable primitives. That "framework-agnostic ops layer" idea is the whole point, and it is exactly the distinction interviewers probe: what does AgentCore do that your agent framework does not, and why would an enterprise pay for it?

Three ideas do most of the work:

1. Framework-agnostic operations. The contract is a single entrypoint(payload, context). Anything that fits — a LangGraph graph, a CrewAI crew, a raw ReAct loop, any foundation model, MCP and A2A protocols — runs on the same Runtime. You are not locked into an AWS agent SDK; you are renting the operations.
2. Isolation is the product. Each session runs in its own microVM with true state isolation; every tool call passes a deterministic Cedar policy check; every credential comes from a real IdP. Security is architectural, not a prompt — the Phase 00 trust boundary, productionized.
3. Composable primitives, not a monolith. Runtime, Gateway, Memory, Identity, Code Interpreter, Browser, Observability, and Policy are separate services you adopt one at a time. This is the deliberate contrast with the older Bedrock Agents (a single fully-managed agent); AgentCore unbundles that into parts you assemble.

Concept map

• Runtime — serverless host for the agent; @app.entrypoint on a BedrockAgentCoreApp; fast cold starts, warm sessions, streaming, and microVM session isolation (Lab 01).
• Gateway — turns functions / Lambdas / OpenAPI specs / existing services into MCP tools behind one endpoint; the M×N-killing tool factory (Lab 02, builds on Phase 03 MCP).
• Policy — Cedar deterministic guardrail that intercepts every Gateway tool call before execution: permit/forbid, default-deny, forbid-overrides (Lab 02, builds on Phase 10).
• Memory — short-term session event log + long-term records extracted by strategies (summary / semantic / user_preference) into namespaces; shareable across agents, persists across sessions (Lab 03, builds on Phase 04).
• Identity — agent identity + auth against any IdP (Cognito/Okta/Entra ID/Auth0) + credential providers (touched in Lab 02).
• Also: Code Interpreter (sandboxed code, Phase 09), Browser (cloud browser tool), Observability (OTEL traces per step, Phase 14), Harness (managed agent loop in a microVM).

The labs

Integrated scenario (how this shows up at work)

Your team built a customer-support agent as a LangGraph graph (Phase 18). It works in the demo. Now make it a multi-tenant production service on AWS. You don't rewrite it. You wrap the compiled graph in an @app.entrypoint, agentcore launch it onto the Runtime so each customer session runs in its own microVM (Lab 01 — no tenant sees another's state). You register the CRM's REST API and a refund Lambda through the Gateway as MCP tools (Lab 02), and write a Cedar Policy that permits the refund tool only for authenticated support-tier agents and only for amounts under a threshold — enforced before execution, so a prompt-injected refund never fires (Phase 10). You turn on Memory so the agent recalls a customer's prior tickets and preferences across sessions (Lab 03), Identity so the agent authenticates to the CRM as itself via your IdP, and Observability so every step is an OTEL span in your existing dashboards (Phase 14). The agent framework never changed; you productionized it with composable primitives. That is the AgentCore pitch, and being able to narrate it end-to-end is the Staff-level signal.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• Lab 02 green; you can state Cedar's default-deny + forbid-overrides semantics.
• Lab 03 green; you can explain short-term vs long-term memory and strategy extraction.
• You can name each AgentCore service and what it replaces/composes.
• You can explain how AgentCore differs from the older Bedrock Agents.

Key takeaways

• AgentCore is the operational layer, framework-agnostic: you bring the agent, AWS runs it.
• Session isolation via microVMs is the security foundation that lets one service host many tenants' agents safely.
• Gateway = MCP tool factory; Policy = Cedar deterministic guardrail on every tool call.
• Memory strategies turn raw turns into durable, shareable, cross-session knowledge.
• The senior framing: "AgentCore doesn't make my agent smarter; it makes it deployable, secure, and observable at enterprise scale — the 80% of agent engineering that isn't the LLM."