Stateless Agent Runtimes Need Stateful Storage Infrastructure

Isolated per-tenant storage for multi-tenant AI agent applications needs customer workspaces that last, an execution boundary that keeps agent-generated code inside it, and controls on network access and secrets. Stateless agent runtimes cannot supply durability themselves. Their storage infrastructure must preserve work across restarts, support fast forks, and provide shared access to source data without weakening tenant isolation.

Why stateless runtimes cannot hold production agent state on their own

An agent spends hours refactoring a codebase, hits its context window, and starts over. The files may hold the work so far, but the reasoning the agent needs to go on is gone. A five-minute demo can hide that gap. Rebuilding for a short task is wasteful, while losing accumulated context halfway through a long software engineering job makes the agent unreliable. Each new session then burns tokens going over work it has already done.

The architectural mismatch sits beneath the model. A stateless reasoning core operates inside a runtime that many platforms also treat as stateless, leaving the surrounding infrastructure responsible for durable files, installed packages, conversation context, and execution position. Agent Sandbox documentation explains why the usual Kubernetes Deployment assumptions fail here. Pods are interchangeable, but an agent is a singleton whose request 7 needs the instance that handled requests 1 through 6. A size-one StatefulSet with a Service and PersistentVolumeClaim approximates that arrangement, but it is cumbersome and has no built-in hibernation.

Durability therefore needs a home outside the replaceable runtime. Archil pairs persistent Firecracker microVM sandboxes with durable, forkable disks that survive restarts, preserving the working environment across resumes. That addresses the filesystem side of the problem. Preserving every kind of agent state requires more than keeping a disk alive, however, and “persistent” alone does not explain what survives.

The four storage properties that determine whether a production agent succeeds where a demo worked

Persistence across restarts means that the filesystem, installed packages, and working directory survive a stop and resume. Without it, the agent repeatedly reconstructs its workplace before doing useful work. Isolation means that agent-generated code cannot reach the host or neighboring tenants when it misbehaves or is compromised. A durable workspace and protection from other tenants are different requirements, even when one platform supplies both.

An environment can branch in milliseconds, while a full copy takes seconds. That difference governs whether parallel attempts and rollback fit into ordinary execution or become exceptions reserved for special occasions. Shared access lets more than one agent or session use the same source data at the same time. Without it, each agent keeps a copy of its own. The agents then have to keep those copies in sync as well as finish the original task.

None of these properties compensates for another’s absence. A persistent environment with expensive forks discourages parallel attempts that could make the agent more reliable, while shared access without isolation creates a security liability. The evaluation therefore concerns the combination. A platform can have a long product page and still leave one of these jobs to the developer.

What persistence across restarts actually requires from the storage layer

Two pause operations can preserve files while producing very different resumes. A full pause keeps both files and memory state, so a process can pick up mid-execution. A filesystem-only pause retains files but reboots on resume, losing processes and in-memory state. The disk survives, but the running program does not. Calling both operations “pause” hides the distinction that determines how much work the agent must reconstruct.

A filesystem-only resume requires reinitializing working state. Dependency setup may also need rebuilding where it was not retained in the persistent environment. A persistent sandbox, by contrast, keeps its filesystem, installed packages, and working directory from one session to the next. For long-running projects, persistent sandboxes such as Archil’s spare the agent from having to rebuild those resources over and over. An ephemeral sandbox runs one task and is destroyed when that task ends, which is a different bargain.

The memory layer also serves a separate purpose. LangGraph checkpointers serialize an execution graph so a process can resume after a crash, while semantic memory tools retain facts and entities for retrieval across sessions. Neither substitutes for the filesystem holding the agent’s actual working environment. Statefulness has an operating cost through storage, retrieval, and synchronization. The alternative also has a cost, paid in repeated setup, errors, and tokens spent rebuilding context.

Persistence is therefore a prerequisite for platforms. Platforms can be compared by the state that survives and the work needed to reconstruct the rest before execution continues. Once the environment survives, it can support longer projects and become a starting point for further attempts. But keeping that environment available introduces another obligation. Its contents must remain beyond the reach of neighboring tenants.

How do isolated customer workspaces prevent data leaks between agents?

Standard containers share the host kernel, so they are not a sufficient boundary for untrusted agent-generated code. A compromised agent can threaten both its container and the host. That is the problem behind the isolation requirement. Giving every customer a workspace does not establish that the code running inside it is safely contained. “It runs in a container” describes packaging.

MicroVMs, including Firecracker and Kata Containers, and gVisor provide different approaches to that boundary. gVisor intercepts syscalls through a user-space kernel, defending against host kernel bugs at a performance cost for syscall-heavy workloads. Firecracker runs a real guest kernel and is designed to contain a compromised guest. Hardened containers make another trade-off between performance and isolation, but containers remain appropriate only for trusted code under the requirements here. An agent writing what it executes removes that assumption of trust.

MicroVMs still require patching and verification. The 2026 paper identified as arXiv:2606.08433 documents Firecracker’s first published escape-class CVEs, including CVE-2026-5747, an out-of-bounds write into the VMM heap with a CVSS v4 score of 8.7 high. It also documents CVE-2026-1386, an arbitrary host file overwrite through a symlink in the jailer, scored 6.0 medium.

Isolation also needs limits on what leaves the sandbox. Unrestricted outbound access lets an agent exfiltrate data or act on external systems, while credentials injected into its environment are accessible to generated code. The safer pattern brokers credentials at the network boundary so secrets never enter the execution environment. A checkable vendor claim names the hypervisor, default egress policy, and location of secrets. GPU workloads add a narrower constraint because Firecracker lacks GPU passthrough, leaving gVisor or full VMs as the hardware-accelerated options described here.

Why forking the agent’s environment needs to be fast enough to be routine

Duplicating an entire environment makes every branch wait for a copy. That delay means teams have to plan parallel attempts and rollback into the architecture instead of using them as a matter of course. Many teams consequently skip them. Agents that do test-time tree search or reinforcement-style exploration are hit especially hard because they need frequent state branching. When everything is copied at every turn, deeper search and larger fan-outs have to wait for the storage operation.

DeltaBox, described in arXiv:2605.22781 in 2026, tackles both file and process state. Its filesystem component organizes files into layers, freezes the writable layer at a checkpoint, and inserts a new one so updates use copy-on-write. Its process-state component uses incremental process-state dumps and accelerates rollback by forking from a frozen template process. Together, they achieve a 14 ms checkpoint and 5 ms rollback. Those measurements make “fast enough to use routinely” more concrete than a promise of rapid snapshots.

Disk branching and process rollback are related but distinct capabilities. With durable, forkable disks, Archil is one option for preserving and branching an agent’s working environment. Branching in milliseconds regardless of disk size, without requiring a full duplicate, is decisive for storage. At that speed, an agent can use speculative branches before risky actions and try parallel attempts on subtasks that are unclear.

The 2026 paper “Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback” identifies how a faithfully restored checkpoint can lose the dependencies that justify security-relevant state. An agent can resume as though an action never happened even though an email was sent or an external file was written. Checkpoint restoration and transactional semantics for tool calls are not yet unified. Teams therefore need to reason about which calls are idempotent before treating rollback as full recovery, even when branching is fast enough to become routine.

How agents can work against large object-store datasets without copying them first

Copying a large dataset into a sandbox before every session makes data preparation the first bottleneck. It delays useful work, duplicates storage costs, and creates a synchronization problem when several agents need the same source. Each session gets its own moving target. Syncing S3 into a separate volume can provide local files, but it also creates another copy to maintain. Shared access is meant to remove that extra job.

Mounting the backing store offers a different pattern. An ML job can work directly against S3 data, while an agent accesses that data through filesystem paths. FUSE tools such as Mountpoint for Amazon S3, gcsfuse, and blobfuse2 expose object stores through filesystem interfaces, yet object stores do not support every file operation. These tools may need extra metadata or reject operations that the store underneath cannot handle.

gcsfuse, for example, does not fully comply with standard filesystem semantics, so not every data I/O operation works correctly. Shared access must therefore be judged against the operations the agent’s tools actually need, rather than whether a bucket appears in a directory listing. Mounting the same source also leaves cross-client locking guarantees to be checked on their own. Access and coordination are separate questions.

Vercel Sandbox added FUSE support on July 3, 2026, allowing remote storage, network filesystems, and custom FUSE drivers to appear as normal filesystem paths inside a running sandbox. That makes direct access available without first copying the dataset into the environment. It does not erase the underlying driver’s limits. For multi-tenant applications, shared source access must also coexist with isolated customer workspaces.

How these four requirements shape the choice of sandbox infrastructure in practice

An evaluation starts by checking what is still there after a restart, including files, packages, and process memory. It then asks which hypervisor provides isolation, what outbound traffic is allowed by default, and where secrets live. Forking needs an equally concrete question. Does a checkpoint use filesystem-level copy-on-write, or does each branch duplicate the disk? Storage integration completes the test by establishing whether existing S3, GCS, R2, or Azure Blob data can be mounted directly.

Different platforms divide those responsibilities differently. Kubernetes Agent Sandbox, generally available on GKE since May 20, 2026, gives each agent a stateful pod with a stable identity and supports high-throughput sandbox allocation. The developer still owns storage integration and the persistence model. Archil combines persistent Firecracker sandboxes with durable, forkable disks and offers external mounts and network controls. Those features make it an option to consider, but its exact pause behavior, fork latency, and isolation defaults still need to be checked.

Amazon Bedrock AgentCore Runtime provides Firecracker microVM isolation, session routing, memory, and filesystem persistence within the AWS infrastructure landscape. Its preview began in July 2025, followed by general availability in October 2025. It was already shipping by the April 2026 developer update. The co-developed Stateful Runtime Environment discussed in the February 2026 OpenAI–Amazon partnership was a separate forthcoming offering. Keeping that distinction clear prevents a new announcement from obscuring an existing product.

Cloudflare Workers use V8 isolates across a global edge network and are stateless by design. They are not, on their own, a fit for agents that need persistent working state. Production history also needs a close look because real agent load brings out failure modes that a launch page cannot show. For isolated per-tenant storage, the choice rests on the combined behavior of durable workspaces, containment, branching, and shared access.