Explainers · the local AI stack · July 2026
Every LLM you run stands on five layers. Only two of them get talked about.
Ask an agent to change something on your machine and five layers move in order: you, the agent, the model, the context it needs, and the machine that context lives on. The two at the top (the harness and the model) get the funding, the release notes, and the arguments. The layer under them quietly decides whether either can do its job: context acquisition (getting the right files, the right lines, and the right history in front of the model before it can think). Everything above it is capped by it. This is a field guide to that stack, and to the fact that two of the most valuable tools in AI are built on this exact layer.
A companion to the backbone of the LLM economy, which measured how much of an agent's day this layer eats.
TL;DR
Every LLM task moves through five layers: you, the agent, the model, the context it needs, and the machine it lives on. The industry funds the top two and ignores the one holding them up.
That layer is context acquisition: find the files, read the exact bytes, remember what was already decided. A model is only as good as what reaches it, so this floor caps everything above it.
Glean and Cursor are billion-dollar bets on this same layer at different scopes: company cloud apps, one open repo. Nothing covered your whole local machine, for agents.
Interlinked fills that scope: one file among 4.47M in 85 μs, content search machine-wide in 7 to 9 ms (the query ripgrep takes 93.8 s), ~44 MB at rest, no model in the loop.
On one real agent task the fast floor turns 6m 57s and 71 tool calls into 16 ms and a single call, and ~58% of session tokens spent hunting files drops to ~0%.
The stack, drawn honestly
Five layers. One of them holds up the rest.
The tower is what the industry ships and debates: a smarter model, a slicker harness, your prompt. It is narrow and it moves fast. Underneath sits a wide slab that almost nobody names, and the whole tower's output is bounded by it. Read the slab left to right and the same layer appears at three different scopes.
Cursor appears twice on purpose: once as the harness you drive, once as an index underneath it. That is the tell: the context layer is so essential that every serious tool builds its own.
The bedrock, defined
A model is only as good as what reaches it.
“Context acquisition” is one plain job with three steps: find which files and lines matter, read the exact bytes, and remember what was already decided. The result is poured into the context window, the only thing the model ever actually sees. Get this wrong and the smartest model on earth answers a different question well.
This is why the layer is bedrock and not plumbing. You cannot reason your way out of a file you never found. A better model widens the top of the tower; it does nothing for a floor that hands it the wrong bytes, slowly. The ceiling on the whole stack is set by the slowest, least-visible layer, and today, on a local machine, that layer usually runs on tools built for one human with one project open.
Two proofs the layer is real
Two of the biggest bets in AI are context-acquisition companies.
Glean built an enterprise on this one layer: a single search box that reaches across all of a company's cloud apps and hands an employee (or their assistant) the right document. Cursor indexes the repository you have open so its model can find the right lines instead of re-reading the tree. Two of the most valuable products in the category, and both are, underneath, the same thing: find the right context fast and put it in front of a model. They just chose different scopes.
The pattern is the point. When a layer is valuable enough that companies get built at each scope of it, the layer is the infrastructure, not the feature. Here is the same slab, read across three scopes:
| What it indexes | Built to serve | Scope | |
|---|---|---|---|
| Cursor | the one repo you have open | the model in your editor | one project |
| Glean | your company cloud apps | employees, in a browser | the enterprise |
| Interlinked | every file on the machine | any agent, over MCP | your whole computer |
Descriptions reflect each tool's own public documentation of what it indexes and where it runs. The gap is the row that isn't there: nothing covers your whole local machine (every repo plus the 90% of the disk that was never in git) for an agent rather than a person, without shipping your files to a cloud.
The open scope
The same bedrock, for your whole machine, for agents.
Interlinked Files sits on the exact layer Glean and Cursor sit on (context acquisition) at the one scope neither reaches: every file and every repo on a single Windows machine, offline, keyed to a file's OS identity instead of its folder, built for agents instead of people, with no model anywhere in the loop. It is a purpose-built indexed engine that stays warm in the background so the answer is already computed when the agent asks. Measured on the machine below:
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Same machine, same drive, same queries as the comparison runs in the VS Code write-up and the ripgrep comparison.
AND IT REMEMBERS: DAY ONE, 12/12 REPOS WEBBED · 26,958 RELATIONSHIP PAIRS REPLAYED FROM 8,455 GIT EVENTS IN 1.7 S · NO MODEL, ALL RECEIPTS.
What the bedrock is worth, measured
Slow floor, then fast floor.
One real task, one file, on the 4.47M-file machine above. Raise the model a tier and the tower gets smarter; it still spends six minutes of a seven-minute session on the floor. Drop a fast layer under it and the same run collapses to a single call. That is the leverage of the bedrock: it multiplies (or throttles) every layer stacked on top. The full run is in the Claude Code teardown.
Common questions
The bedrock, answered plainly.
Does any of my data leave the machine?
No. Interlinked runs fully offline: no model, no cloud, no keys of any kind, just an index and a path/id match. Your files never leave the computer.
How is this different from Cursor or my IDE's built-in index?
Those understand the one repo you have open; Interlinked indexes every file on the whole machine (4.47M here), including the ~90% of the disk that was never in git. It is the connective layer across all your repos, exposed to any agent over MCP.
How much faster is it than the search I already have?
Finding a file runs about 412,000× faster than VS Code and ~480,000× faster than Windows Search, which takes 67 s for the same lookup. For content, the query your agent already runs takes ripgrep 93.8 s cold and 16 ms here, 58,625×.
Will it slow down or bloat my machine?
No. At rest the whole engine sits around 44 MB (less than a browser tab) and the index on disk stays under 1% of the drive. It stays warm in the background, so the answer is already computed when an agent asks.
What does it cost?
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo.
Give your agent the bedrock
Put the fast layer under everything.
Install once. One signed installer configures 19 AI clients and starts the background index. Filename search works immediately; content fills in behind it.
Let it stay warm. At rest the whole engine sits around 44 MB (less than a browser tab) and the index on disk stays under 1% of the drive.
Scope when you know, go wide when you don't. A folder you know returns in microseconds; the whole machine when you don't know where something lives.
Let the vault grow. Day one it webs your repos from their own git history. Every week after, it knows your machine better, automatically, with no model in the loop.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.