Analysis
AI Agents Made NFS Interesting Again
Google describes Filestore agent volumes as persistent POSIX workspaces that attach and detach in milliseconds. That latency is a vendor claim, not a measurement from my own deployment. The storage is familiar—shared files, directories, permissions, and locks—but the lifecycle is built for sandboxes that appear, sleep, move, and resume.
That matters because an agent’s useful state often exceeds a chat transcript. It may include a repository checkout, generated artifacts, indexes, caches, and tool output that should survive the compute environment.
Persistence and isolation pull in opposite directions
A shared filesystem is convenient precisely because many processes can see it. An agent workspace often needs the opposite default: one task, one identity, one mount. Isolation must be enforced by the provisioning and export path, not by asking an agent to remain in its assigned directory.
Volume identifiers should be opaque, mounts should be created from current authorization, and a resumed sandbox should not inherit credentials merely because it inherited files. Snapshots and backups also become part of the data boundary.
POSIX semantics are useful for multi-agent work
Read-write-many access and file locking can support several agents working against one tree. They do not solve coordination. Two processes can make individually valid edits that produce a broken repository, and a lock around one file does not protect a cross-file invariant.
I would keep source control as the merge boundary, give each worker its own worktree or branch, and use shared storage for deliberate exchange points. The filesystem supplies primitives; the workflow still needs ownership.
Lifecycle is where the cost model lives
Google says customers pay for consumed capacity and can tier inactive data through lifecycle management. Lower-cost tiering and deletion solve different problems. Moving inactive data to a cheaper tier does not erase it or establish an appropriate retention period. Agent platforms generate abandoned checkouts, package caches, logs, and failed-run artifacts quickly.
Every workspace should have an owner, creation reason, last activation, retention class, and deletion policy. A user-visible recovery window is better than indefinite accumulation. Capacity alerts should distinguish active work from cold retained state.
Google’s September 15 announcement, rechecked October 10, describes non-production availability for all Google Cloud customers and production GA via allowlist. That availability statement does not specify the recovery and retention policy for an individual deployment.
A small acceptance test before storing real work
I would use two dummy identities and disposable workspaces. Write a unique marker under each identity, verify each can read its own file, and verify that knowing the other volume’s identifier does not grant access. Test through the actual provisioning and mount path, not just an application’s directory selector.
Next, revoke one identity while its workspace is suspended. Try both an existing mount and a fresh attachment after resume. Record which access stops immediately and which requires session or mount invalidation. A policy update and an already-open file handle are not necessarily the same enforcement point.
For retention, create a versioned marker, take any configured recovery copy, then delete the workspace through the supported lifecycle. Check whether it can still be attached and whether an authorized recovery process can restore the marker. Record the retention deadline separately for the active volume and each recovery copy. This is a proposed procedure, not a claim that I ran these tests or found a Filestore isolation defect.