Mounting a Single Persistent Volume Agents Read and Write Across Every Session

Mounting a single persistent volume across agent sessions lets each run build on the work of the ones before it. For isolated per-tenant storage in multi-tenant AI agent applications, that shared workspace belongs within each customer’s storage boundary. The architecture needs durable writes, coordinated access, and compute isolation so that an agent can keep yesterday’s work without seeing somebody else’s.

Why session continuity requires a shared persistent disk, not just better prompting

A coding agent spends a session installing packages, cloning a repository, and preparing a build, only to restart in an empty sandbox. In the next session, the agent has to do the setup again before it can start useful work. Conversation history may describe every step, but it cannot bring back the missing dependencies, generated files, or test outputs. A longer prompt does not repair that storage failure.

A persistent volume is a durable filesystem whose lifetime is separate from the sandbox that mounts it. Archil pairs each sandbox with a persistent disk that survives restarts and can be mounted across multiple sessions, leaving installed packages, generated files, and intermediate state accessible without re-derivation. This makes the disk a complement to in-context memory. Sessions can also read one another’s outputs through that shared workspace. When agents share files, they no longer need to pass every artifact through a message, but they still need rules for write-coordination that prompting cannot provide.

What "persistent" actually means across the three layers where state can live

Compute-layer persistence preserves RAM and process state through a pause or snapshot. It helps a paused sandbox resume, but it does not give the workspace an independent lifetime after compute deletion. Filesystem-layer persistence, including the durable, forkable disk used by Archil, preserves files, packages, and task artifacts outside that compute lifecycle, surviving compute deletion and remaining accessible from multiple machines.

Session-state persistence is what the agent chooses to write down for later use, including investigation notes, task summaries, and conversation history. The volume supplies the medium. If the agent never writes its findings, the next session has nothing to read back. Prompt threading cannot preserve binary artifacts or large intermediate outputs, while a preserved filesystem cannot reconstruct an unwritten decision.

How writes survive restarts — durability guarantees a shared disk must provide

A persistent volume earns the name only if acknowledged durable writes survive an abrupt stop. Agents use ordinary POSIX tools such as write, close, and fsync without knowing what is beneath the filesystem. The crucial contract is that fsync returning means the data has reached durable storage. A buffered write is not that promise. If the filesystem reports durability while changes remain only in a temporary buffer, terminating the sandbox can erase work the agent believed was safe.

The underlying object store’s durability does not settle this question, because the filesystem must first deliver the bytes to it. In Archil’s design, changes go back to the underlying object store, and the durability gate depends on that flush completing before control returns to the agent. Windmill syncs changed and new files after execution, updates metadata, and only then releases the volume lease. The gate is the important architectural detail. Strong per-key object-store consistency governs writes once they reach the store.

Storage deletion must also be distinct from sandbox deletion, so that removing compute leaves the volume intact and reattachable. Otherwise, a successful flush merely preserves files until the wrong lifecycle event arrives. For agent builders, the practical test is deliberately ungentle. Write a file, ask for the promised durability, kill the sandbox abruptly, and check whether the last-written file is still there after remounting. A graceful shutdown tests the cleanup path.

How concurrent mounts behave when multiple sessions share one disk

Once writes survive a restart, the next question is what happens when sessions overlap. Multiple agents can generally read the same files without coordinating with one another. Concurrent writers are a different proposition entirely. Two agents updating the same file can corrupt it or overwrite each other’s work, depending on the filesystem implementation. Strong consistency for individual objects does not automatically serialize a shared editing workflow.

Advisory locks such as flock provide mutual exclusion among cooperating processes where the filesystem supports the relevant shared namespace. They are not a universal cross-machine referee. Separate mounts need a clear locking contract, and a writer that uses the object-storage API directly can bypass filesystem locks. Amazon S3 Files has the same boundary between locks in the filesystem and access through the S3 API. Windmill instead acquires an exclusive volume lease before execution, making another job wait and trading parallel access for serialized execution.

The practical choice is between separate write paths and coordination over shared paths. Giving each agent its own subdirectory avoids competing writes while allowing readers to inspect every agent’s output. The Git Context Controller pattern illustrates this with main.md for global context, per-branch subfolders under branches/, and commit.md for milestones. Writes to shared paths instead need serialized access or a clear merge strategy, such as known last-write-wins semantics or append-only logs.

Why isolation still has to hold even when sessions share a disk

A shared disk is a data channel that leaves each session’s kernel-access boundary intact. Standard containers share the host kernel, and runc flaws disclosed in 2024 and 2025 allowed escapes to the host. MicroVM-based isolation gives workloads their own kernels, closing that shared-host-kernel escape path without promising perfect security. gVisor instead interposes on system calls to reduce the kernel attack surface. Google uses gVisor in the first-generation execution environment of Cloud Run and in App Engine, while the second-generation environment of Cloud Run uses microVMs.

Mounting the volume inside a microVM leaves the hypervisor boundary between the agent’s code and the host. That boundary does not make shared files confidential. If one session writes a credential to an accessible file, another session can read it without escaping anything. This is an authorized file read with an unauthorized consequence. Compute isolation and file-access policy protect different things, so neither can substitute for the other.

Credentials should be kept off the volume entirely and injected at the network boundary through proxy-based secrets injection. Egress should default to off or an allowlist, limiting where an agent can send data it reads. Windmill supports restricting outbound network access per sandbox. In multi-tenant deployments, credential resolution must also use the tenant’s context at call time.

Forking and checkpointing the shared disk for parallel agent attempts without full copies

Parallel attempts cost more if each one starts by copying a whole volume that holds gigabytes of intermediate work. Copy-on-write branching changes that cost structure by giving each attempt a private, writable view while storing only its diverging writes. The starting state is still shared beneath those views. This makes it practical to compare different instructions, make a checkpoint before risky changes, or give parallel regression tests their own branches of a dataset. Rollback becomes part of the workflow.

The DeltaBox paper from Shanghai Jiao Tong University, submitted in May 2026 as arXiv:2605.22781, applies a related delta-based principle at the sandbox level. It argues that successive agent checkpoints are highly similar and that storing only their differences avoids full duplication. The paper reports checkpoint and rollback latencies of 14ms and 5ms respectively in evaluations on a software engineering benchmark and RL micro-benchmarks. Those results need a clearly stated caveat. The abstract does not quantify delta sizes or memory churn on those workloads, so it does not establish how broadly the similarity assumption holds.

For shared-disk workflows, private branches also move concurrent-write conflicts to a more deliberate point. Agents work independently, then merge verified outputs into the main path with a human or orchestrator involved when needed. The merge still needs rules and review. The Git Context Controller’s folder structure approximates this organization without copy-on-write semantics, so its branch names do not create true isolation between writers. A directory called a branch is not automatically a private disk.

Mounting large object-storage buckets as the persistent volume, without copying data

Existing datasets often already live in object storage, and downloading them into every new sandbox undermines the point of persistence. Mounting the bucket through a filesystem layer lets agents use the operations they know, such as ls, cat, grep, and editor writes, without first copying all the data. The bucket remains the source of truth. The mount changes how the agent accesses data while leaving the rest of the stack’s storage location unchanged. Revoking that access layer leaves a customer’s data in the customer’s account.

For S3, a filesystem interface makes bucket data accessible through file paths, with the same warning that direct API writes bypass filesystem locks. For GCS, Google’s Agent Compute Engine, announced in October 2026, integrates shared-volume access through high-speed FUSE and manages credentials outside the sandbox on the host. For R2 and generic S3-compatible endpoints, FUSE-based mounting is the main way to do this described here. These are variations on the same access pattern. Their mount implementations still need separate answers about durability and coordination rather than inheriting those answers from a familiar bucket name.

The storage-agnostic principle extends to S3, GCS, R2, and Azure Blob, with no migration or ETL pipeline required merely to expose files to an agent. Archil offers managed storage or a customer-connected bucket, making it one option for separating the workspace interface from ownership of the underlying data. The agent’s code should not need a storage-provider rewrite. This is especially useful for source trees, notes, and configuration files, where ordinary filesystem tools already do the job. A mounted bucket is an access layer over object storage.

How do you give each customer an isolated storage workspace in a multi-tenant agent platform?

Each customer’s sessions can share a persistent workspace, but different customers need storage boundaries that agent code cannot cross. A separate disk, or a separate bucket with its own credentials, puts that boundary below the application logic. A path-prefix filter alone does not do this. Prompt injection, code bugs, or race conditions can let another tenant’s files through when application checks are all that stand in the way. The useful distinction is between a workspace shared within a tenant and a volume indiscriminately shared across tenants.

The isolation spectrum goes from logical separation to namespaces to separate storage resources. Logical isolation uses shared infrastructure with scoped prefixes and has the lowest operational cost, but a missing predicate or misconfigured filter can expose cross-tenant data. Namespace isolation, such as a separate database or schema per tenant, requires a configuration error rather than merely a missing query clause for cross-tenant access. Separate disks or buckets provide the strongest boundary in this spectrum. The choice depends on data sensitivity and the consequence of exposure.

Fast forking can make separate tenant disks practical even when the platform serves thousands of tenants. A new workspace can branch from a base template at copy-on-write cost. That economy does not replace access control. Tenant credentials still need storage and network scopes tied to the correct tenant, resolution at call time, and exclusion from both shared files and prompts. Storage billing should follow active data per tenant because flat allocations waste capacity for small workspaces or constrain large ones.

A single persistent volume across sessions is the architecture for accumulating an agent’s work. Multi-tenancy gives that architecture a stricter boundary and a larger workload. Durability, safe concurrent access, compute and storage isolation, and fast forking must then hold together across every customer workspace. Otherwise, the system has scaled the number of sessions without scaling the guarantees that make their work worth keeping.