Builder procedure
Use this track when you need OS- or cloud-level filesystem primitives under an agent stack. It complements Build an Agent Filesystem (application virtual FS) and For Agents (workspace procedures).
Read order
- This hub — choose the right layer
- Linux VFS & FUSE — in-process/user mounts
- Cloud filesystems — EFS and managed shared FS
- Mountable storage — bind mounts, NFS, object-via-FS bridges
Which layer do you need?
| Need | Prefer | Track |
|---|---|---|
| Path API inside one agent process | Virtual FS + tools | Build |
| Same files across many sandboxes/hosts | Shared network/cloud FS | This track |
| Custom FS behavior without kernel modules | FUSE / user FS | Linux FUSE |
| Enterprise governance on “files” | DMS/object behind composite FS | Composite + cloud |
Agent workload reminders
From industry analyses (Amplify): agents often want many small files, frequent updates, hierarchical navigation, and low-latency loops. Classic big-data FS and cold object stores may be a poor primary interface even if they are excellent durable backends.
Manual index
| Doc | Focus |
|---|---|
| Linux VFS & FUSE | Kernel VFS concepts, FUSE for custom agent mounts |
| Cloud filesystems | EFS-like shared FS, tradeoffs vs object storage |
| Mountable storage | How to mount and expose storage to sandboxes |
Human notes
Infrastructure choices calcify. Start with local/sandbox disk for a single agent; introduce shared mounts only when multi-host concurrency or durable shared artifacts require them. Always keep FILESYSTEM.md’s logical layout stable above the mount.