A model router is a component that decides which AI model handles each request, sending simple tasks to a smaller, cheaper model and harder ones to a larger or more specialised model. For AI agents it keeps costs and response times down without giving up quality where it counts. It also means the model behind an agent can change from one step to the next.
Why does a model router matter once agents act?
Because certification is evidence about behaviour, and behaviour depends on the model. If an agent was tested on cases handled by one model, and the router later sends the same capability to a different model, the evidence no longer describes what is running. Nothing in the agent's brief changed, yet its behaviour may have.
That does not make routing a bad idea. It makes the set of models a router may choose part of what has to be tested.
How does a model router work in practice?
The router looks at each request and applies rules or a small classifier. Rules might be: classification and extraction go to a small model; drafting customer letters goes to a mid-sized one; complex reasoning over long documents goes to a reasoning model. Some routers also fall back to another provider when one is slow or unavailable.
In a governed setup, two constraints apply. First, the router may only choose a model the agent's certificate names. Second, the model actually used is recorded with every action, so a verdict can be reconstructed with the right model in view. Fallback to an uncertified model should limit that step to read-only, not carry on silently.
What does that look like in an example?
An insurer's claims agent uses a router. Reading claim forms and extracting fields goes to a small, fast model. Drafting decline letters goes to a larger model, because tone and accuracy matter. One afternoon the larger model's provider has an outage and the router falls back to an alternative. Decline letters drafted on the fallback are held for a handler to review, because the agent was never certified on that model. Field extraction continues on the model it was certified on.
How is a model router different from a foundation model?
A foundation model is the model itself: the thing that reads and generates. A router is traffic control in front of several models. It does not generate anything; it decides which model does. A router is also different from an orchestrator, which assigns work between agents rather than between models.
Why does routing support model independence?
A router makes it practical to switch models: you change the route, not the agent. That is part of why model independence is a governance requirement: if your controls live outside the model, you can move between models as prices, quality and providers change. The steps for doing it safely are in how to switch model provider without losing control of an AI agent. The router itself, though, should never be asked to judge whether an action is allowed, for the same reason the model cannot be its own supervisor.
Where Pryme fits
Pryme works with any model and records the model behind every action. Certification covers the models an agent runs on, so routing to a model the agent has not been proven on changes the verdict. See the governed agentic operating system, explained.
Questions people ask
Does a model router save money?
Usually, because many agent steps are simple and can run on cheaper models. The saving has to be weighed against the cost of certifying each agent on each model it may use.
Should the router decide based on how risky an action is?
It can route high-risk steps to stronger models, which is sensible. It should not decide whether a risky action is allowed; that belongs to the control layer.