Why Every Agent Company Eventually Builds a Filesystem

From Cursor's repo cache to Devin's snapshot model, the filesystem keeps showing up where the architecture diagram said it shouldn't.

In the last 18 months, every serious agent company has shipped some version of a session-state or workspace-management layer. They were not planning to. They were building compute orchestration, model routing, IDE integrations, and developer surfaces. The filesystem appeared as a side effect of every team eventually realizing that "where does the agent's work live" is the load-bearing question underneath everything else.

Read the engineering blogs from any well-known agent platform and the same artifact shows up. A paragraph, often buried in a postmortem or a launch note, describing how the team built a custom layer to handle workspace state. Different vocabularies, same primitive. The pattern is consistent enough that it is worth asking why it keeps happening, what the implicit shared design is converging on, and whether anyone is going to ship it as a standalone product. That last question matters because the alternative, which is the current default, is that every agent company runs the same engineering project in parallel. It is the kind of duplicated effort that infrastructure layers exist to absorb.

The Side-Project Filesystem

A non-exhaustive tour. Cursor maintains an aggressive local repository cache to reduce the cost of context switches across multi-repo agent runs. Cognition's Devin product has shipped iterative improvements to its session and snapshot model, with recent versions emphasizing faster fork operations and better state portability across machines. Factory.ai's droids hold their work in scoped workspaces that persist across model invocations. The OpenHands project (formerly OpenDevin) introduced a workspace abstraction early as a way to manage agent filesystem state separately from compute substrate. Replit's broader agent offering has always been tightly coupled to its filesystem fork, originally built for human developers. Augment Code's context store, framed primarily as a code-understanding system, leans heavily on caching and dedup primitives that look like a filesystem layer in everything but name.

Each of these implementations re-invents roughly the same set of capabilities. Fast forking from a known base. Some form of deduplication to keep storage costs down. State that can be paused, resumed, and inspected. A surface that an agent can drive programmatically and a human can occasionally peek at.

None of these companies sells the filesystem as a product. None of them, as far as public statements go, set out to build one. They built one because the alternative was untenable. Once an agent platform has more than a handful of concurrent sessions, the cost of cloning, the cost of dependency reinstallation, and the operational burden of state drift across runs becomes the dominant pain point. Compute is cheap. State management is the hard part.

Why It Keeps Happening

The pattern is not coincidence. Four characteristics describe what an agent platform actually needs from its substrate, and none of them map well to generic compute primitives.

First, fast forking. An agent run is not analogous to a developer session, where one workspace lasts hours or days. Agent runs are short, often parallel, and benefit enormously from being able to spawn from a known good state in milliseconds. Container images are too coarse. Git clones are too slow. What works is copy-on-write at the filesystem level.

Second, deduplication. When 200 concurrent agents work off the same base, materializing 200 copies is unacceptable. Deduplication at the file level helps. Deduplication at the block or content-addressable level helps more. The math gets brutal at scale, and most teams who hit it discover it the hard way.

Third, deterministic state. An agent that runs the same task twice should be able to start from the same state both times, including dependencies, caches, and prior side effects. This is straightforward in theory and hard to guarantee in practice without a substrate designed for it.

Fourth, portability. Agents do not live alone. They hand work to other agents, to evaluation pipelines, and occasionally to humans. The handoff is much smoother when the workspace is addressable as a reference rather than serialized into a tarball or container image.

Generic compute does not give you any of these. Containers give you parts of one and three. Cloud volumes give you parts of two. No single existing primitive gives you all four.

AetherFS as the Counter-Bet

AetherFS, a Rust-built distributed filesystem currently in private beta, is the most articulated external example of the alternative approach. The premise is straightforward: build the filesystem layer that every agent platform is currently re-inventing internally, and offer it as infrastructure those platforms can adopt instead.

The architecture maps closely to the four characteristics above. Sessions are copy-on-write overlays on a shared base, materializing in seconds rather than minutes. A content-addressable store underneath the overlay handles deduplication at the blob level, with reference counting to keep memory bounded. The system is accessible through gRPC, HTTP, WebDAV, and a FUSE mount, which means an agent backend can create a session over gRPC, a build pipeline can hit it through HTTP, and a human developer can mount the same session locally for review without environment drift.

Underneath the design is a thesis the team has discussed in technical writeups. Their argument, paraphrased, is that the filesystem has been the wrong layer of abstraction for agent infrastructure since the start. Compute companies treat it as an output. Agent platforms treat it as a side concern. Nobody has built it as the primary product. The bet is that the industry is converging on a substrate, that an open-source Rust core is the right form factor for that substrate, and that adoption will follow when the in-house alternatives become more expensive than they are worth.

Whether the bet pays off is unsettled. The pattern that motivates it is not.

The Build vs. License Decision Tree

For an agent platform deciding whether to keep building this in-house or adopt an external substrate, a few questions actually matter.

Is the workspace primitive central to your product's differentiation? If your platform is differentiated by something agents do (better planning, better tool use, better evaluations), the workspace is plumbing. Plumbing should not be a competitive moat. Adopt.

Do you have unique requirements that no general-purpose system can meet? Specific compliance, specific isolation, specific integration with proprietary build systems. These are real reasons to build, but they are rarer than teams initially believe.

Is the team you would assign to maintain this substrate the team you actually want working on agent capabilities? Workspace infrastructure is a long tail of corner cases (POSIX semantics, lock coordination, cache invalidation, FUSE quirks). It absorbs senior engineers indefinitely. License if the answer is no.

Has the alternative reached enough maturity to trust? This one cuts both ways. Early-stage infrastructure has scar risk. Mid-stage infrastructure is the inflection point. Late-stage infrastructure is usually a worse fit because it has accumulated assumptions from its biggest customers.

The honest answer for most agent platforms today is that the build option has not been a strategic choice but the default. There has not been a credible alternative.

The Twilio Comparison

A speculative analogy, flagged. Twilio's bet, articulated in early-2010s investor materials, was that every consumer application would eventually need telephony, and that every one of them was rebuilding the same primitives because no one had productized the abstraction. The bet was correct. AetherFS, and any future entrants in this category, are making the same bet about agent state. Every agent platform will need a filesystem. Most of them are currently building it in-house. The question is whether enough of them eventually stop.

The historical pattern favors the externalization thesis. The execution risk is non-trivial. The next 18 months of agent infrastructure will probably tell.