Persistent sandboxes for long-running AI agents must preserve more than a folder. Installed packages, working files, and the state needed to continue a task must survive interruptions without a rebuild. The production test is whether an agent can resume correctly, detect what did not survive, and return to a known good state when something breaks.
Why "persistent" means more than keeping files alive
An agent returns after a restart, finds its repository, and continues working on top of a half-finished package install. The files survived, but the environment did not. Worse, the agent may not see that anything has changed. Persistence without recoverability can preserve a broken assumption and let every later step depend on it. A saved mess is still a mess.
A successful return depends on three layers. Filesystem state includes repositories, working files, and generated artifacts, while the installed environment includes packages, language runtimes, and system dependencies. Process memory holds in-flight computation, running servers, and in-memory caches, with open sockets adding another continuity requirement. These layers can fail independently. A coding agent needs its earlier edits across many turns, but an hours-long data task may also need uninterrupted runtime, so “the disk survives” answers only part of the question.
What the isolation model underneath determines about persistence
Containers share the host kernel, so a kernel exploit can cross into other tenants’ state. Plain containers therefore fit trusted code and provide insufficient isolation for untrusted agents in a multi-tenant product. gVisor adds a user-space kernel that an escape must breach before reaching the host kernel, raising the barrier when hardware virtualization is unavailable.
MicroVMs such as Firecracker and Kata Containers give each workload its own kernel under hardware virtualization. That is a stronger starting point for untrusted or self-written code. Many teams use gVisor for routine execution and microVMs for builds and third-party code. GPU workloads complicate that choice because Firecracker does not support GPU passthrough, making gVisor or full VMs alternatives.
That boundary still needs defense-in-depth. Two 2026 Firecracker advisories qualify any claim that published escape-related vulnerabilities are absent. CVE-2026-5747 concerns an OOB write in the virtio PCI transport, rated CVSS v4 8.7, while CVE-2026-1386 concerns arbitrary host file overwrite via symlink in jailer, rated CVSS v4 6.0. Platform teams should revisit assumptions based on the earlier baseline. A boundary weak enough to expose neighboring tenants turns saved state into shared state, undermining the isolation that durable persistence requires.
What actually breaks when a long-running agent session stops
An interrupted package install may leave lock files, partial caches, or PATH mutations that cause import failures later. A development server or database may simply be gone. The agent can still find the source files and issue requests as though the service were alive, which makes this a detection problem as much as a storage problem. Like a cleaning agent working from a mistaken assumption about what belongs where, it can keep acting confidently after its premise has failed.
Writes introduce a quieter form of loss. Results still in an in-memory buffer, without a completed fsync, have no durable record when compute stops. A hard session limit brings the same risk at a set time, so the agent needs external checkpoints or loses process memory at cutoff. Meanwhile, a persistent environment can accumulate broken state across successive sessions unless it offers a route back to a known good version. To avoid these failures, the platform must spell out its write guarantees, restart semantics, and recovery mechanisms.
The durability guarantees a platform must provide before an agent loop can rely on it
When is a write actually safe? The platform must specify whether fsync is required for multi-AZ durability and what happens to unflushed writes when compute stops. It must also explain visibility across machines. Can another mounted reader see a new file immediately, or must it invalidate its cache? Durability and visibility are separate promises.
How do concurrent writers coordinate their work? Advisory locks such as flock and fcntl can coordinate processes on one machine without coordinating writers on different machines. A platform offering multi-machine mounts needs to document the alternative. Otherwise, two agents can both believe they have exclusive access. Confidence is not a locking protocol.
How quickly can the agent checkpoint or branch, and does that time grow with disk size? Minutes can make recovery impractical inside a loop, while tens of milliseconds can make it routine. Does a session cap, such as 24 hours, discard process memory despite preserving files? For an existing bucket mounted as a filesystem, does the customer’s bucket remain the source of truth after platform access is revoked? These questions establish what can be relied on before any product comparison begins.
How egress control and credential handling interact with persistence
A long-lived environment extends the lifetime of its access. Code the agent runs later can still use credentials passed through environment variables, even if that code was generated after the credentials arrived. Credential brokering provides a stronger boundary by injecting API keys at the egress proxy, outside the sandbox. That requires proxy-level header injection.
Network policy must follow the same logic. A known allowlist of package registries, Git hosts, and model APIs limits outbound access by default. Dynamic updates can open access for a data pull, restrict it during execution, and permit an upload endpoint during verification. But new rules may take effect right away only for new connections, while connections that are already open stay open.
Keeping state across sessions without keeping compute running: pause, resume, and snapshot tradeoffs
An intermittent agent needs preserved state without paying for a machine while it waits. With filesystem-only persistence, packages and files survive, but processes, open sockets, and in-memory state are lost. Servers and databases must restart on resume. Memory snapshots preserve process state as well, requiring the platform to serialize CPU and memory state in addition to disk. That adds storage cost and complexity.
A snapshot can also become a reusable starting point. Subsequent sandboxes branch from that point, avoiding an environment rebuild. The snapshot’s scope determines what they inherit. A filesystem image preserves the installed environment and files, while a full sandbox snapshot can also include memory. Calling both operations “pause” does not make them interchangeable.
Persistent VMs bring back resource management, idle charges, and latency tradeoffs that serverless execution was meant to remove. Developers have also reported agents killing their own sandboxes and requiring manual remediation. Yet a function that returns and discards its state cannot provide continuity for long-lived development servers, in-memory caches, databases, or preview URLs. The choice depends on whether the workload needs a remembered filesystem or a continuing process.
Branching and parallel attempts as a first-class part of the agent loop
Branching solves the route-back problem without destroying current work. An agent can preserve a known good checkpoint, explore several approaches independently, and discard unsuccessful branches. That changes the architecture of the loop. It no longer needs to run every attempt sequentially and manually undo each failure before trying again.
TreeRL and Crab frame checkpoint-and-restore at scale as a research problem. DeepSeek’s DSec infrastructure uses host-side checkpoint engines and fast filesystem snapshots to avoid rebuilding common environments. Shared prefixes make repeated setup wasteful. A disk-level branch completed in tens of milliseconds can support speculative execution and parallel evaluation, while capturing CPU and memory has a different latency profile.
For practitioners, the lesson is to inspect what fork() actually does. Does it pause the original sandbox, resume it automatically, and define what happens to in-flight writes? Its presence in an SDK signals support for branching, but not the precise guarantees. Shared mounts still require coordination if a verifier reads while another agent writes. Independent branches and concurrent access to one disk are different operations, even when both involve several agents.
Giving agents file access to existing cloud storage without copying data
An agent reading an existing S3 dataset should not need to download the whole dataset again at every session. That takes time, costs money, and leaves another copy to manage. Mounting the bucket as a POSIX filesystem lets the agent use bash and standard file tools without migrating the dataset. The bucket remains the source of truth. Agents also need access to existing datasets in GCS, R2, and Azure Blob without downloading them again at every session.
Write behavior needs equal attention. Writes should become durable when fsync returns, with background propagation to the backing bucket, while unflushed writes remain at risk if compute stops. An S3-compatible API can also let CI pipelines, downstream services, and reviewers access the same files without mounting the disk. But compatibility is not completeness. Missing S3 versioning or Object Lock can rule out workflows that depend on those primitives, and bring-your-own-bucket checkpoint support may have restrictions.
This does not make filesystems replacements for databases. Documents, logs, and generated artifacts often have no clean schema and work well as files. Structured data with a known schema belongs in a database. The agent needs access to both, without a rule that all storage must look like a directory.
Per-tenant storage and the multi-tenant agent product problem
With bring-your-own-bucket access, each tenant can mount its own bucket. But a product must keep thousands of environments apart and let each recover on its own. The default pattern is one disk per user or workspace, provisioned programmatically without shared state between tenants. Recovery then has a clear boundary. One tenant’s broken environment should have no path into another tenant’s data.
That boundary needs storage-level access control. Disk tokens or IAM conditions scoped to a disk or matching tenant account identifier prevent mount credentials from reaching other tenants’ storage. Application checks alone are not the same guarantee. Encryption at rest and in transit is a basic need, and customer-owned buckets should keep the key management policies they already use without being forced into a key hierarchy.
Location and capacity also become product constraints. For regulated healthcare, finance, and government workloads, teams need to control how data moves across regions and be able to co-locate data with compute. Whether that works depends on which regions and BYOC options are available. A per-organization disk limit can also become a limit on tenant growth. Storage provisioning therefore belongs in capacity planning.
How to evaluate whether a platform's persistence story holds under production load
The practical evaluation starts with interruption. A team should test what pause preserves, what a session cutoff loses, and whether packages and files remain usable after restart. It should examine fsync durability and visibility to an already-running reader on another machine. Checkpoint latency needs testing across disk sizes.
The security review should ask for the named isolation primitive, default egress rules, and the location of secrets. “Secure” describes a quality without specifying an execution boundary. Production history should distinguish when infrastructure first served workloads from when a product page appeared. Teams should also ask how disclosed hypervisor-level vulnerabilities were handled, with the 2026 advisories showing why that question is concrete.
Archil is one credible option, running persistent Firecracker microVMs with a separate Linux kernel and root disk per sandbox on a Firecracker runtime that has run production workloads since 2025. It preserves installed packages and files across restarts, makes writes durable across multiple Availability Zones once fsync returns, and creates a disk checkpoint in about 15 ms and a branch in about 35 ms, regardless of disk size.
Cross-machine writers must use read-only or conditional mounts and explicit checkout rather than relying on per-client flock or fcntl locks, and existing readers may need cache invalidation to see new files promptly. On Developer and Team, bring-your-own-bucket disks cannot be checkpointed or branched (Enterprise offers ones that can), so on those plans they do not fit a workflow that requires that combination. The S3-compatible API also lacks S3 versioning and Object Lock. Free-plan egress uses a managed allowlist that users cannot modify, while Developer plans and above can set custom firewall rules and network-boundary credential brokering.
The deciding criterion for a platform that says “persistent” is whether its guarantees are precise enough to reason about failure before an agent encounters it. What survives, when it becomes durable, who can see it, and how it can be recovered must all have explicit answers. Otherwise, the agent is returning to unfinished business and hoping the furniture has not moved.