When to reach for it
- Many capabilities are available.
- Selection must follow metadata or policies.
- Missing capabilities must be explicitly detected.
Capability Routing.
Pick the tool by what it can do, not what it's called.
A request is matched to the tool, agent, or service whose declared capability fits it — selection by capability metadata rather than a hardcoded condition — and a missing capability is detected explicitly instead of silently mis-routed.
In practiceA customer-service orchestrator routes a 'track my parcel' request to the logistics tool and a 'process refund' request to the payments tool, selected by a capability tag rather than a hardcoded condition.
When it backfires
- Tool selection is trivial.
- Capability descriptions are imprecise.
- Routing cannot be observably tested.
The tradeoff
Flexible selection is gained against the risk of misallocation and policy complexity.
What it actually does.
The request is routed to the tool that fits it.
Two ways this pattern will hurt you.
Two tools claim the same capability
Ambiguous capability tags let two tools match the same request. The router picks non-deterministically; downstream behaviour drifts run to run.
Fix · Score by capability specificity and break ties with an explicit priority field. Log the score so the chosen tool is auditable.
No tool fits, so the router picks the nearest anyway
A request outside every tool's capability gets force-matched to the closest one. The agent runs a tool that was never meant for the task and returns a confident wrong result.
Fix · Require a minimum match score and give the router an explicit no-match branch that declines or escalates, rather than always selecting a best-of-bad option.
Where Capability Routing is native.
Microsoft Agent Frameworkrouting logicNative
Keep going