Which Sandbox Vendors Support Stateful Execution for Long-Running Agents

Sandbox vendors keep different parts of a long-running agent’s work, from saving files to restoring live processes or forking an environment that is already set up into parallel branches. Assess which state survives, for how long, and behind what isolation boundary. An agent can continue its work if the state it needs survives, or must reconstruct it if that state is lost.

Why long-running agents expose the limits of ephemeral sandboxes

An ephemeral sandbox makes each invocation pay for work already done. When it tears down, the next step must clone repositories, reinstall packages, and rewarm caches before useful work can resume. That repetition burns tokens and adds latency. For a multi-step agent, setup is therefore not just an initial expense but a recurring interruption in the execution loop.

Different workloads expose this mismatch in different ways. A coding agent iterates on test results across many runs, while a PR-review agent may wake sporadically throughout the day. A long-horizon research agent accumulates crawled datasets and conversation history over days or weeks. Their schedules differ, but all build context over time. Working directories, warm caches, and fine-tuned parameters become accumulated capital that sandbox expiry can destroy.

Zhang et al. frame the transition from ephemeral tool calls to persistent workspaces as the architectural leap toward a “digital colleague”. Their “Workspace + Skill” paradigm joins state persistence with reusable procedures and task closure. The distinction is between answering and continuing work. If each invocation loses the environment the previous step worked in, an agent that can reason across steps still has to rebuild that environment to keep working.

What vendors actually mean when they claim "stateful execution"

Tier 1 is filesystem persistence. Installed packages, cloned repositories, build caches, and SQLite files survive a stop, but running processes do not. On the next boot, the agent restarts its dev server and reloads data. Most platforms offer at least this level. It preserves the workspace without preserving everything happening inside it.

Tier 2 is memory, or checkpoint, persistence. A pause checkpoints RAM with disk, and a resume restores processes where they were. A Jupyter kernel keeps its variables, a dev server keeps its port, and a half-finished test run picks up where it left off. This guarantee is harder to implement than retaining files. Far fewer vendors deliver it, and a filesystem-only claim cannot substitute for it when an interpreter must survive a multi-hour pause.

Tier 3 is snapshot-and-fork capability. A snapshot turns state into a reusable artifact, and a fork starts new environments from it. A filesystem fork gives each branch the same files and a fresh boot, while a memory fork lets multiple agents branch from a warmed-up session.

These tiers describe distinct guarantees. Does “resume” mean reopening the same directory, restoring the same processes, or creating another environment from saved state? The answer shows which parts of an agent’s work survive. It also prevents a snapshot feature from being mistaken for a promise that every live process can be copied.

Session caps and what they cut off

A hard session limit can fall inside an agent’s working window even when the platform preserves live state correctly before that limit. The lifetime of a session identifier may also differ from the lifetime of its machine. That distinction changes what continuity actually requires.

AWS Bedrock AgentCore Runtime provisions a dedicated Firecracker microVM per session and routes subsequent invocations with the same session ID to that VM. It preserves in-memory state, environment variables, running processes, and the filesystem. Its original microVM model nevertheless has an 8-hour hard cap per VM. Sessions persist indefinitely, but crossing the VM limit requires migration, with the agent serializing state into an external store and rebuilding on the next microVM. AgentCore added interactive shell sessions in June 2026, with up to 10 concurrent shell sessions per runtime, but terminal continuity for a session’s lifetime is a different guarantee from an unlimited VM lifetime.

Consider a customer-success triage agent that keeps a conversation open for two weeks. The original microVM model forces migration, while AgentCore Instances at 14 days fits that window. A GKE StatefulSet also fits, but bills continuously. Blaxel offers indefinite standby with sub-25ms resume and no compute charges during standby, although storage charges still apply. Fit depends on the shape of the work. A conversation that waits between interactions presents different requirements from a process that must execute continuously, and neither duration nor standby economics settles whether its retained state is safely isolated.

How isolation model shapes what statefulness can safely promise

A long-lived environment also extends the time during which untrusted code can act. In a shared-kernel container, persistence gives code more time to exploit documented escape paths. The saved state is only one concern. Its isolation boundary determines how safely the environment can retain and execute agent-generated code over time.

MicroVMs give workloads their own kernels and hardware-enforced separation, with hardware as the boundary in place of a shared host kernel. AgentCore, Fly.io Sprites, and Blaxel use microVM or Firecracker-inspired models. This design keeps workloads apart from the usual shared-kernel escape paths. It changes the boundary around the persistent computer.

gVisor uses a user-space kernel intercept layer to do this in a different way. Google Vertex Agent Engine on GKE Agent Sandbox uses it, as does Kubernetes SIG Apps agent-sandbox. It provides stronger separation than plain containers without full microVM hardware isolation and suits managed, well-scoped workloads. The Kubernetes project, introduced in November 2025, adds a Sandbox custom resource with pause and resume lifecycle controls backed by gVisor or Kata Containers. Its lifecycle abstraction does not itself implement the isolation boundary.

Compliance introduces a related scope trap. A provider’s certification of its broader platform may leave the sandbox execution product outside its scope. Northflank combines no fixed session time limit with GPU support and a BYOC control plane, and holds SOC 2 Type II and HIPAA compliance with BAAs under Enterprise contracts. Those properties address distinct requirements. Teams still need to establish whether the applicable controls cover the execution layer itself.

Fly.io Sprites and the dedicated-VM model for persistent agent compute

Fly.io Sprites, launched January 9, 2026, treats each agent environment as a persistent computer. Each Sprite is a Firecracker microVM that boots in seconds with 100GB storage and automatically idles when inactive to stop billing while preserving filesystem state. An agent can install packages once, work on more than one task, and read logs from running applications without starting a new workspace for every invocation.

The memory guarantee is narrower than that description might suggest. Sprites retain memory for a short window after the machine goes idle, then drop it when the Sprite goes cold. Filesystem checkpoints support rollback of disk state, but do not restore process memory after a full cold transition. Warm idle and cold storage are different states.

In the three-tier framework, Sprites has Tier 2 persistence when it is idle for a short time and Tier 1 persistence when it stays cold for longer. Is the workspace sufficient, or must the interpreter remain intact?

Beam VMs and what full snapshot-and-fork capability adds to the picture

Beam offers persistent CPU microVMs and sandboxes that together cover all three persistence tiers. Beam’s October 2026 product breakdown distinguishes VM pause, which retains RAM and running processes, from stop, which retains disk. The VMs support SSH, a browser terminal, Docker, systemd, and an Ubuntu desktop with screenshot, click, and typing APIs. Published ports keep the same URL through pause and resume.

The fork boundary requires a separate reading. Beam VM snapshots and forks are filesystem-only, so a VM fork does not copy its live process memory. Memory forks instead use a sandbox memory snapshot. The product path changes the guarantee. Ten agents branching from one warmed-up session require that sandbox memory snapshot path.

That distinction makes Tier 3 qualitatively different from a longer-lived session. An evaluation pipeline can create parallel branches by reusing a shared baseline for each branch. A/B agent testing and fan-out workflows benefit for the same reason. If only installed dependencies and files need to match, a filesystem fork may suffice, while a shared live interpreter requires a memory fork.

How long does resumption take, and does a session cap interrupt the resulting branches? Those remain separate questions from what the snapshot contains, and the persistence tier alone supplies neither answer.

Where purpose-built agent runtimes fit in this landscape

Developer sandboxes built out to serve agents, general cloud compute that makes sessions easier for agents to manage, and autonomous execution runtimes built for agents each start with different ideas about what agents need. A retained disk does not supply the full stack. Long-running agents also depend on lifecycle behavior, provisioning speed, compatibility, isolation, and controls at the execution layer.

Purpose-built runtimes address these requirements together through sub-90ms provisioning, stateful-by-design sandboxes that run indefinitely, Docker-native compatibility, and execution-layer compliance covering SOC 2, HIPAA, and GDPR. These are different dimensions of the design, each with its own role that requires separate consideration. Fast provisioning keeps agents responsive at scale, while Docker compatibility avoids rewriting an existing stack. Neither property alone establishes whether a paused process or a fork preserves memory.

This is the gap that retrofitting persistence onto a generic container or developer sandbox does not, by itself, close. A purpose-built runtime needs to coordinate the full execution lifecycle. Its guarantees still need the same scrutiny. An open-source, transparent implementation lets teams see how the runtime works without having to rely entirely on a black-box service, which helps them assess trust and compliance where security matters but still leaves both for them to assess.

How to match persistence tier and isolation model to your agent's actual workload

The practical decision tree begins with the workload. How long does its working session run, do live processes need to survive pauses, and do multiple branches need to start from a shared baseline? First establish what can restart cleanly. Tier 1 is sufficient for scheduled batch jobs and PR-review agents that reread the repository on each wake, where restarting is acceptable relative to task duration.

If a restart loses live state that the agent needs, it needs Tier 2. Iterative coding agents with dev servers and data agents with Jupyter kernels need process continuity when restarts add meaningful latency or risk partial-state errors. The duration of the pause then becomes decisive. Short-window memory retention is not enough for a workload that requires its interpreter to survive a long cold period.

If parallel copies are required, evaluate Tier 3 and specify what those copies must contain. Evaluation pipelines, A/B testing, and fan-out architectures need a shared baseline so they can skip setting it up each time. Files and live memory are different baselines. The fork path must preserve whichever one the branches depend on.

Next, match isolation to the threat model and duration to the working horizon. Untrusted or AI-generated code in multi-tenant environments calls for microVM isolation, while managed, semi-trusted workloads with narrow tool surfaces can suit gVisor-backed containers. Plain containers work only when the workloads are fully trusted and their blast radius is acceptable. Tasks that take hours can work with AgentCore’s original model and external serialization, while tasks that take days need a limit that gives them enough time, such as the 14-day cap of AgentCore Instances or Google Code Execution, or standby that can last indefinitely. Indefinite continuity requires no standby deadline and durable storage backing.

Compliance scope is the final filter. Check that the controls cover the sandbox execution layer itself. A vendor fits only when its persistence guarantee, lifecycle limits, and isolation boundary all match the work the agent must preserve.