Agentic File Systems
File systems are becoming the default interface agents use to store context, navigate work, and produce outputs.
A file system organizes information into files and folders, the same pattern on every desktop. Every general purpose operating system, Windows, macOS, Linux, works this way, and models trained on code written for these systems can already traverse it well.
An agent-native file system is a database that behaves like that ordinary file system to the agent. The agent runs the same open, read, and write operations it already knows. Underneath, the system adds version history, an append-only log of agent actions, and control over which files an agent can touch. This differs from a memory layer such as Mem0 or Letta, which helps an agent recall past interactions and preferences. An agentic file system instead lets the agent produce, version, and govern its own inputs and outputs.
Value will accrue to file systems built for specific kinds of work. The underlying storage stays a commodity, the way basic cloud storage became a standard hyperscaler feature. A standalone file system startup cannot win on storage alone. AWS S3 dominates on scale, and Wasabi leads on hot storage with pricing that is hard to undercut.
Three problems only an agent-native file system solves
Traditional file systems were built for humans clicking through folders. Autonomous agents need three things a folder on a laptop was never built to give them.
Context management
Models hold limited memory, and reading a hundred files to finish a task strains what an agent can usefully produce. A file system lets an agent organize information and pull only the files it needs. Today most agents either re-read everything at each step or lean on the harness to manage retrieval, spending capacity on remembering instead of reasoning.
An auditable action record
Autonomous agents make consequential mistakes more often than a human would. A dedicated agent file system logs every operation and tool call in an append-only record, so humans can review what happened and trace a failure back to its source.
Recoverable mistakes
Agents will make errors. A file system gives users point-in-time snapshots and branches off historic versions. A human in the loop can rewind state to before an unwanted change and branch from that version, so people or sub-agents can work alongside the agent that made the mistake.
Cloud execution platforms such as E2B, Daytona, Modal, and Runloop, and coding tools such as Claude Code, Cursor, and Codex, address memory through combinations of sandbox persistence, volumes, and snapshots (definitions in the appendix below). Claude Code and Cursor preserve files through git history, but working memory resets between sessions.
A common workaround has agents maintain note files: an architecture summary, a running list of gotchas, a plan. Because agents write these as self-generated summaries, the notes drift stale as a project moves forward, and nothing links a piece of reasoning to the file version it explains.
Git records what changed. It does not always record why.
From the thesisWhy this breaks now, not five years ago
Agents handle files well because the code they trained on is dense with file operations. That fluency used to be enough. A single agent working alone needs little from a shared, live file system.
Fluency and workload
- Leading models learn from code full of file operations, so agents handle files and folders predictably.
- Agents retrieve and synthesize information without knowing upfront how it should be organized. A file system lets them write freely. A database needs its structure defined in advance.
Interface and platform support
- Reaching a file takes only its path. Reaching a database takes addresses, passwords, and logins, which costs an agent tokens and time.
- OpenAI's Agents SDK now supports mounting a remote file system natively. When a distribution platform builds that connection point in, adoption of whatever plugs into it speeds up.
The multi-agent collision
A single agent has little need for a shared, live file system. The shift to orchestrator and sub-agent architectures changes that. When several agents write to the same state at once, they collide, producing conflicts, lost work, and results nobody can reproduce. The fix moves the file system off a single constrained machine and onto a shared layer where every agent, and every person, writes to the same state.
How to read this. Each agent writes to the same underlying state. Left alone, simultaneous writes collide. A shared file system layer reconciles them into one consistent version instead.
Where the stack creates defensibility
This is not a filesystem versus database question. The agent sees one directory and calls ls, read, and write. The backend routes to cloud or database stores underneath, and can swap from S3 to something else without touching the agent's reasoning trace.
A database gives real advantages a filesystem typically lacks. It preserves old versions instead of overwriting them, avoids permanent loss through soft deletion, and lets multiple agents work at once without interfering with each other. Recreating those capabilities on top of a filesystem adds complexity that a database already solves.
The two can coexist. Agents write schema-free, in whatever structure suits the task, while a database-backed system underneath runs structured queries across the full history of files, state, and tool calls. File-level permissions then limit each agent to only the files it should touch.
Turso AgentFS is one example. It keeps everything in a single compact database file and exposes three things an agent needs: the files themselves, a running log for rollback and visibility, and a scratchpad for ongoing work. That single-file design is portable, though it does not hold up at scale on its own, which Turso is addressing by spreading storage across the cloud.
A file system this low in the agent stack holds durability once enterprises adopt it.
From the thesisWho is building this
Toggle between how companies group by layer and how the opportunity splits by vertical. Hover or tap a card for detail.
SQLite engine made to look like a file system interface. Keeps old versions instead of overwriting them, ships as a portable file, and tracks the files, a running log of changes, and the agent's scratch notes.
Founders Glauber Costa and Pekka Enberg met at ScyllaDB, a MongoDB competitor, and now run a team of fifteen. Currently working to make the system scale to real company workloads.
A file system that remembers every version of any kind of file, built for company document work that needs sign-offs and a clear record of who did what.
Workflow-layer thesis aligned. The approvals and human sign-off layer line up with Lightspeed's research on this category. Founders Oliver Gilan and Ben Warren met at Microsoft, a team of five with no funding yet.
Established public company offering the same folder-style access, wrapped in the security and compliance controls large companies already trust.
Owns enterprise content and governance distribution. Hard to displace in the general case. Competes against startups on regulated verticals.
Turns cloud storage a company already owns, such as Amazon S3, into a fast local folder agents can read and write without moving the data first.
Removes the data-staging step and gives agents memory across runs, real infrastructure value, though it sits close to the raw storage that commoditizes. Founder Hunter Leath went through YC, with past experience in cloud storage systems at Netflix.
Open-source unified virtual filesystem that mounts S3, Google Drive, Slack, GitHub, Redis, and a dozen other backends as one folder tree. Agents interact with all of them through standard Unix bash tools.
Strong on developer ergonomics. First public release in May 2026 drew 3,100 GitHub stars. Governance is light: no audit logs, no append-only event log, no formal permissioning, which limits fit for regulated verticals.
Temporary execution environments that spin up per run. They run the work, then forget everything when they shut down.
Some persistence layers have been built to fill this gap, with each company taking a slightly different approach.
Tools that store and recall facts so an agent can look things up later.
The alternate leading approach to capturing an agent's reasoning. Whether that reasoning should live here or inside the versioned file system stays an open question.
Four reasons this market splits
Assessed against four pillars of a winner-take-all market, this space does not favor one winner.2
Network effects are weak. One user's usage does not benefit another. Heavy use makes the product better for that one customer, which locks the customer in rather than pulling new customers toward it.
Switching costs cut both ways. Box, Mesa, and LangChain's Deep Agents pattern argue that an agent depends only on filesystem semantics, so the backend swaps without a costly rewrite. That portability makes the vendor a two-way choice and weakens lock-in. Reasoning and memory that accumulate per use run the other way, and compound into stickiness.
Different verticals value different features. Coding, research, analytics, and document-heavy regulated work each weigh version tracking, oversight, and file types differently. That splits the market into several specialized winners while incumbents keep the generic, one-size-fits-all business.
Agent ergonomics argue against fragmentation. In developer tools, small interface differences compound into large gaps in overall experience. The same will hold for agent-facing systems, where how a file system exposes information, errors, and history will shape adoption speed.
Where the standalone opportunity sits
The standalone opportunity is narrow. It lives in regulated verticals with real governance requirements and no vertical AI workflow owner today.
There is no single lead vertical. Coding, regulated document work in legal, health, and finance, research and analytics, and robotics and field operations each reward a different filesystem profile. Coding is especially crowded, with labs and harness vendors already competing there directly.
The strongest vertical products commit to legitimate governance requirements, accumulate per-user context that compounds, couple agent reasoning to the outputs in the same versioned read path, and stay backend-agnostic.
In verticals with real regulation, a file system can stand alone as a company because it becomes the system of record other systems integrate with. Vertical platforms will keep adopting file systems as part of their own offering too. Harvey, for example, could build a file system for its law firm clients with the features listed above. A general-purpose file system commoditizes, leaving hyperscalers and Box with structural advantages.
The case against this thesis
A lab shipping a general-purpose agentic filesystem with native governance and reasoning capture would be strong enough that vertical specialization stops mattering. Even so, labs have tried to enter adjacent markets before and have not won them, and specialized players have kept real share.
A more negative development would be a memory layer absorbing reasoning capture. That would weaken the structural case for a separate file system.
The bull case for a general-purpose competitor is gaining share across industries fast, then building derivative products that entrench value inside the enterprise. A file system this low in the agent stack holds durability once an enterprise adopts it. The open question is how fast a startup can gain share before that happens.
What if we're wrong?
- What will a company deploying agents actually pay for an agentic native file system?
- Which underlying design wins for which kind of work, and at what company size? Lightweight, single-file designs may fit early-stage and smaller use, while large enterprises need storage spread across the cloud.
- Does reasoning capture belong inside the file system, or inside a separate memory tool?
- Is there room for one company to move fast and offer a wide set of features that work across every vertical?
Reference material
Sandbox persistence. Sandboxes are isolated environments where code runs. By default they wipe clean on shutdown. Sandbox persistence means the state survives between runs, so an agent picks up where it left off.
Volumes. Storage attached to a running environment that survives restarts and can move between environments, like an external hard drive that different machines can plug into without losing data.
Snapshots. A read-only copy of an environment's full state at a point in time. If something breaks, the system reverts to the snapshot.
Stateful operations. Operations where the result depends on prior context. A stateful agent knows what it has already read, decided, and written within a session.
Every file is a node. Every relationship between files is a typed edge. Every agent action is an entry in an append-only event log with the reasoning attached.
Nodes represent files and folders. Edges capture relationships such as CONTAINS, DERIVED_FROM, and REFERENCES.
Each event log entry records what operation ran and on which file version, why the agent made that choice, what alternatives it rejected, and what prior event triggered it.
Footnotes
- entire.io is an open source project from former GitHub CEO Thomas Dohmke, backed by a $60M seed. Any developer can install it to capture agent session history, track concurrent agents, and keep full version history native to git, with shared agent memory on its roadmap.
- The four pillars, network effects, switching costs, vertical variation, and interface ergonomics, are the lens this thesis uses to test whether a market tends toward one winner.