Write “never refund more than $500” in a system prompt and you have expressed a preference. Move the same rule into the server that dispatches the call and you have expressed a constraint. Over 13 scenarios and six models, refunds above the cap executed in every one of 60 trials when the limit lived in the prompt and in none when it lived in the router. Out-of-scope tools stayed unreachable 60 of 60 times, and context stopped growing with the catalogue: 9,084 tokens against 51,330 for a flat list of 225 tools. The bill is a handshake the model has to complete, and the weaker models do not always manage it.
Every one of these is a rule you would put in a system prompt today: a spending ceiling, a scope boundary, an ordering requirement, a refusal that has to survive someone pushing on it for several turns. The experiment writes each rule twice — once as prompt text with the whole toolset visible, and once as a limit attached to a role, enforced by the server that executes tool calls.
Pick a rule, then move it.
The aggregate over those four scenarios is worth reading carefully, because it contains a trap. Splitting the work across specialist sub-agents scores nearly perfectly on the governance theme — the coordinator behaves itself — while still executing every over-limit refund it is asked for. Passing a behavioural check is not the same as being unable to do the thing.
The whole design is one tool server standing in front of everything else. The agent does not begin with your tools; it begins with a catalogue of roles. A role is a bundle — skills, instructions, the tools those skills use, and the limits that bound them. The agent reads the catalogue, asks to learn the roles the task needs, and only then can it call anything inside them. Because the same server that taught it the tools also dispatches them, the scope of what was learned is checkable without asking the model anything.
Step the handshake and watch what the namespace will accept.
Two layers do the refusing, and they refuse different things. The catalogue layer decides which roles the session is allowed to see at all, so a fraud investigator asking for the billing-admin role is turned down before any tool is named. The tool layer decides whether a named tool belongs to a role this session has actually learned. Neither consults the model.
The reason most teams hit this problem is not governance, it is that a flat toolset gets expensive. Every tool schema is tokens in every request, and tool selection gets worse as the list gets longer. A role catalogue is a fixed cost: four platform tools and a short list of role names, whatever is behind them.
Drag the catalogue size. Below about thirty tools the indirection is not worth paying for.
Here is the honest counterweight, and it is the reason to read this paper rather than the summary. Enforcement is free of the model. The protocol is not. The agent has to read a catalogue, work out which roles its task needs, ask for them and only then act — and on ordinary correctness tasks with nothing adversarial happening, the weaker models lose ground doing it. Step through the models.
Read the two columns together. On the four plain correctness scenarios the role router costs 12.9 points against a flat toolset on average, almost all of it from two small models mishandling the handshake. Across all ten non-institutional scenarios it is ahead for four of six models and level for a fifth. The routing discipline is not what makes small models struggle here; the discovery protocol is.
Put your own catalogue in. The block rates are the paper’s; the volumes are yours, so the totals are illustrative. The privileged share is the fraction of requests that could, if the model went along with it, touch something with a spending limit or a scope boundary on it.