What is agent-native storage?

Agent-native storage is a filesystem designed around how AI agents actually work: many parallel workers forking from shared state, writing with ordinary file tools, and publishing results that need attribution and history. In practice it combines four things — a mountable POSIX-style filesystem, instant copy-on-write forks, content-addressed version history, and conflict-safe publishing with per-commit provenance. None of the storage we inherited from the pre-agent era (object stores, network filesystems, sandbox disks) provides all four.

Why do agents need a filesystem at all?

Because every tool agents are good at using assumes one. Agents work with grep, Git, jq, editors, compilers, and package managers — decades of software built against files and directories, not object APIs. Give an agent an S3 SDK and it must translate every intention through requests; give it a mounted filesystem and its entire toolchain works unmodified. The filesystem is the agent's native interface, which is exactly why storage that merely resembles a filesystem breaks agents in subtle ways.

What's wrong with the storage agents use today?

Each existing option fails a different way:

• Object stores (S3 + adapters like s3fs) leak object semantics through the mount: no real rename, slow small-file operations, per-request billing, and last-writer-wins for concurrent writers.
• Network filesystems (EFS, NFS) share one live tree — the opposite of what parallel workers need — and metadata-heavy workloads crawl on round trips.
• Sandbox disks (E2B, Daytona, Modal) tie the data's lifetime to a compute lifecycle: state lives and dies with the sandbox unless you hand-roll sync to an external store.
• All of them lack history. When an agent overwrites or deletes the wrong thing, there is no "what did the workspace look like an hour ago, and who changed it?"

What makes storage agent-native?

Isolation first: every agent gets its own writable fork of shared state, created in milliseconds without copying, because parallel workers writing one shared tree is how work gets destroyed. On Amulet, forking a multi-terabyte workspace returns in about 3 ms and copies zero bytes — data is shared until a fork diverges.

History second: work is captured as immutable, content-addressed commits recording the complete workspace state and its provenance — which actor, session, and run produced it, from which base. Publishing a session is compare-and-swap: if another agent already advanced the workspace, the publish fails with an explicit conflict instead of silently overwriting. Any published revision can be restored exactly.

Speed third, in the dimension agents feel: mounts complete in under 100 ms regardless of workspace size because nothing is scanned or copied up front — bytes hydrate on first read and hot data serves from local NVMe cache.

How is this different from just using Git?

The semantics rhyme deliberately — commits, branches, history — but Git assumes working copies that fit on local disk and workflows where a human resolves conflicts in an editor. Agent-native storage applies those semantics at filesystem scale: terabyte workspaces that mount instead of clone, forks that are instant at any size, and conflict-safe publication designed for automated writers. Git itself runs happily inside an Amulet workspace; the workspace is the layer underneath.

Who needs agent-native storage?

Anyone running parallel work over shared data: agent platforms provisioning ephemeral sandboxes, training and eval systems creating many isolated environments from a common dataset, fan-out pipelines whose workers publish attributable outputs, and teams that simply need to answer "which run produced this file?" without log archaeology. If your workload is one process appending to one bucket, you don't need this. The moment work happens in parallel, you do.