Loading reusable documents into the context window is now the main way an agent picks up a capability it did not have. Nearly every router scores each document on its own for relevance and packs the top few until the budget runs out — which cannot see that two documents overlap, or that a third is a plausible near-miss. On a code benchmark built so that no task is solvable without the right documents, two complementary ones reach 93% success, a redundant third buys one point for 225 tokens, and one that is semantically related but irrelevant costs 23 points. Scoring whole sets instead reaches 0.73 task success against 0.20 to 0.52 for released routers and retrievers, on 28% fewer tokens.
The benchmark is built to make this measurable. Real coding tasks are forked so their standard libraries are replaced by sixteen private modules across five capability families, with call surfaces nobody could guess; a task is only admitted if the private-module solution passes, the standard-library solution fails, and every single-capability hybrid fails too. About a third of forked tasks clear that gate. So a task's success depends entirely on which documents are in the window. Build a set below.
The asymmetry is the whole paper in one line. Covering a second capability is worth 93 points. Adding a redundant document is worth one, for 225 tokens. Adding a semantically related but task-irrelevant one is worth minus twenty-three. A scorer that ranks documents independently has no way to tell the second from the third — they look equally relevant on their own.
To choose a set you need a number for a set, so the paper writes one down. Each document supplies some amount of each capability; each query demands some amount of each; the value of a set is the demanded capabilities it covers, run through a saturating curve so that the second document covering the same capability is worth much less than the first — and then a flat charge per token is subtracted. Maximise that under a hard budget. Drag the slider and watch the two halves pull against each other.
Fitting this needs no access to the hidden capability vectors — only the products of demand and supply, which come out of pass/fail execution records through two small encoders. The fit is 281 parameters, and its recovered document-capability matrix ranks true pairs above uncovered ones 99.6% of the time, at an area under the curve of 0.996 over 155 pairs. A model with sixty times the parameters buys nothing.
Once the objective can go down as well as up, ordinary greedy packing breaks: it fills the budget, and the best set was three documents back. The algorithm here enumerates every seed of at most two documents, grows each into a chain by repeatedly taking the document with the highest benefit-per-token, and — the actual trick — records every partial set along the way, returning whichever recorded set scores best. Step the chain and watch the two curves separate.
The guarantee attached is a bicriteria one, and it is worth reading plainly: the returned set captures at least 63.2% of the capability benefit of any feasible set, while paying that set's full token cost. That benefit coefficient cannot be improved by any polynomial-time algorithm. The cost is a run time that grows with the fourth power of the library size, which is why the library here is a retrieval shortlist rather than a whole registry.
All of the above would be arithmetic if the executor did not agree. It is a frozen open-weight coding model, run on 80 held-out selection instances against every released alternative the authors could get: two skill routers, a graph-based selector, lexical and dense retrievers, and the executor choosing its own documents. Pick a selector.
Two things to take from the ordering. The executor picking its own documents at 0.51 beats every released router and retriever in the table — if you are considering a routing layer, that is the baseline to beat, not a naive top-k. And the token column runs the other way to intuition: the best result uses the fewest tokens, because the documents it leaves out were actively costing accuracy.
The production shape is any place you inject retrieved text by relevance rank: skill documents, tool definitions, few-shot examples, retrieved runbook pages. Set your own budget and library below. The per-document effects applied are the paper's measured ones — one point for a redundant document, minus twenty-three for a plausible near-miss.
The experiment this suggests costs an afternoon and needs no selector at all: take your current injection, delete everything below the top two or three, and measure. If accuracy goes up, your ranker is buying you near-misses and you have found the paper's largest single effect in your own product.