Agents · measured July 2026
The retrieval layer is the new database. Your agent's still runs on ripgrep.
For twenty years you could not ship anything serious without a database. It was the load-bearing layer: the thing that decided what the app could show, how fast, and at what cost. Swap the framework, swap the language; the database was the floor everything stood on, and a whole industry was built on owning it. Agents have that layer too. It is not the model: the model is rented and swappable. It is retrieval: the code that decides what the model sees before it reasons.
Glean already proved that layer is worth billions for the enterprise. But on the machine where your agents actually run, it is barely built: we watched Claude Code spend 6 minutes and 57 seconds finding one file, because its database was ripgrep walking the disk. With a real index underneath it, the same lookup took 16 milliseconds.
TL;DR · the 30-second version
- 01In the web-app era, nothing serious shipped without a database. It was the load-bearing layer: it decided what the app could serve, how fast, and at what cost. A whole industry grew around owning it.
- 02In the agent era, the equivalent layer is retrieval: the code that decides what the model sees before it reasons. The model is rented and swappable; retrieval sets the quality ceiling.
- 03Glean proved the thesis pays in the cloud: it became one of the most valuable enterprise-AI companies by selling retrieval across a company's apps, without training a frontier model of its own.
- 04On the machine where agents actually run, that layer is mostly unbuilt. The local agent's "database" is still ripgrep walking the disk: we watched Claude Code spend 6m 57s to find one file.
- 05Interlinked is that database for the local agent: a whole-machine index answering in ~139 µs, always fresh, plus a self-built knowledge vault of relationships, measured on a real 4.47M-file machine, with no model in the box.
Take the analogy seriously
What the database was to the app, retrieval is to the agent.
The retrieval layer is the part of an AI agent's stack that decides what the model sees: which files, which passages, which past decisions get pulled into the context window before the model reasons about them. The model is the CPU; retrieval is what feeds it. And like the database before it, it is the layer nobody photographs and everything depends on.
Think about how the web-app stack settled out. The framework wars cooled; the language stopped mattering much; the front end became a commodity you could regenerate in an afternoon. What stayed load-bearing was the database, because it held the truth, and its speed and shape set the ceiling on everything above it. A slow query was a slow product no matter how elegant the code on top. Whole companies, and a good chunk of the last two decades of infrastructure spending, existed to make that one layer faster and more reliable.
The agent stack is settling out the same way, one level up. The models are converging and interchangeable: you will swap yours for a better one next quarter and barely notice. What stays load-bearing is the layer that finds and feeds the right context, because a brilliant model reasoning over the wrong files is still wrong. That is the argument, drawn in full, in the backbone of the LLM economy and agents need retrieval, not a bigger context window. Retrieval is the new database. The only question is who builds it.
The stack, then and now
Every era has one load-bearing layer. This is the one nobody's optimizing.
Here are both stacks, drawn honestly. On the left, the web app you already understand: the database sits at the bottom, holding the truth, and the whole product is only as fast as it is. On the right, the agent. And the layer in the same position, doing the same job, is retrieval. Same role, new era. The difference is that the database got thirty years of engineering and a dozen billion-dollar companies. Its successor, on your own machine, got ripgrep.
That is what a missing database layer costs. Without a whole-machine index the agent does directory archaeology (list a folder, read the bytes, guess, repeat) for nearly seven minutes and 71 tool calls to reach a file that was already sitting on the disk. Seven minutes is long enough to make a coffee and drink half of it; 16 milliseconds is faster than you can blink. One call instead of 71, roughly 7,200,000× less work for the same result. Not because the model got smarter. Because it finally had somewhere to look.
Same machine · same drive · same queries
The agent's database query, priced today.
Every row is the same errand a web app would hand its database in a millisecond: fetch one thing off a 4.47-million-file drive. Windows Search takes 67 seconds, long enough to refill your coffee. The indexed lookup takes 139 microseconds, and the answer is on screen before you register the wait.
| The searcher | What was measured | Time | vs Interlinked |
|---|---|---|---|
| Interlinked | one indexed lookup, 4.47M files | 85 μs | the baseline |
| VS Code Ctrl+P | find a file by name, same drive | 35 s | 412,000× |
| Windows Search | 20 filename queries, median | 67 s | ~480,000× |
| ripgrep (your agent's content search) | same query, same corpus | 93.8 s → 16 ms | 58,625× |
| Claude Code (no index) | the full file hunt, 71 tool calls | 6 m 57 s | ~7,200,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename lookups are median-of-20 (139 μs); the 85 μs figure is a single-file lookup, best case 2 μs. The ripgrep row is a content query over the same corpus: 58,625× is the average across the query set, and one query from it ran 93.8 s → 16 ms. The Claude Code row is the measured agent hunt (6 m 57 s, 71 tool calls) against a single indexed lookup; with the index the same task was one call, 16 ms, not a single-operation stopwatch ratio. Full per-tool write-ups: the 412,000× VS Code comparison and the ripgrep content benchmark.
The enterprise already bought this
Glean is worth billions for owning one layer. It never trained a model.
Glean is an enterprise "Work AI" platform, founded in 2019 by a former Google search engineer. Its product is retrieval: it indexes and searches across a company's cloud apps (the docs, the tickets, the chat) and hands the right passages to an assistant. It became one of the most valuable companies of the AI wave without shipping a frontier model of its own. Its public bet, argued consistently by its founder, is that in enterprise AI the model is the easy part and the retrieval layer is the hard, valuable one. Sell the database, not the CPU.
Now look one layer down, at the machine on your desk where your coding agents actually run. There is no Glean there. There is no Postgres-for-the-local-agent. Each tool indexes the one project you opened (VS Code the folder, Cursor the repo) and the moment a question crosses a folder boundary, or touches the 90% of the disk that was never in git, the agent falls back to walking the disk by hand. The most valuable layer in the stack, the one the enterprise pays billions for, is on your machine an afterthought. That gap is the whole thesis of every AI startup is a search company, and it is the layer Interlinked builds: Glean for the local machine, built for agents instead of people.
The other half of the database
A database has rows. It also has relationships.
The reason the database mattered was not just fast lookups: it was the joins. The foreign keys. The fact that the layer knew how the data connected. The retrieval layer for agents needs the same second half, and it is the part editor search never had. So the same index that answers in microseconds also carries a knowledge vault it builds by itself (files that change together, repos that share hundreds of identical files, which project is alive and which went dormant) plus notes any agent can leave on any file that every other agent then reads. Keyed to the file's OS identity, so it survives renames, spans every repo, and belongs to no vendor. No model, no embeddings: every edge is a count or a hash you can check.
This is not a replacement for RAG or your model's memory: it is the layer under both, the reason it is not RAG and not memory. The whole seed, timed from the service log, is in files that find each other.
THE ROWS ARE THE FILES. THE JOINS ARE THE RELATIONSHIPS. THE LOCAL AGENT NEEDS BOTH.
FAQ
Questions people actually ask.
What is the retrieval layer in an AI agent?
The retrieval layer is the part of an AI agent's stack that decides what the model sees: which files, which passages, and which past decisions get pulled into the context window before the model reasons about them. The model does the thinking; retrieval decides what it gets to think about. More on why that split matters in agents need retrieval, not a bigger context window.
Why call retrieval “the new database”?
Because it plays the same structural role. In a web app the database was the load-bearing layer: it set the ceiling on what the app could show and how fast, while the language and framework on top became interchangeable. In an agent stack the model is the interchangeable part (you can swap it next quarter) and retrieval is the layer that determines the answer's quality. Owning it is where the leverage sits, which is the whole argument in the backbone of the LLM economy.
What is Glean, and how is Interlinked different?
Glean is an enterprise "Work AI" platform, founded in 2019 by a former Google search engineer, that indexes and searches across a company's cloud apps, the retrieval layer under its AI assistants, built for people. Interlinked is the same idea aimed one layer down and one machine over: a whole-machine index of every repo and file on your own computer, built for agents, offline, with no model in the box. Glean for the local machine, in short. Agents plug in over an MCP server.
Isn't a vector database the retrieval layer?
A Pinecone-style vector database is one implementation of one kind of retrieval: fuzzy semantic recall over embeddings. It is not the whole layer, and for a local coding agent most lookups are exact: find this file, find every use of this function, read what changed. Interlinked handles those in microseconds and sits underneath a vector DB, not in place of one, the distinction we draw in it's not RAG and it's not memory.
Is any AI model running on my machine?
No. There is no model in the box: just an index and a lookup, offline and private. That is why it can answer in microseconds, and why every relationship it derives is a receipt (a count or a hash you can check by hand) rather than a model's guess.
Do this today
Give your agent a real database.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing, no keys.
Let it index. Filename search works immediately; content fills in behind it. At rest the whole engine sits around 44 MB (less than a browser tab) and its index stays under 1% of the drive.
Point it at everything. Whole-machine when you don't know where something lives; scoped to a folder when you do. A file you just saved is searchable in about a millisecond, under 30 at worst.
Let the joins grow. Day one it knows your git history. Every week after, it knows how your machine connects, automatically, offline, with no model in the box.
The database era minted the biggest infrastructure companies of its time, not by owning the app, but by owning the layer under it. The agent era has the same layer open, and locally it is still up for grabs. It is the unglamorous floor everything stands on. It is also the whole game.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.