Why Provisioned Filesystem Capacity Is the Wrong Unit for Unpredictable Agent Working Sets

Isolated per-tenant storage for multi-tenant AI agent applications needs a separate storage boundary for each customer, with no need to fix how much space each gets. Provisioned filesystem capacity is the wrong unit because an agent’s footprint depends on work that has not happened yet. The better model bills active data elastically, preserves state across restarts, and keeps tenant credentials and data separate as workspaces grow and branch.

Why agent working sets cannot be predicted at provision time

An agent’s working set can swing from near-zero to tens of gigabytes within a single session. Installing packages, compiling binaries, downloading datasets, and caching intermediate outputs all change its footprint. Retries add another source of uncertainty. A task that looks small at launch can accumulate artifacts through repeated attempts, while another finishes with little to keep.

That variability creates a long-tail capacity problem, although the supplied research does not establish a power-law distribution or filesystem swings into hundreds of gigabytes. Unlike a REST handler that finishes in milliseconds and leaves a clean slate, an agent can run for minutes or hours, retaining tool connections and in-process state. Its footprint grows and shrinks as it retries and branches. To predict how much storage the artifacts will need, the operator must predict the agent’s execution path before the agent has chosen it.

The two failure modes provisioned capacity forces on operators

At deploy time, fixed provisioning asks the operator for a capacity number. That number cannot know which packages the agent will install, which datasets it will fetch, or how many attempts it will make. So provisioning for the median puts sessions that need more space at risk. When a session exhausts its volume, writes fail, and the task can fail with them. If the work so far is lost, the agent must start again, and the choice made before the task began adds the cost of doing that work again.

Provisioning for the tail avoids that particular shortage by reserving space most sessions will not use. Under a fixed-provisioning model, idle reserved capacity costs just as much as active capacity, so most sandboxes can use only a fraction of their volume while the fleet pays for all of it. Every fixed number leaves at least one failure mode unresolved, because the uncertainty belongs to the workload.

How persistent sandboxes change the storage billing question

With persistence, that uncertainty lasts for the life of a project. Installed packages, crawled datasets, conversation history, and cached artifacts must survive stops and restarts if the agent is to resume useful work. Storage is now a workspace. The operator must account for what earlier sessions left behind as well as what the next session might add. A capacity guess made at launch becomes less useful as that history accumulates.

Stopping compute should not require discarding the workspace, while keeping the workspace should not require reserving its eventual peak size. Archil meters storage on active data, with billing following bytes actually written.

Copying important outputs to S3, R2, or a workspace service before sandbox termination is another way to preserve selected state. But it moves responsibility back into the agent’s workflow. The agent must manage that state externally, adding latency, fragility, and engineering work.

Why branching and parallel attempts make the provisioning problem acute

Branching multiplies the working set by an unpredictable number of concurrent attempts. With fixed provisioning, each branch either gets its own reserved space or has to compete for space in a shared allocation. The first multiplies idle space. The second introduces contention and the possibility that one attempt consumes capacity another needs. Even a good estimate for one execution path says little about how much space a session needs when it tries several paths at once.

Copy-on-write changes the accounting because branches share base storage until they diverge. The correct unit is delta bytes. The ParallelEnv paper represents execution as a state graph over immutable environment snapshots. Its tree-forking results on a software engineering benchmark show a materially higher resolve rate than single-path baselines at matched compute budget. That makes parallel branching a practical execution technique, rather than an elaborate way to produce more directories.

BranchFS, proposed at the Agentic OS Workshop in March 2026, makes the separation explicit. Its userspace filesystem supplies copy-on-write branching, while branch() coordinates process creation and mount namespace isolation. DeltaBox extends checkpoint and restore to coupled filesystem and memory state for inference-time MCTS search and RL training fan-out. Both designs treat branching as an operation on state. Speed is part of that design requirement. Systems with instant fork-and-checkpoint primitives, including Archil’s disks that checkpoint and branch in milliseconds regardless of size, let attempts diverge without reserving every possible path in advance.

Giving agents access to large datasets without provisioning for them

The working set also includes what an agent reads. Copying a terabyte-scale dataset into a local volume before work starts sets aside space for data the agent may never read in full. It also delays the first useful read. Mounting the object store instead lets the agent treat the bucket as its working directory without first making a complete local copy. Under active-data billing, the relevant footprint is the subset touched.

Amazon S3 Files, announced April 7, 2026, lets applications mount an S3 bucket as a shared filesystem without a gateway, third-party tool, or data copies. Applications read and write through the filesystem interface, and S3 stores the data. Its stage-and-commit model accumulates changes on the filesystem side before pushing them back as whole objects. This separates access to a large dataset from the need to provision a volume large enough to hold it.

Explicit downloads create local state that an agent must remember, and context compaction can lose the record of what was downloaded, prompting repeat transfers. Filesystem access makes that bookkeeping less central to the task. FUSE-based drivers such as gcsfuse, Microsoft’s blobfuse2 for Azure Blob Storage, and AWS’s Mount Point established the broader pattern of presenting object data through a filesystem. Accessing a bucket should not force the operator to buy local capacity for all of it.

How do you keep each customer’s agent storage isolated?

Each agent’s storage must be as bounded as its compute, because workspace files, cached secrets, and in-process context can cross tenant boundaries if cleanup is not rigorous. A sandbox boundary cannot compensate for shared storage access. The storage design must preserve separation wherever a workspace is attached, including when the compute environment stops, resumes, or branches. Capacity and permission are different controls.

Compute isolation constrains those attachment choices without supplying a universal winner. Standard containers share the host kernel, and CVE-2024-21626, associated with “Leaky Vessels,” demonstrated a container escape. Firecracker microVMs use a separate kernel per workload but add 150 ms to 2 s to cold starts. gVisor offers user-space kernel protection with faster cold starts and narrower compatibility, while browser isolates start quickly but support fewer languages. The choice follows the threat model. None of these options makes the storage boundary somebody else’s problem.

Two 2026 advisories cover an out-of-bounds write in Firecracker’s virtio PCI transport and arbitrary host file overwrite through a symlink in the jailer. The first reaches the host boundary under additional preconditions. The second is host-side privilege escalation, and neither is a demonstrated full RCE. These findings undermine an unconditional zero-CVE claim.

Credential policy completes the storage boundary. Each agent must use its own tenant identity, with OAuth tokens and API keys stored per tenant in a secrets manager and resolved at call time. Neither prompts nor workspace files should hold those credentials. Network egress should default to deny-all, with external tools receiving credentials at injection time from a platform vault keyed on (tenant_id, integration_type). Shared configuration must not become a side door between otherwise isolated workspaces.

Per-tenant storage at thousands of tenants, and why the silo model breaks first

With thousands of tenants, fixed provisioning makes the same bet on how much space each needs thousands of times. A silo architecture gives each tenant a separate runtime, storage volume, and API endpoint, reserving capacity against each tenant’s theoretical peak. Most tenants are idle most of the time. Their peaks are not correlated, yet the reserved allocations appear together on the bill. The waste is structural.

Active-data billing ties that total bill to what agents read and write, leaving unused allowances out of the charge. Each tenant’s disk can remain isolated by the storage layer while its usage is metered independently, separating the security decision from the capacity decision. To give each customer an isolated workspace, the design needs a distinct storage boundary and tenant-specific access. An empty room is not a lock.

Existing customer buckets can also remain the source of truth. Mounting an S3, GCS, R2, or Azure Blob bucket avoids moving its contents into a platform-owned provisioned volume merely to make them accessible. Revoking access leaves the data in the tenant’s account. There is no migration or copy to unwind, which supports the cost and data-residency requirements together.

What the right storage unit actually looks like in practice

The right unit is active data. That means charging for bytes that exist, including branch deltas. It also means allowing storage to expand and contract with use instead of requiring a new prediction for every session. Archil’s active-data approach is one implementation of that model, with the isolation requirements around it still applying.

Persistence and fast branching then become properties of the same workspace. Installed packages and written files survive compute stops, while checkpoints and branches take milliseconds regardless of the working set’s size. Parallel attempts need not wait for full copies. Because branches share unchanged data, their growth can follow their actual divergence, and rollback need not turn into a separate capacity-planning exercise.

The workspace must also remain useful outside the sandbox. With S3-compatible API access to the same disk, pipelines, downstream agents, and human reviewers can read outputs without first exporting them. When existing buckets are mounted as a POSIX filesystem, agents can use the file access they know, and the bucket stays the source of truth. That is the practical endpoint of elastic storage. Models can work through files and bash without the operator having to guess, before the first command runs, how much disk the last command will need.