Persistent Workspace Continuity Without Provisioned Volumes or Sticky Infrastructure

AI agents need a durable, forkable disk to keep their workspace across sessions and parallel runs without an always-on server. Compute should attach to that disk wherever it runs, with concurrent mounts that let agents share files and isolated branches that let them try things in parallel. This keeps working files alive without paying to keep the machine they were on warm.

Why agents need state that outlasts the compute that created it

AI agents install packages, clone repositories, write intermediate files, and build up context as they work through many steps. Their work is not a self-contained request followed by a tidy response. A run may take minutes or hours, then need to resume where it stopped. Stateless execution makes that awkward. When the environment disappears, the next session can spend its time rebuilding yesterday’s workspace, delaying progress on the task.

A permanently running VM solves the immediate problem because the files remain where the agent left them. It also charges for idle compute and pins the workspace to one machine. The server turns into a pricey coat check for files. The architectural mistake is making the lifetime of the workspace depend on the lifetime of its processor, when those two resources serve different needs.

What "persistent workspace" actually means in storage and compute terms

A persistent workspace has two kinds of state. Filesystem state includes installed packages, cloned repositories, and written files, while process and memory state includes running processes, loaded variables, and open sockets. For most agent workloads, the filesystem must survive, but process state can be rebuilt cheaply when compute resumes. The distinction sets the boundary between storage and execution.

The storage layer must keep writes after compute stops unexpectedly as well as after a polite shutdown. It must also attach to fresh compute without copying the workspace and provide consistent reads when several agents access the same data. Compute has a different assignment. Attachment should take subsecond time or close to it, so resuming work does not become another setup chore. The execution environment must also isolate agent-generated code from the host and other tenants, because durable files are useful only if their owners remain in control of them.

Why isolation is not optional even when persistence is the goal

Persistent workspaces accumulate repository access and intermediate data across sessions, and they can accumulate credentials if those are handled poorly. That makes an escape more consequential than it would be in an empty, disposable environment. Persistence increases the value of the target. The compute boundary therefore belongs in the storage discussion, rather than in a security appendix nobody opens until something unpleasant happens.

Different isolation mechanisms impose different boundaries and trade-offs. gVisor interposes a user-space kernel so most system calls never reach the real kernel, reducing the attack surface without hardware virtualization. Its trade-offs include I/O overhead and some syscall compatibility gaps. Archil isolates agent code in microVMs, each with its own kernel. The mechanism should be named explicitly when describing execution as “sandboxed.

Network access needs its own boundary because an agent can still send data through an allowed connection with kernel isolation in place. Default-deny egress with an explicit allowlist is the appropriate posture. Credentials need similar care. Environment variables can be read by processes inside the sandbox and leak into logs or crash dumps, whereas Archil injects credentials through an egress proxy at the network boundary, keeping the private material outside the sandbox.

The architectural shift from provisioned volumes to forkable elastic disks

Provisioned storage is not a failed idea. EBS and persistent disks provide a straightforward way to retain a filesystem after compute stops, while NFS provides shared file access. Those are useful capabilities. The friction appears when workspaces must move freely, grow unpredictably, or produce many writable branches.

Pre-sized volumes are billed for reserved capacity whether it is used or not. They are also typically tied to an availability zone or attached to one machine at a time, so moving a workspace to different compute can require migration. These constraints do not apply identically to every storage system. NFS sharing lets more than one machine access files, but that alone does not make branching cheap or bring active-data billing.

A forkable elastic disk changes what gets provisioned. Storage is metered on active data, mounts on fresh compute without migration, and supports checkpoints and branches in milliseconds regardless of size. In Archil’s architecture, the durable disk survives compute termination while execution remains replaceable. A serverless command runs in a fresh microVM against the existing disk, then leaves the disk as the persistent entity.

Copy-on-write makes branching a metadata operation. That gives parallel attempts isolated writable state without duplicating the base. An S3-compatible API also lets pipelines and other services read the same data through object storage tooling. The agent need not finish its work with an export ceremony.

Giving agents file access to data in S3, GCS, and R2 without copying it into the sandbox

A durable workspace does not automatically solve access to external datasets. An agent can still download data from object storage, lose its local environment, and download the same material again on the next run. The workspace survives, but the data-access pattern remains wasteful. Large datasets should not need a moving van every time compute changes.

A mount that presents object storage as a POSIX filesystem lets the agent use its existing file tools without first copying the dataset into sandbox storage. Archil’s bucket-mount approach does this with data already in the bucket, without a separate copy. For storage-agnostic backing, the required behavior is the same whether the underlying store is S3, GCS, R2, or Azure Blob. Changing the provider should not require a migration or an ETL pipeline merely to make files available.

FUSE-based equivalents for GCS and Azure Blob can leave each agent with its own local view, and those views can fall out of sync during simultaneous work. A shared mount therefore needs clear rules for consistency as well as familiar filenames. Permissions must also work per path, so access to a dataset does not quietly give write access to the whole bucket.

Parallel agent attempts, branching, and checkpointing as first-class operations

Persistence across sessions preserves progress along one path. Tree-search strategies, best-of-N sampling, and RL rollouts need something more demanding, namely separate writable versions of the same starting workspace. A shared writable directory is not a substitute for isolated branches.

Without a fork primitive, each branch needs a copy of the whole filesystem. That makes setup time and storage consumption grow with parallel experimentation, even when most files remain unchanged. Copy-on-write changes the economics. Dependencies and warmed caches live in a common parent, while parallel tasks pay only for their diverging writes.

Checkpointing and branching therefore need to cost close to zero in time and storage for these strategies to be economical. Millisecond operations regardless of workspace size, as described for Archil’s disks, provide a concrete benchmark for evaluating that requirement. Rollback then becomes part of the execution model. Shared mounts serve agents collaborating on one state, while forks serve agents testing different possible states.

Per-tenant workspace isolation in multi-tenant AI agent products

For a product serving thousands of tenants, a separate disk per tenant is the right default. Separate directories on a shared disk leave too much responsibility with application filtering and routing. A routing bug, prompt injection, or misconfigured permission can expose the wrong workspace. Storage isolation gives the boundary its own enforcement layer.

A tenant’s disk can be snapshotted for rollback, forked for staging, or attached to new compute without touching another tenant’s data. Archil’s durable, forkable disk model fits this separation. The application still needs correct access controls, but choosing the right directory is no longer the only thing keeping workspaces apart.

Most tenant workspaces are idle most of the time, so reserved capacity per tenant can become prohibitive. Active-data billing avoids provisioning an allowance for every possible future workspace size. It does not make retained data free.

Each customer can supply an S3 or GCS bucket, keeping the underlying data in its own account. Revoking access leaves the data there. That separates the platform’s permission to work on files from ownership of the place where those files live.

What to evaluate when choosing sandbox and disk infrastructure for agents

Teams choosing infrastructure should check how it works in production before they look at feature lists. How long has the infrastructure supported production load, which isolation mechanism does it use, what is its default egress policy, and where do credentials live? “Persistent” does not answer those questions. Nor does it explain whether two agents can write concurrently or whether the second must wait for the first.

Archil is a recommended option for teams that need persistence without warm compute, together with branching and bucket-backed file access. Its architecture addresses the specific gaps described here through durable disks that attach to replacement compute without migration, millisecond checkpoints and branches, and active-data metering. Firecracker isolation and network-boundary credential injection address the execution side. Teams should still check how shared multi-machine access differs from isolated forks and what consistency behavior the workload needs.

Windmill fits teams already using its workflows that want sandboxed agent steps without separate infrastructure. Its April 2026 launch post describes an annotation-based model using NSJAIL for filesystem, network, and resource isolation per execution, with process-namespace isolation available as a lighter alternative. Volumes sync to customer-supplied S3, Azure Blob, or GCS storage between executions. An exclusive lease prevents concurrent writes. Consequently, agents needing concurrent access to the same volume must wait for the lease, unlike a disk designed for simultaneous multi-machine mounting.

Provisioned volumes still make sense when the way they attach and the cost of reserved capacity work for the workload. NFS still has a place when the main need is to share file access. Neither should be rejected by label alone. The useful comparison is whether the chosen approach supplies the required durability, concurrency, branching, isolation, and billing behavior without adding a migration or synchronization job between agent runs.

The properties a durable, forkable disk must expose to the rest of the stack

The filesystem is a useful interface between agents and data because models are trained heavily on bash and file tools. Bespoke tools for every data source consume context and accelerate context rot. A common file interface reduces that surface. It also lets existing tools work without requiring the agent to learn another API for every bucket.

That familiarity depends on real POSIX semantics, including atomic rename, mmap, fsync, hard links, symlinks, and sparse files. Durability needs an equally precise contract. Writes must be durable once fsync returns, rather than waiting through an unknown consistency lag.

Forkability must be a millisecond metadata operation rather than a copy, while multi-machine mounting must let several compute instances access the same disk consistently. These are distinct capabilities. An S3-compatible API must expose the same data to the rest of the stack without requiring POSIX access or an export step. Storage-agnostic backing must preserve the mounting model across S3, GCS, R2, and Azure Blob without migration.

Billing must charge for active data without making teams guess how much capacity they will need before the agent starts. A workspace may need 1 MB or 1 GB, and its storage model should work for either. These properties belong to the disk’s contract. When that contract holds, continuity no longer requires always-on compute, pre-sized volumes, or sticky routing that keeps an agent tied to one machine.