The router sorts requests into concepts, and the obvious question is where the concepts come from. Two answers are available.
Learn them. Embed a corpus of real traffic, cluster it, name the clusters. The categories are grounded in what people actually send, which sounds strictly better and mostly is.
Author them. Somebody writes down the kinds of work that exist, with a description, three or more example sentences, the capabilities required and the constraints that bind. That file is the definition.
We author them, and the reason is not accuracy.
What a concept file looks like
moneypath.verify:
describes: >-
Check a change that touches value transfer — balances, ledgers,
refunds, settlement. Value-bearing work, treated as critical by default.
exemplars:
- does this refund path still keep debits equal to credits?
- review this change to the settlement reconciliation job
- verify the ledger entries this migration rewrites
- can this retry double-charge the customer?
needs: [tool_use, reasoning]
constraints:
residency: in_infra
min_tier: high
verifier: pytest
Adding a route is writing one of these. Nothing is retrained, no corpus is required, and the exemplars are what the embedding classifier compares against — so "teaching" the router a new kind of work is a pull request with four sentences in it.
The argument for authoring
A constraint has to be attached to something a person chose. residency: in_infra on this concept is a compliance decision. It is not a property you
discover in a cluster; it is a claim about what this category of work is allowed
to touch. Learned categories give you groupings with no natural owner and
nowhere obvious to hang a rule that somebody has to be accountable for.
Categories should change deliberately. A learned taxonomy shifts when the traffic shifts. That is the feature, and it is also a routing policy that changes without anyone approving it — which for money-path work means a constraint could stop applying to a request that would have matched last month. Authored concepts change in a diff.
You can argue with a file. When someone asks why their request went where it did, the answer is a description and four example sentences they can read and disagree with. "It was closest to cluster 7" is true and unarguable, which is worse.
What it costs
Somebody has to write them, and that is judgement rather than measurement. Coverage is a real risk: traffic that fits no concept goes to the default, which is correct behaviour and also a signal you are missing a category.
So unclassifiable requests are logged for taxonomy review. Not as an error — the
router never fails closed on classification — but as the input to the meeting
where you decide whether general.assist is quietly absorbing something that
deserves its own row and its own constraints.
The ladder underneath
Authored concepts do not mean an expensive classifier. Classification is a ladder, cheapest first:
explicit header → the caller already told us
per-conversation → classified once, not once per turn
embedding → compare against the exemplars
llm → only the low-confidence tail
default → and never an error
The budget is 5% of end-to-end p95. The LLM rung exists for the tail and is not allowed to become the common case, because a classifier that costs a model call per request has made routing more expensive than the thing it was meant to make cheaper.
Most requests never get past the second rung.
The part that is actually load-bearing
None of this makes the classification more accurate than a learned one. It probably makes it slightly less.
What it makes is reviewable. The routing policy for money-path work is a file in a repository with a commit history, and changing what counts as money-path work means someone approving a diff. For a system whose entire pitch is that hard constraints gate before preferences rank, the constraints need to be attached to something a person put their name on.