Agents · measured July 2026 · 7 min
Tony Stark's Jarvis never ran grep. Your AI agent does.
In the Iron Man films, Tony asks a question mid-sentence and Jarvis already has the schematic on the glass: no searching, no waiting, the answer just there. Real agents do the exact opposite. Claude Code has no map of your machine, so to find one file it grinds ls, grep and read in a loop, 6 minutes 57 seconds in one measured run. The gap between the fantasy assistant and the real one is not intelligence. It is the retrieval layer. And here is the joke: “iron man” is literally one of our benchmark queries, found in 58 microseconds.
TL;DR: the short version
In the Iron Man films, Jarvis answers before Tony finishes the sentence: instant, total recall, no visible searching. That is the fantasy assistant.
Real agents do the opposite. With no map of your machine they loop ls, grep and read. We watched Claude Code spend 6m 57s and 71 calls to find one file.
The distance between Jarvis and your agent is not the model's intelligence: it is the retrieval layer under it. About 58% of a session's tokens go to hunting, not thinking.
“iron man” is literally one of our benchmark queries. A warm index returns it in 58 microseconds, roughly 1,700 times over in a single blink.
Interlinked keeps an always-fresh whole-machine index and hands it to 19 AI clients over MCP. The content query ripgrep needs 93.8 s for, it answers in 16 ms.
The fantasy, honestly
Jarvis never searched. That was the whole trick.
J.A.R.V.I.S. (“Just A Rather Very Intelligent System”) is the fictional AI assistant Tony Stark talks to throughout the Iron Man and Avengers films: it runs his lab, flies the suit, and pulls up any file, schematic or analysis the instant he asks. Watch closely and you notice what the movies never show: Jarvis looking for anything. Tony says a half-sentence and the model is already rotating on the glass. The searching is edited out, because on screen instant retrieval reads as intelligence.
That is the sleight of hand, and it is worth being honest about: the films assume the hard part is free. In reality, “knowing where everything is” is the hard part, and it is a completely different job from being smart. A frontier model can reason about your code beautifully and still have no idea which of your 4.47 million files the function lives in, because nobody handed it a map.
So the fantasy is not really about a smarter brain. It is about a brain wired to an instant index. Take that wiring away and even the best model becomes a very articulate assistant fumbling through drawers. The bottleneck was never the model.
Fiction vs the grep loop
One hop on screen. Seventy-one on your machine.
Here is the difference drawn. On the left, the movie: Tony asks, Jarvis answers, done. Retrieval assumed free. On the right, what actually happens today: an agent with no map guesses its way through the disk, re-reading the growing transcript on every pass, and loops until it stumbles onto the file. Same task, two different universes.
Same machine, same drive. The loop on the right is what runs today; the hop on the left is one MCP tool away.
One real task, measured
We put a stopwatch on the loop.
The distance between hunting for a file and knowing where it is. Put plainly: the run that took long enough to brew a pot of coffee collapses to a camera flash. A narrower test (one file by name) put Claude Code at 193.5 s against the same lookup at 85 µs: 2,276,000×, on the same drive.
This was Anthropic's strongest agent running on a $200-a-month plan, which buys a better model, not a better floor. The tools underneath stay the same ls and grep, so more than half of a premium session goes to typing directory listings the model forgets a turn later. Why the count climbs to 71. Measured on a Ryzen 9 9950X3D, 64 GB DDR5, NVMe, Windows 11, 4.47M files.
Same machine · same drive · same file
“iron man” in 58 microseconds. Everything else, still running.
We picked “iron man” as a benchmark query for a boring reason: two common words, no special characters, matches dozens of files, nowhere for a slow tool to hide. A warm index returns it in 58 µs. To put that in human terms: a blink lasts about a tenth of a second, so you could run this search roughly 1,700 times before your eyelid finished closing. Now line the same file up against every other tool on the drive:
| The searcher | The job | Time | vs a warm index |
|---|---|---|---|
| Interlinked | type “iron man”, one indexed lookup | 58 µs | the baseline |
| VS Code: Ctrl+P | open the file by name | 35 s | 412,000× slower |
| Windows Search | find by name (median of 20) | 67 s | ~480,000× slower |
| ripgrep (what your agent runs) | one content query, same drive | 93.8 s | 58,625× on the set |
| Claude Code (Opus, one file) | 71-call shell hunt for one file | 6m 57s | ~7,200,000× on the run |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename look-ups are a 139 µs median across 20 queries (85 µs for a single file, 2 µs best case; “iron man” landed at 58 µs). The ripgrep row is one content query over the same corpus (93.8 s versus 16 ms), 58,625× faster averaged across a five-query set. VS Code Ctrl+P (412,000×) and Windows Search (~480,000×) are the file-open and median-of-20 times; the Claude Code figure is the full measured agent run. Full per-tool method in the 412,000× VS Code write-up and the ripgrep comparison.
Why the gap exists
Search was built for a human with one project open, not a whole machine.
Jarvis had the run of the whole workshop; your agent's tools do not. VS Code indexes the folder you opened. Cursor indexes the repo you're in. Both are fast, inside that one boundary. But an agent's questions don't respect folder lines: the answer might sit in a sibling repo that ships alongside this one, or in the 90% of the disk that was never in git: a config, a document, a log. Nothing keeps a warm view of all of that.
So the agent falls back to the floor: ripgrep and ls, re-walking the disk on every single query, because nothing machine-wide is kept ready between them. The model isn't the bottleneck: it does exactly what a person would do with the same tools. The floor it stands on is what's slow, and a warm index is the missing wiring.
Close the gap
Give the agent an index. Then it answers like Jarvis.
Interlinked keeps an always-fresh index of every file on the machine (names and contents, every repo, the git-ignored files a cwd grep never sees, PDFs and Office documents included) and hands it to any agent over MCP. One signed install wires up 19 AI clients, Claude Code among them, with no JSON editing. Once the indexed-search tool is registered, the agent stops reaching for grep: it makes one call and gets the exact path back: no walk, no retries. The dramatic pause is gone.
Same agent · same model · same query
Fumbling in drawers
Answering like Jarvis
71 blind filesystem walks replaced by a single index lookup. Same model, same machine: a different floor.
And there is a second half Jarvis fans will recognize: the movie assistant didn't just find files, it knew how they related. The same index carries a knowledge vault that rides along on the searches the agent already runs, with no model in the loop. On a fresh machine it found 12 of 12 repos and replayed 8,455 git events in 1.7 s into 26,958 relationship pairs (in less time than it takes to say good morning) and flagged repos that quietly share hundreds of identical files, unprompted. Speed finds the file; the vault knows why it matters. The whole engine sits around 44 MB at rest (less than a browser tab) and stays fresh to about a millisecond after every save.
THE MODEL DIDN'T GET SMARTER. THE FLOOR GOT FASTER. THAT'S THE WHOLE DIFFERENCE.
Questions worth asking
Straight answers.
Was Jarvis real, or just movie magic?
Fiction, of course: J.A.R.V.I.S. is a character, and the films skip the searching entirely because instant retrieval reads as magic. But the honest half is buildable. The reason the movie assistant answers before Tony finishes asking is that it never appears to look: it already knows where everything is. That is not a bigger brain; it is an index. Give a real agent one and the dramatic pause disappears.
Why is a real AI agent so slow at finding files?
Because it has no map of your machine, only shell tools. So it guesses: list a folder, grep for a word, read a candidate, decide, try again. On a 4.47M-file drive we watched that loop run 71 times over 6 minutes 57 seconds to open one file. A prebuilt index answers the same request in 58 µs by name, 16 ms by content: the loop drawn out, and the one call that ends it.
Does this replace RAG, my vector database, or model memory?
No. It is the layer underneath them. A fast, exact index of names and contents, with no model in the loop: a lookup is a word, a row, a list of files, not an embedding's best guess. Keep your stack; give it a faster floor. More on why it runs parallel to RAG, not against it.
Won't the index be stale right after I edit a file?
No. A save is searchable again in about a millisecond, under 30 ms in the worst case, so the index never lies about a file you just wrote. It is a live map that updates as files change, not a nightly rebuild you wait on.
Which agents can actually use it?
One signed install auto-configures 19 AI clients (Claude Code, Cursor, Copilot, Codex, Windsurf, Cline, Zed and the rest) over the Model Context Protocol, with no JSON editing. The same index serves all of them; no per-app plugins.
Do this today
Wire your agent to an index.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed 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 updates as you save.
Scope when you can. Whole-machine when you don't know where something lives; scoped to a folder when you do. Scoped queries return in the microsecond range.
Let the loop die. The agent trades 71 blind tool calls for one that returns the exact path, and stops spending its token budget on directory listings it forgets.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. No Jarvis required. Download for Windows.