A search tool hands your agent more text than its turn can hold, so something cuts it down. The comfortable assumption is that the agent will notice and ask for the rest. Across 4,175 file-search responses in production logs, these authors recorded zero agent-initiated requests for a second chunk. So they went after the obvious next lever — put the file the agent needs first — and lifted first-place accuracy from 24.2% to 35.8%. Downstream, nothing moved: at most 2.8 points either way across five models, none of it significant. The chunk boundary is the decision. The order inside it is not.
A coding agent asks for the files matching a pattern. The search returns fifty of them; the agent's turn has room for a fraction of that. Every harness solves this the same way — pack what fits, mention that there is more — and the packing is a knapsack: each candidate costs some tokens, carries some score, and you take the highest-scoring set that fits under the budget. The paper runs four budgets, 1,000 through 8,000 tokens. Drag the budget below and watch the cut line move.
The pagination number is the one to sit with. Every one of those 4,175 responses told the agent, in the response itself, that more was available. Not one agent went and got it. Whatever your tool leaves out of the first chunk, treat as deleted.
If the chunk is all you get, the natural move is to rank inside it: get the file the agent actually needs to position one. The paper's measure for this is p₁ — precision at one, the share of tasks where the needed file is the top item of the chunk the agent receives. Six selection policies were run over the same candidate lists, from filesystem order (what a shell search gives you) to an adversarially reversed baseline to a keyword scorer matching the query against the file path. Step through them.
Two things to read off this. The keyword scorer is a real improvement — +11.6 points of first place over filesystem order, for a scorer with no parameters to tune and no model call. And there is a hard ceiling above all of it: in 221 of the 500 tasks the needed file was never in the candidate list at all, so no ordering could ever put it first. The best any policy here can do is 55.8%.
Now the part worth changing your roadmap over. The same tasks were run end to end with each policy, and scored on the thing that matters: did the agent name the file that had to be edited. Five models, 4,800 calls, filesystem order against the keyword scorer. If ranking mattered, this is where a +11.6-point jump in first place shows up as better answers.
Three models went up, two went down, the largest movement in either direction is 2.8 points and every paired test lands nowhere near significance. A twenty-point swing in the ranking metric bought nothing an agent's user would ever notice.
The explanation is in how the gain is distributed. Split the scorer's improvement by how deep in the chunk you look: at position one it is large, and by the time you ask "is it anywhere in the top ten" it has mostly evaporated. That shape is the whole story — the scorer is reordering items that were already going to be in the chunk, and the agent reads all of them. Toggle the depth.
There is a second, sharper warning in the same section. The keyword scorer is one signal: does the query's vocabulary appear in the file path. The richer policy adds four more — how deep the file sits in the tree, its extension, how recently it changed, whether the filename matches — the sort of feature list that looks like an obvious upgrade in a design document. It is worse.
One more measurement pins the interpretation down. Condition on the runs where the needed file was ranked first, and the accuracy gap between the strongest and weakest model in the set contracts from 7.8 points to 1.9. Getting the right file into the chunk is what separates a good model from a weak one on this task. Where it sits once it is in there is nearly free.
Take this to the tool you actually ship — a search endpoint, a records lookup, an MCP server wrapping some internal index. Set how many results it returns, how big each one is, and the budget your harness gives a single tool response. The count that matters is the third one: results that exist, that your endpoint paid to produce, and that no agent will ever request. Everything you know about which result matters has to be spent before the cut, not after it.
The cheap moves, in order: cap the result count server-side so the model sees a set rather than a truncation; strip each result to the fields that decide the next step; and if you must lose something, lose it deliberately with a line saying what was dropped and how to ask for it by name — a second search the agent will happily run, unlike a second page it will not.