AWS Lambda MicroVMs land on the right problem. Every team building agentic systems eventually hits the same wall: you need to run code the model wrote — or that an end user wrote — and you can’t trust it on a shared kernel. The announcement frames it cleanly as “code generated by users or AI in isolated, stateful execution environments.” That second adjective — stateful — is the part that matters.

Until now the choice was bad in two directions. Full VMs give you real isolation but cold-start in tens of seconds, which kills an interactive agent loop. Containers launch fast but share a kernel, so safely containing untrusted code means custom seccomp/gVisor hardening you have to own and maintain. Lambda MicroVMs split the difference with Firecracker: VM-level isolation, near-instant launch and resume, and explicit lifecycle control.

The resume bit is the underrated unlock. Agent loops are long-lived — a planning step, a tool call, a model round-trip, another tool call. If your sandbox is stateless you rebuild the world every turn: reinstall deps, re-mount the repo, re-warm the interpreter. Stateful resume means the environment persists across turns and you pay the setup cost once. That’s the difference between a 200ms tool call and a four-second one, multiplied across every step of every session.

The flip side is what I’d watch in production: per-session VMs are a blast-radius and a billing-surface problem at the same time. A misbehaving agent that spawns environments in a retry loop is now spinning up isolated VMs, and “near-instant” still isn’t free. The HN thread already has people asking about idle cost and eviction policy — exactly the right questions.

Are we finally treating the agent sandbox as a first-class primitive, or just renting Firecracker by the minute and calling it serverless?