A relevance score is normally spent selecting: rank the documents, hand the model the top few, and the agent can only ever answer from what those passages happened to contain. The other option is to leave the agent with plain text search and file reads and spend the same scores on sequencing — which files the scan reaches first, which paragraphs it starts from, which raw matches get shown. Same embedding model, same corpus, no extra retrieval interface. On a hundred-thousand-document search task that moved accuracy from 78% to 84% while cutting the agent from 99.1 tool calls to 23.9 — and every one of the three places relevance was injected made it both more accurate and faster.
A retrieval agent gets a top-k endpoint: it asks, it receives a handful of snippets, and everything outside those snippets is invisible for the rest of the run. A direct-interaction agent gets a shell and greps the corpus itself: nothing is invisible, but it works blind, and a question whose evidence is scattered across several documents turns into dozens of tool calls of trial and error. Switch the measure and watch the trade.
The plain grep agent and the structured retrieval agent land on the same 78% from opposite directions — one by never seeing enough, the other by seeing everything in no useful order and running out of patience. Relevance-as-order gets 84% while doing less work than either.
The agent keeps exactly two tools — run a shell command, read part of a file — and gains one more that ranks documents against a query and returns no content at all, only a file of paths in ranked order. Everything else is plumbing around when those rankings get applied. Step through the three levels; each is added on top of the last.
The result to notice is that these do not trade off against each other. Normally an accuracy gain in a search agent is bought with more steps; here each level of relevance added accuracy and cut steps at the same time, because a better-ordered scan converges instead of wandering.
Ordering is a way of managing scarcity, so its value should grow with the corpus and shrink with the backbone's patience. It does. Move between the two corpus sizes and the two backbones — the gap over a structured-retrieval agent widens as the corpus gets ten times larger, and survives on a stronger model rather than being washed out by it.
Ten times the documents costs the ordered agent 5 points and the structured-retrieval baseline 9. Neither is immune, but an approach that never discards the corpus degrades more gracefully than one that has to summarise it into an index first.
Browse questions have handles — names, numbers, quoted strings — so a text search can bite. Reasoning-intensive retrieval does not: the right document shares almost no vocabulary with the query, and grep alone flounders. This is where you would expect an embedding-first agent to win outright, and roughly, it does — but the ordered agent matches it using a general-purpose scan.
One nuance worth carrying: on this task the seeding step — starting the agent from the ten most relevant paragraphs — mattered more than reranking the raw matches, the reverse of the browse task. Which level of relevance pays depends on whether your queries have lexical handles.
If you already run an embedding model behind a top-k endpoint, you have everything this needs — the change is where the scores are spent, not what produces them. Set your query volume and how expensive a tool call is in your loop, then switch the strategy. Tool calls per question are the paper's; the money and minutes are illustrative.
The honest caveat lives in the same box: forcing the scan to run in ranked order means running it single-threaded, and reranking the matches costs an extra model pass. Per question that is a small tax on a number that fell by three quarters — but it is a tax, and on a corpus where the plain agent already converges in a handful of calls there is nothing here to win.