Your agent never sees your whole tool library. It sees a shortlist — and that shortlist is almost always built by matching the request text against tool descriptions, which reliably surfaces the tool that produces the answer while burying the dull tools that produce its inputs. Rebuild the shortlist as a route instead — what can run from here, whose output feeds whose input, which orders recurred in past runs — and completed multi-step tasks go from 73.7% to 89.8% with the agent, the model and the prompt all unchanged. A routed shortlist of 32 tools covered more complete chains than the stock list of 128.
A tool menu is the short, ordered set of tools an agent is shown before it acts, and it can only call what is on it. Thirty-two entries is typical; the library behind it might hold thousands. The menu is therefore a prediction about what the run will need, and the usual way to make that prediction is to embed the request, embed every tool description, and take the nearest thirty-two.
The paper's worked example is a request to email a customer their receipt. Wording similarity puts the send-receipt tool first, because that is the tool whose description contains the words in the request. But it cannot execute until three other tools have run and handed it their outputs. Step through the route and switch how the menu was built.
Nothing is missing from the library and nothing is wrong with the agent. The failure is that a consumer appeared before its producer, and two producers never appeared at all — so the first thing the model tries is the one thing it cannot do yet.
That is not one unlucky request. Measured across the benchmark, three properties of a menu get better when it is built from routes rather than from wording: how often the whole chain is present, how often the first executable tool is near the top, and how much of an executable prefix the agent can actually see.
The constructor learns three things about every pair of tools: whether a tool can run at all from the state the request starts in, whether one tool's outputs satisfy another's required inputs, and how often one preceded the other in recorded runs. The retriever then picks thirty-two tools to cover an executable entry point, the producers of every missing input, and the final action; the reranker sorts them so producers land above consumers.
Those are two separable jobs — which tools are on the menu, and in what order. Turn each on and off.
Either half alone is worth about three and a half points. Both together are worth sixteen. That is the whole argument of the paper in one number: a menu is not a ranked list of relevant things, it is a claim about a sequence, and half a sequence does not execute.
If the effect were really about relevance, it would be flat across tasks. It is not: the advantage in complete-chain coverage grows with how many tools the reference route needs, because every extra step is another chance for a producer to fall off the bottom of a wording-ranked list.
Which is why menu size is the wrong lever. A routed menu of thirty-two tools covered complete chains slightly more often than the stock menu of one hundred and twenty-eight — four times the tools, four times the context, and it still hid the producers.
And when the paper pairs the runs task by task to ask what the new successes had in common, more than half of them were tasks whose stock menu never contained a complete chain in the first place. They were not lost to bad reasoning. They were lost before the first token.
The constructor has to learn which tools follow which, and it learns that from recorded runs. Take those away and it degrades to a schema-only retriever. Drag the slider to see how much recorded history it needs — then corrupt half of what is left, which is the realistic case if your traces come from an agent that was often wrong.
Two useful details fall out of that. Corrupting half the recorded routes costs one point of coverage, so this survives a noisy trace log. But going from a quarter of the routes to all of them is worth twelve points, so it does not survive having no log at all — which is exactly the position you are in on a tool surface you just shipped.
What the constructor reads matters less than you would think. Tool names alone get most of the way; adding the declared input and output fields is the whole remaining gain, and full prose descriptions add nothing on top of that.
And it costs time. Building a menu with every component runs about four hundred milliseconds at the median before the agent has emitted a single token — the neural parts are trivial, a few milliseconds each; the cost is in the frontier search around them.
Put the paper's measured gains against your own traffic. Pick the executor family closest to what you run — the paper reports paired gains for three, and the weaker the model, the more the menu does for it — set how many multi-step tool runs a day you serve, and see what the reorder buys and what the construction step costs you in latency.
The shape to notice is that the gain is largest on the cheapest executor. A menu that is already in execution order is doing work the model would otherwise have to do by planning, and a smaller model has less to spare.