Shareable Cloud Volumes Built on Object Storage

Cloud volumes built on object storage can be shared, so agents can use buckets they already have as file systems without moving the data. Some file-system layers mount existing S3, GCS, R2, and Azure Blob buckets in place, so file-based tools can work against data where it lives. The real test is not whether a bucket looks like a local folder, but whether it behaves like one through restarts, concurrent writes, and isolated branches.

Why object storage alone cannot serve as an agent's file system

Object storage offers a durable, horizontally scalable, bucket-addressed model built around coarse operations, namely writing an object and reading it back. A file system promises something different. Tools expect operations including atomic rename, mmap, fsync, hard links, symlinks, and sparse files, which have no direct equivalent in the object model. A bridge that refuses those operations or hides substitutes in bucket metadata has not resolved the mismatch. It has moved the argument to runtime, where the debugging bill arrives.

That matters because agents overwhelmingly work through bash and file tools, the interfaces models are trained to use. Without a bridge that works, platform teams have to move state back and forth between sandboxes and centralized storage. Google Cloud's Filestore agent volumes announcement describes that burden as concurrent sessions grow into the thousands or millions. The incompatibility is architectural, so manual copying cannot be the lasting fix.

What a real translation layer must deliver: the five primitives

Five primitives follow from that gap, which are persistence, concurrent mounts, sub-second attachment, S3-compatible read-back, and branching. With persistence, the packages that were installed, the files that were written, and the working directory are still there after stops and restarts. Concurrent mounts let several agents use the same workspace. With sub-second attachment, the workspace is ready without a wait for storage at every launch.

The remaining primitives connect that workspace to production and the wider stack. S3-compatible read-back lets existing object tools read the same data agents reach through files, without duplication or migration. Branching gives an agent an isolated, writable view of production data, with room to try alternatives and roll back. Underneath all five, the translation must preserve the operations that tools actually call. That means real atomic rename, fsync, and hard links, not emulations that break under load.

Why persistence is the hardest primitive to get right

A volume must be reconstructable on any machine without manual intervention. A sandbox that pauses and resumes on the same node may keep a local disk, but an agent platform that resumes work on arbitrary nodes cannot depend on that arrangement. Its file system state must be disaggregated from compute. In practical terms, the file system database belongs outside the worker process.

A FUSE daemon inside a sandbox holds a live kernel-to-user-space connection and a live network session to the object store. When a platform snapshots the VM and resumes it on another node, those connections do not serialize or restore cleanly, leaving the mount dead. The files may still be there, but the tool cannot reach them when it resumes. Keeping the database outside the worker, as in a durable shared cloud file system, removes that dependency on the suspended process.

Durability also has a precise moment of truth, which is when the file system reports success. A volume that acknowledges fsync before committing to the backing object store can lose data before the next attach. Separating durable data from a pre-allocated disk also changes the economics, since stored data need not carry the cost of fixed capacity headroom. Filestore agent volumes addresses the waste of fixed-size volumes for short-lived sessions through automatic lifecycle tiering.

Concurrent access and POSIX locking: what multi-agent collaboration actually requires

Read-Write-Many, or RWX, allows several agents to mount a volume, but access alone does not coordinate their writes. Two agents writing to the same path can silently corrupt each other's output without file-level coordination. The file system still needs consistency at the operation level.

Filestore agent volumes pairs native Read-Write-Many support with POSIX file locking for concurrent co-authoring. The important qualification is where those locks work. Advisory locks can coordinate cooperating processes on one machine, but that alone does not establish safe coordination between writers on different nodes. Cross-machine work needs explicit ownership or a coordination layer. With that distinction handled, one agent can write a patch, another can run tests, and a third can review output on the same file tree without a separate data-passing pipeline.

Branching and checkpointing: how agents work on production data without risking it

Agents need real data to be useful, but direct production writes leave one bad operation between a useful run and an incident. Staging copies grow stale, while manual snapshots do not fit agents running continuously. A branch resolves that tension by giving an agent an isolated, writable view that can be promoted or discarded.

Object versioning is not the same capability. S3 uses bucket-level configuration to keep versions of individual objects, but it cannot give an agent an isolated, writable copy of a bucket. R2, GCS, and Azure Blob likewise lack a native fork or branch primitive. The distinction is the scope of the guarantee. Recovering an object is useful, but it does not give an agent a separate workspace in which all its changes can remain isolated.

A write-ahead log, or WAL, links checkpointing to branching by keeping a record of every mutation. That history allows prior states to be reconstructed and branches to start from checkpoints, so a bad run can be rolled back. If the whole workspace has to be copied first, every experiment has to wait on I/O. Copy-on-write checkpoints that take milliseconds make branching part of normal agent execution instead. A fork needs to be fast enough for everyday use, no matter how large the disk is.

How can an existing S3 bucket stay readable through both files and the S3 API?

A POSIX-only volume solves the agent's interface problem by handing a new one to the rest of the stack. Existing tools including boto3, AWS CLI, rclone, Terraform, LangChain, and Spark already use the object interface. Requiring them to change storage models turns a mount decision into a migration project. With S3-compatible read-back, an agent can instead write through the file system, and a downstream job can read the same data through boto3. Those operations should work without a sync step or a second copy.

Amazon S3 Files brings both interfaces to S3. AWS describes it as built using Amazon EFS, with file system access while S3 remains the system of record and both interfaces remain available. Multi-cloud file-system layers apply the same approach to GCS, R2, and Azure Blob buckets. The strongest in-place mounting guarantee leaves the bucket as the source of truth, so revoking the mount leaves the data where it was.

How isolation interacts with storage: why the sandbox boundary and the volume boundary must match

A volume can apply workspace permissions as it should even when the environment in which code runs is unsafe. Agents in shared-kernel containers on the same host have paths through which they can escape the kernel. They fit trusted, reviewed code. A kernel for each tenant in microVMs gives a stronger boundary when each tenant also has its own storage. Firecracker runs microVMs, while Kata Containers supplies an orchestration layer over Firecracker, Cloud Hypervisor, or QEMU.

Compute isolation and storage permissions must define boundaries for the same tenant. Filestore agent volumes uses granular per-workspace permissions to keep agents within designated directories and separate toolchains across tenants. Application filters cannot substitute for that enforcement. Likewise, gVisor's user-space syscall interception offers stronger separation than shared-kernel containers, but incomplete coverage and Linux tool compatibility remain part of the tradeoff.

The boundary also has to control what leaves the workspace. An agent with arbitrary outbound HTTP access can exfiltrate data even when its volume permissions are correct. The safe default is deny-by-default outbound access with an explicit allowlist per tenant. Credentials belong at the network boundary for the same reason. A secret never placed on the sandbox's file system cannot be retrieved by an agent reading its disk.

Per-tenant storage at scale: provisioning, scoping, and economics for thousands of agent workspaces

At thousands of concurrent sessions, a sound boundary must also be cheap and practical to operate. Engineers should not have to create, attach, and tear down a volume for each run. Filestore agent volumes automates allocation and attachment at launch, then tiering and detachment when work becomes idle. With that lifecycle, a short-lived session does not have to keep its peak storage capacity set aside forever.

Compute and storage meters still need to be distinguished. Serverless execution against a shared disk, where compute is billed only while code runs, shows how durable workspaces can work with elastic execution, but it does not make storing data free while an agent sleeps. Together with Filestore's lifecycle model, it illustrates how workspace persistence can be separated from the life of an individual sandbox. The goal is to keep state durable without keeping compute or fixed disk headroom set aside all the time.

Credential scoping must scale with the same tenant model. A shared key pool lets one misdirected tool call reach another tenant's data. The safer pattern is a vault that looks up credentials by (tenant_id, tool_name) and issues short-lived, scoped tokens. Storage access controls must enforce the boundary because prompt injection or race conditions can get past application filters. Provisioning, permissions, and billing therefore belong in the same design discussion.

Evaluating a shareable cloud volume: the questions to ask before committing

Vague isolation and persistence claims are common, but only specific, checkable claims help a buyer. Start with whether a volume survives attachment on a different node. Ask where fsync durability terminates, at the file system layer or the backing object store. For concurrent mounts, ask whether RWX coordinates writes across nodes or has only advisory locking on one machine. For attachment speed, distinguish a documented, benchmarked sub-second guarantee from a best-case result on pre-warmed infrastructure.

Next, ask whether a fork makes an isolated, writable volume without having to copy the data. An answer about versioning must specify whether it protects individual objects or the entire namespace. For S3 compatibility, establish whether both interfaces expose the same data simultaneously and whether an existing bucket mounts in place.

Finally, ask the provider to name its hypervisor, default egress policy, and the place where secrets live. A secure sandbox label is less useful than a concrete account of Firecracker, deny-by-default egress, and network-boundary credential brokering. Ask how long the underlying infrastructure has carried production load. Infrastructure that serves millions of agents per week has a different record of running real work from a product that has just launched. The right evaluation is exactly what the preceding requirements demand, namely proof that file semantics, durable state, shared access, and tenant boundaries survive real agent lifecycles.