A persistent filesystem workspace lets an AI agent keep its work across sessions and parallel runs. But keeping files after a restart is only the beginning. The workspace becomes the agent’s durable identity when other processes can mount it, parallel attempts can branch it without copying the dataset, and failed runs can roll back without rebuilding the environment.
Why an AI agent's filesystem is its identity, not just its storage
Agents are often described as stateless, session-scoped processes. Production work needs something that accumulates progress instead. Installed tools, working files, and intermediate results form the environment the agent learns to navigate and changes as it works. Without that durable environment, a restart erases the work. The agent has a fresh start, which sounds nicer than it is.
A filesystem also lets the model discover context progressively, through bash and file read/write tools it already knows, instead of squeezing everything into the opening prompt. The available context can grow beyond what fits in a conversation. Alternatives such as SQLite for state, S3 links in Postgres, or files synthesized on demand require bespoke tooling to serve as the workspace interface. Those adapters take up context and are hard to use when the work does not fit a clean schema. Each bespoke MCP connector narrows the model’s familiar repertoire, while files give it a universal way to explore.
What "persistence" actually requires across the three scenarios agents face
The first scenario is a session restart. Installed packages, working files, and intermediate outputs must still be there after a stop and resume, without having to be built again. This is the minimum requirement. A volume can meet that need yet fail in the second scenario, when another agent, an evaluator, or the application needs to read and write at the same time from different compute. Storage tied to one node does not cover that handoff.
The third scenario is parallel attempts and rollback. An agent or orchestrator needs independent writable branches so it can try several strategies without duplicating the dataset or mixing their results. Persistence alone does not provide that independence. Consider an agent running python report.py and writing reports/report.pdf, followed by an evaluator running python eval.py and adding reports/results.csv. The application must be able to read both through an S3-compatible API, and each parallel attempt needs its own workspace to start from. These are distinct requirements, even when the product label says only “persistent.”
Why ephemeral sandboxes break long-horizon agent work and what the architecture shift looks like
Ephemeral compute fits poorly with work that accumulates over time. Rebuilding the sandbox every session also rebuilds the agent’s environment, leading to repeated package installs, lost intermediate files, and handoffs serialized through the model’s context window. The agent’s reasoning need not be broken. Its desk is simply being cleared between tasks, sometimes while it is still writing.
The architectural shift is to make the disk durable independently of compute, then attach compute to it. The agent reasons, executes, and persists its results rather than reconstructing its surroundings on each run. Archil implements this pattern by attaching a durable, forkable disk to each Firecracker microVM sandbox, preserving installed packages and intermediate artifacts across pause and resume. For lightweight commands, serverless execution complements the persistent sandbox by running a single command in a fresh microVM against an existing disk.
What isolation model an agent sandbox actually needs and the trade-offs among microVMs, gVisor, and containers
Durability does not make generated code trustworthy. Plain containers using runc isolate processes through Linux namespaces and cgroups, but share the host kernel. A kernel vulnerability can thus give untrusted, model-generated code a way into the host even when the processes are kept apart.
gVisor interposes a user-space kernel that mediates agent code’s access to host kernel syscalls and meaningfully reduces the exposed kernel surface with less overhead than a dedicated VM, making it a reasonable choice when microVM provisioning latency cannot be absorbed. It does not eliminate that surface. MicroVM approaches such as Firecracker and Kata Containers instead give each sandbox a dedicated kernel, placing the intended boundary of a compromise at the VM.
That stronger boundary is not a promise of invulnerability. Escape-class CVEs have appeared against microVM engines, so a credible evaluation needs a named hypervisor, a public vulnerability history, and transparent patching to substantiate a “secure” sticker. No isolation primitive earns unconditional trust. Persistence also has to respect the boundary, with the durable disk attached exclusively to the sandbox by default.
Why egress policy and credential handling are as important as the sandbox boundary
Isolation controls where code executes, while egress policy controls what it can reach. Both are necessary. An agent inside a well-isolated microVM can still leak data or abuse credentials through unrestricted outbound access. A locked room with an unrestricted outgoing mail service is not much of a data policy.
The appropriate default is outbound traffic denied until explicitly allowed, with rules for package registries, git hosts, and model APIs. Dynamic controls make that practical. A sandbox can fetch from an S3 bucket at the start, have its outbound access cut off while it runs, and get permission to upload results again without a restart. Credential brokering keeps secrets outside the sandbox by having an egress proxy inject them at the network boundary, so agent code never sees the raw credential. Cloudflare describes this mechanism for its Sandboxes, including authentication logic customized per outbound host.
How a filesystem mounted across multiple processes enables agent-to-agent handoff without passing content through context
A file path is a cheaper handoff than a serialized payload. Passing an identifier takes a handful of tokens, while passing the contents can take orders of magnitude more and has no direct way to represent binary files. With a filesystem mounted on multiple machines, one agent can write reports/report.pdf, another can read it through a POSIX path, and the application can get it through an S3-compatible API without copying it between stores.
For example, Archil disks support simultaneous mounts across machines and an S3-compatible API, allowing evaluation scripts, batch jobs, and applications to use the same workspace. Its POSIX interface also gives agents in Firecracker sandboxes the read/write/rename operations their training makes familiar. The filesystem becomes a familiar discovery mechanism. Atomic rename, fsync for durability, and hard links let existing scripts, compilers, and test runners work without agent-specific wrappers.
Shared access does not make concurrent writes collision-proof. Advisory locks through flock/fcntl coordinate access within each client. Writers on different machines therefore need explicit ownership or conditional mounts because a local lock cannot coordinate the whole workspace.
How branching and checkpointing make parallel agent attempts and rollbacks operationally routine
Trying strategies in parallel is less appealing if each workspace needs a copy of the whole dataset before it can be used. Forkability removes that preparation cost. A checkpoint captures a named, immutable point-in-time view of filesystem state, and a branch creates an independent writable copy from it without disturbing the original. Checkpoints and branches operate like git commits and branches.
An orchestrator can branch a disk per agent, run strategies against identical starting state, compare outputs, and discard the losing branches. Their changes never contaminate the winner. In Archil, a checkpoint takes about 15 ms and a branch about 35 ms no matter how large the disk is, because neither copies the data. Those timings cover filesystem state only; forking a whole running sandbox also means pausing it and booting the fork, which takes longer.
Rollback uses the same mechanism. A bad run leaves its pre-run checkpoint intact, so recovery means branching directly from that checkpoint. Cloudflare also describes snapshots as a way to recover an agent’s coding session quickly.
How agents access large existing datasets in S3, GCS, and R2 without copying them first
If the system needs a local copy of a large dataset, an agent can be stuck waiting before it runs its first command for the task. Mounting an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket as a POSIX filesystem removes that prerequisite. The agent navigates the mounted path with standard file tools while the bucket remains the source of truth. No migration or ETL pipeline is required. In healthcare, finance, and government, this provides access to unstructured documents that do not fit neatly into database schemas.
In this model, writes become durable once fsync returns and are copied to the bucket in the background, without waiting for a full upload cycle. Bring-your-own-bucket also preserves ownership and residency because revoking the filesystem layer’s access leaves the data in the customer’s account. The applications and pipelines already in use can reach the same disk through an S3-compatible API. There is a visibility caveat, however. A new file can take time to reach an already-running reader on another machine unless that reader explicitly invalidates its cache, so shared access should not be mistaken for instantaneous remote cache updates.
How per-tenant disk isolation structures multi-tenant agent products at scale
A disk per tenant gives a multi-tenant agent product a clear unit of filesystem isolation. Each customer’s agent can see only its own files, with the neighboring tenant’s environment kept out of reach. That boundary fits the work. An agent uses the whole of a customer’s environment as context to reason through its work, instead of treating each record as a task on its own. A dedicated disk preserves that context without pooling customers’ files.
At thousands of tenants, the economics require elastic storage metered on active use because tenant sizes vary by orders of magnitude. Provisioning the same allowance for every tenant wastes capacity. A filesystem service that handles commands in near-constant time regardless of tenant count lets expansion mean adding elastic disks rather than proportionally more infrastructure engineering. Disk-level branching also lets a new version of an agent run against a tenant’s data without changing the live workspace. If a test branch fails, it can be dropped.
For regulated deployments, that structure can preserve residency as well as separation. A healthcare organization can keep patient documents in regionally locked object storage and make them available through paths grouped by facility and department. Immutable audit records of every agent access event complete that deployment pattern. The filesystem layer does not move the documents outside the region, and revoking access leaves them intact in the customer’s account.
What to verify before committing to a persistent filesystem workspace for agents
For buyers, the practical task is to turn these requirements into questions a vendor can answer precisely. Are installed packages still there after a restart, and can the disk exist on its own without compute? Can multiple machines mount it with POSIX semantics, and what prevents concurrent writers from colliding? A demonstration of one surviving file proves neither a reusable environment nor safe shared access.
Security questions need equally specific answers about the hypervisor, published CVE history, default egress policy, and where secrets live. Branching claims need a defined scope too. Archil’s documentation gives approximately 35 milliseconds for creating a branch, and about 15 milliseconds for a checkpoint. An evaluation should establish whether timings stay independent of disk size and whether they cover filesystem state or running process memory.
Archil is one concrete option, with Firecracker microVMs, dedicated persistent disks, multi-machine mounts, and native bucket access without migration. Its sandbox documentation describes per-sandbox egress policies on Developer and above, including deny-by-default rules and credential brokering at the network boundary; a sandbox created without a policy has unrestricted egress. Buyers still need to ask whether per-tenant isolation is the default or an option, whether bills are based on active use, and whether customer data stays intact when bucket access is revoked. Buyers need an operating contract covering both the promise that files will still be there tomorrow and these operational requirements.