Explainers · updated July 2026
What is a context engine? The layer that decides what your AI sees.
A language model has no standing knowledge of your machine: not your repos, not your configs, not the document with the answer. Everything it appears to know about your code was selected, ranked, and pasted into its prompt a moment earlier. The system that does the selecting is the context engine. Get it right and the model feels omniscient; get it wrong and the smartest model on earth answers from the wrong three files. Cursor has one. Glean has one. Here is what they are, and the one your local machine is still missing.
The whole idea in one picture
A machine on one side. A sliver on the other.
Your machine holds millions of files. A prompt holds a handful. The context engine is the funnel between them: it takes a question and returns the small set of files, symbols, or lines most likely to answer it, small enough to fit the window. Everything downstream (the model's reasoning, the quality of the diff) is capped by what made it through. The engine is not a feature of the model. It is the gate in front of it.
The three jobs are always the same: find the candidates, rank what matters, assemble a slice that fits. Change the engine (its reach, its freshness, whether it guesses or proves) and you change the answer, on the exact same model.
Two you have already met
You have used a context engine. Probably two.
“Context engine” is not a marketing coinage: it names a real layer, and two of the best-known tools in software are built around it. They are drawn fairly here; both are good at the job they were built for. The point is only where each one's edge falls.
Both prove the pattern. Both also stop at an edge: Cursor at one repo, Glean at the company's cloud. Neither is the machine you actually work on: the dozen repos that ship together, plus the non-git 90% (configs, documents, downloads, the PDF with the answer), fed to every agent, not just their own.
How to judge one
Four questions to ask any context engine.
What can it even see? One repo, one company's cloud, or the whole machine, every repo and the files git ignores?
How current is the answer? This second, right after you save, or whenever it last re-indexed?
Is a hit a literal match you can verify, or a model's guess ranked by similarity, which drifts until re-computed?
Does it answer fast enough to live inside the agent's loop, or does every lookup stall the run?
| Context engine | Reach | Freshness | Trust | Speed |
|---|---|---|---|---|
| Cursor | the one repo you opened | fresh as you type | semantic: ranked by meaning | in-editor |
| Glean | your company's cloud apps | re-synced by connectors | semantic: ranked by meaning | server round-trip |
| Interlinked | whole machine · every repo + non-git | ~1 ms after a save | literal: exact, verifiable | 85 µs to 16 ms, local |
Cursor and Glean are semantic engines: they retrieve by meaning, which is the right tool when you don't know the words. Interlinked is literal: exact, verifiable, whole-machine. Different jobs; they belong in the same stack. The row nobody had filled is the last one: a context engine that reaches the whole local machine, stays literal, refreshes on save, and answers fast enough to live inside the loop.
The local engine, measured · Ryzen 9 9950X3D · 4.47M files
Fast enough to live inside the loop.
| The tool | The task | Time | vs Interlinked |
|---|---|---|---|
| Interlinked (live index) | one indexed lookup | 85 µs | the baseline |
| VS Code · Ctrl+P | same file, same drive | 35 s | 412,000× |
| Windows Search | median of 20 queries | 67 s | ~480,000× |
| ripgrep (content query) | same query, same corpus | 93.8 s | → 16 ms |
Same machine, same drive, same queries. On the content lane a query that took ripgrep 93.8 s returned in 16 ms, and across the five-query set, 58,625× faster than ripgrep.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 µs across 20 queries, 85 µs single-file; content queries run ~7 to 9 ms, ~16 ms for exact phrases. At rest the engine sits around 44 MB in Task Manager, and the on-disk index stays under 1% of the drive (~24 GB on a 4 TB machine).
The context engine for the machine in front of you
Cursor indexes a repo. Glean indexes a company. Interlinked indexes the machine, for every agent.
Interlinked is the context engine for the local machine: an always-fresh index of every file (names and contents) across every repo and the non-git 90%, exposed to whatever agent you use through one connector. No model in the box, so every hit is a literal match you can verify, not a ranked guess, and it never leaves the machine. The same index carries a relationship layer it builds by itself: which files change together, which repos ship together. The local analogue of the enterprise graph, seeded from your own history with zero LLMs. Keep Cursor's index. Keep Glean. This is the layer under both.
PARALLEL TO CURSOR AND GLEAN · WHOLE-MACHINE · LOCAL · NO MODEL IN THE BOX.
Give every agent the whole machine
Put a real context engine under your agents.
Install once. One signed installer indexes every file on your machine and auto-configures 19 AI clients: Claude Code, Cursor, Codex, Windsurf, Zed, Cline and the rest. No JSON to edit, no cloud account, no keys.
Ask across the whole machine. Names, symbols, strings, error messages. Whole-machine, across every repo and the files git ignores, fresh to the last save. At rest the engine sits around 44 MB.
Keep your semantic engines. Cursor and Glean answer 'what is this about?' by meaning. Interlinked answers 'where is this exact thing, right now?' Different jobs, same stack.
Let the relationships grow. Day one it knows your git history: which repos ship together, which files move as a pair. Every agent reads it, 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 · RAG, a live index, or grep?