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

Phase 20 — Staff Engineer Notes: Amazon Bedrock AgentCore

Anyone can wire @app.entrypoint and agentcore launch. The gap between using AgentCore and being trusted to own it is a small set of judgment calls that don't have a documented right answer — you have to reason from the constraints. This doc is that reasoning: the decisions you own, the framework for reaching for it, the review red flags, the war stories, and the exact signal an architecture review listens for.

The decisions a staff engineer actually owns

1. Build vs adopt vs stay managed. The first call is not "how do I use AgentCore" but "should I." Three roads: roll your own hosting/isolation/memory/policy (you will rebuild the seven horizontal things badly); adopt AgentCore primitives around your own agent loop; or stay on the older Bedrock Agents managed agent. You own picking the road and defending it — including the honest downside that AgentCore is AWS-specific and young.

2. Session lifetime and warm-pool economics. Nobody hands you the right session TTL. Too short and you thrash cold starts; too long and you pay to hold idle microVMs. This is a latency-versus-cost curve, and the input is turns per session — the ratio that decides whether the microVM model is cheap or ruinous for your workload. Establishing that number is a staff move; guessing the TTL is not.

3. Memory namespace design. {actor} vs {session_id} vs per-agent is a security and product decision disguised as a naming convention. Get it wrong and you either build an amnesiac (state in the wrong scope) or a cross-tenant leak (records keyed so tenants collide). You own the namespace schema the way you'd own a database schema.

4. Policy authorship and default-deny discipline. Who may call which tool, under what when conditions, and — critically — the discipline that every new tool starts denied and earns a permit. You own the policy set as a security artifact, and you own testing the denials.

5. Where the trust boundary sits. The model proposes; deterministic code on the trusted side disposes. You own keeping authorization (Cedar/Policy), content-safety (Guardrails — a different system), and identity (IdP/IAM) in separate boxes and never letting an LLM be the thing that authorizes a side effect.

A decision framework: when to reach for it

Reach for AgentCore when the answers line up: On AWS? yes. Multi-tenant service where a state leak is unacceptable? yes — per-session microVMs are the argument. Do you want to own the agent loop in your framework? yes. Do you want deterministic authorization on every tool call? yes. Do you want to adopt incrementally (Gateway now, Memory later)? yes.

Reach for Bedrock Agents (the older managed agent) when you want a quick, low-code assistant inside AWS and are happy with AWS's agent shape and orchestration — and you don't need to bring a custom loop.

Reach for neither / portable concepts when you're not on AWS or are avoiding lock-in. The ideas — per-session isolation, an MCP tool factory, Cedar-style deterministic policy, memory strategies — are portable and worth building yourself (which is exactly why these labs build miniatures); the service is AWS-specific.

Reach for a hard-coded workflow when the "agent" isn't one. If control flow is fixed, don't buy autonomous-agent machinery — though you may still use Gateway/Identity around it.

Code-review red flags

  • Policy checked after the tool runs. The authorize step must strictly precede execute; a deny that fires after the refund handler already moved money is the canonical bug. The tell: an audit/side-effect log that isn't empty after a denied call.
  • Shared state across sessions "to save cold starts." Any global keyed by session id that the entrypoint can iterate, or a shared process pooling users, defeats the isolation that is the entire product. Cold-start optimization belongs in warm-pool sizing, not in dissolving the boundary.
  • An LLM asked "is this tool call allowed?" Authorization must be deterministic. A model gate is stochastic and injectable — a downgrade from Cedar, not a feature.
  • Treating Policy as content-safety (or vice versa). "Our guardrail blocks unsafe tool calls" is the classic confusion. Guardrails is is this text OK to show a human; Policy/Cedar is is this principal allowed to do this action. Different systems, different boxes.
  • Long-term memory storing raw transcripts. No strategy, no dedup, unbounded growth, degrading retrieval. Long-term memory is extracted, namespaced, deduplicated records — not the chat log.
  • A memory namespace not templated by actor (or templated by agent when it should be actor), silently sharing one user's records into another's scope.
  • A new tool shipped with a broad permit "to unblock." Default-deny means new tools fail closed; the review should see a narrow permit with a tested when, not a wildcard.
  • "AgentCore vs LangGraph" anywhere in the design doc. Wrong layer — AgentCore hosts LangGraph. This phrasing reveals the mental model is off.

War stories

  • The shared-process leak. An early internal agent ran all users in one process "to save cold starts." One session's cached file surfaced in another's context — a breach, not a bug. Per-session microVMs exist precisely so that is structurally impossible; the fix wasn't more careful coding, it was the boundary.
  • The refund the prompt talked into happening. A support agent guarded refunds with an LLM "are you sure?" A crafted message walked it past. A Cedar forbid(resource=="refund") when {amount >= 1000} on the Gateway would have denied it deterministically, before execution — no argument possible, no money moved.
  • The amnesiac agent. Great demo; every session started cold with no history or preferences. Turning on Memory strategies (semantic, user_preference) keyed by actor made it feel like it knew the user across sessions — the difference between a toy and an assistant.
  • The cold-start storm. A team minted a fresh session_id per request in a k=1 workload, so every invocation paid a cold start and p99 was dominated by boot. The fix was reusing sessions across a conversation, not more compute.
  • The "we'll just use Bedrock Agents" wall. A low-code Bedrock Agent hit a branching loop AWS's orchestration couldn't express; the rewrite onto a custom framework would have been free on AgentCore, where you keep the graph and rent the ops. Know which product you're choosing and why.

The signal an interviewer or architecture review listens for

They are not checking whether you can list the services. They are listening for whether you hold the boundaries correctly, under pressure:

  • You say "AgentCore hosts LangGraph, it doesn't compete with it" without prompting — you have the layer model right.
  • You recite default-deny and forbid-overrides and can explain why a two-pass evaluation makes forbid-overrides order-independent.
  • You distinguish microVM from container as a hardware-virtualization boundary and tie it to blast radius, not just recite the word.
  • You separate Policy (authorization) from Guardrails (content-safety) from Identity (authn) into distinct boxes and don't let them bleed.
  • You know Bedrock Agents and AgentCore are different products, and can narrate the unbundling and why it happened.
  • You put numbers on it — turns-per-session driving cold-start tail, warm-pool sizing, per-session cost — instead of hand-waving "at scale."

Deliver those and you're the person handed the "make this production-ready" problem instead of the person who built the demo.

Closing takeaways

  1. AgentCore doesn't make your agent smarter; it makes it survivable — isolated, authorized, remembered, observed. That is the 80% of agent engineering that isn't the LLM.
  2. Isolation is the product, and it's architectural. Per-session microVMs contain a compromise to one session; no amount of careful coding gets you that from a shared process.
  3. Determinism belongs on the trusted side. Cedar authorizes, the model proposes. Never let an LLM be the gate on a side effect.
  4. Memory design is schema design is security design. Strategies keep it small and high-signal; the namespace template decides who shares what — and who must not.
  5. Bet on the primitives, be honest about the vendor. The concepts (isolation, MCP gateway, Cedar policy, memory strategies) are durable and portable; the AWS API surface is young and will move. That candor is itself a seniority signal.