Everyone is building a filesystem for their agent.

Look closely at the agent systems shipping in 2026 and the same pattern shows up in all of them. Whatever the model, whatever the framework, the retrieval layer keeps converging on one shape: a filesystem. Not a vector index the agent queries once, but a set of files it can list, open, and search on its own, as many times as the problem takes. Different teams arrived there independently, from different starting points, mostly without coordinating. When that many people rebuild the same thing without talking to each other, the thing is usually load-bearing.

The pattern

Consider three examples from three very different teams.

Anthropic's Claude Code drops a CLAUDE.md file into context up front, then hands the model glob and grepto navigate everything else on demand. Anthropic's own writing on context engineering calls this “just-in-time” retrieval: keep lightweight identifiers like file paths around, and pull the underlying content into context only when it's needed. The filesystem is the index.

Turso built AgentFS, a SQLite-backed filesystem that gives every agent its own copy-on-write sandbox to read and write.

And Mintlify built a virtual filesystem to sit in front of the vector database powering their documentation assistant. Their name for it is ChromaFs.

Three storage backends. Three companies. One interface: ls, find, cat, grep. There's even an arXiv paper now, Everything is Context, arguing the filesystem is the right abstraction for agent memory. The idea isn't fringe anymore.

What Mintlify found

Mintlify's write-up is worth reading in full, because they measured the switch. Their assistant had been a standard RAG pipeline: embed the docs, return the top-k chunks near each query. It struggled the way top-k retrieval always struggles, on answers that span several pages or hinge on exact syntax that never makes the top of the ranking. Their fix wasn't to tune the embeddings. It was to change the interface. They wrapped their existing Chroma index in a virtual filesystem that translates ordinary UNIX commands into queries, and let the agent explore.

Their reported numbers, from their engineering post: session creation dropped from about 46 seconds to roughly 100 milliseconds, the marginal compute cost of a conversation went from just over a cent to nothing, and they retired more than $70,000 a year of sandbox infrastructure, across 30,000-plus conversations a day. Their framing is the line that stuck with us: agents are converging on filesystems as their primary interface.

We have no affiliation with Mintlify, and they don't use Grepticon. We point at their post because it's one of the clearest public accounts of a team reaching for a filesystem and being glad they did.

Why the filesystem keeps winning

The primitive reappears because it matches how models already reason. Every model in production has read enough shell sessions to know what ls, find, cat, and grepdo. You don't teach the interface; it's pretrained. From there, three properties fall out that a single vector lookup can't offer.

Exploration beats a single shot. A top-k lookup sees a fixed handful of chunks and stops. An agent with a filesystem can list a directory, grep for an identifier, read the two files that matched, and follow a reference into a third. Retrieval becomes a loop the model drives, not a hyperparameter you tune in advance.

Exact beats approximate. Embeddings are built to blur, which is exactly wrong when the answer is one precise string among hundreds of near-identical ones. grep matches bytes. When you need the record with this ID and not the twelve that look like it, that difference is the whole answer.

Navigation is deterministic.Paths mean the same thing every time. There's no chunk boundary to fall across, no stale embedding to rebuild when the source changes, no top-k cutoff quietly dropping the one file that mattered.

None of this means embeddings are dead. Mintlify kept theirs, behind the filesystem. Similarity search still earns its place when you're fuzzily retrieving over millions of records. The shift is narrower and more durable than “RAG is over”: the agent's interface to your data is becoming a filesystem, whatever sits behind it.

The part everyone rebuilds

Here's the catch in every one of these stories. Each team had to build the filesystem itself, and the interface is the easy part. The plumbing under it is not.

You need sessions that start in milliseconds, not the tens of seconds a real sandbox takes to boot. You need per-user access control, so one tenant's agent can never list or read another's files, enforced before a path is ever returned. You need grepto stay fast as the corpus grows, which means a coarse filter to find candidate files and a fast path for the regex pass. You need a way to get documents in and keep them in sync as they change. Mintlify's post is, in large part, a tour of solving exactly these problems: directory trees bootstrapped from storage, paths pruned by session token, grep split into a coarse and a fine stage.

That's weeks of infrastructure work that has nothing to do with your actual agent, rebuilt from scratch every time the pattern shows up.

The primitive, hosted

Grepticon is that primitive, as a service, so you don't build it again. Point it at your documents and your agent gets an isolated, read-only workspace with the four commands already wired: ls, find, cat, grep, over HTTP, through a typed SDK, a REST API, or MCP. Sessions start cold in milliseconds. Every workspace is permissioned and isolated by default. There's no sandbox to boot, no embedding pipeline to maintain, no vector store to keep in sync.

We took the all-the-way-to-real-files version of the idea, and then we measured it. On an adversarial 18,340-file corpus, an agent with grep over a Grepticon workspace answered 97.9% of held-out questions correctly, 16.7 points ahead of a naive top-k baseline, with the gap concentrated in exactly the counting, exact-match, and multi-hop questions embeddings are worst at.

The pattern isn't going to stop reappearing. The only real question is whether you build the filesystem again yourself, or reach for one that already exists. Signup is free, and the quickstart hands your agent the four commands in about the time it took to read this.

Common questions

Do AI agents need a vector database?

Not necessarily. For many agent workloads the more effective interface is a filesystem the agent explores with ls, find, cat, and grep, retrieving just in time. Vector search still helps for fuzzy retrieval over very large record sets, and the two can coexist, as Mintlify's ChromaFs shows.

What is a virtual filesystem for AI agents?

A filesystem interface, the ordinary ls/find/cat/grep commands, backed by your documents or a datastore rather than a physical disk, so an agent can navigate and search your data with commands it already understands.

Is RAG dead?

No. The durable shift is in the agent's interfaceto your data, which is becoming a filesystem. Embeddings often still sit behind that interface. What's fading is single-shot top-k as the only retrieval an agent gets.