Model routing in plain language: how one request finds the right engine

If you have heard someone say their AI system "routes across models" and nodded politely, this article is for you. There is no code in it.

The dispatcher analogy

Think of a well-run service company. Calls come in. A dispatcher decides which technician takes each one — based on who is closest, who has the right certification, who has the parts on the truck, and how urgent the job is. The dispatcher is not doing the work. The dispatcher is deciding who does the work, and that decision determines most of the outcome.

A routing layer is the dispatcher. The models are the technicians. Your request is the call.

What happens to a request

1. The request is classified. Before anything else, the system determines what kind of job this is: extracting specific facts from a document, drafting something in a particular voice, reasoning through a problem with multiple constraints, summarizing at length, or answering a simple factual question. These are genuinely different jobs, the way a panel upgrade and a thermostat swap are different jobs.

2. Context is gathered. The system pulls in what it needs to answer well — the relevant customer record, the prior conversation, the document being discussed, the house style guide. This step is where most of the perceived quality difference between AI products comes from. A mediocre model with the right context beats an excellent model working blind, consistently.

3. A model is selected. Now the dispatcher decides. Reasoning-heavy work goes to a model that is strong at reasoning and slower and more expensive. High-volume mechanical work goes to something fast and cheap. Something needing a very long document goes to a large-context model.

4. The work is done and checked. The response comes back and gets validated — is it the right shape, does it contain what was asked for, does it contradict the source. Failures get retried, sometimes on a different model.

5. It hits the gate. If the output is going outward — to a customer, into a record, toward money — it stops and waits for a human. If it is internal and reversible, it proceeds.

Why the path matters more than the brand

People ask "which model do you use?" the way they would ask which brand of truck a contractor drives. The honest answer is that the truck matters far less than the dispatcher, the parts inventory, and whether anyone checks the work.

Two systems using the identical model can differ enormously in output quality, because one of them gathers the right context, picks the right prompt for the job, validates the response and routes failures somewhere sensible, and the other passes your question straight through.

What this buys you as a customer

Resilience. When a provider has an outage — and they all do — the dispatcher sends work elsewhere. Your Tuesday is not defined by someone else's incident page.

Cost control. You are not paying premium rates for routine work. In a system handling meaningful volume, this is not a rounding error.

Improvement without migration. When a better model arrives, it enters the rotation. Nothing you built has to change.

The one thing to ask

If you take a single question from this article into a vendor conversation, make it this: how do you know which model is best for my kind of work?

A good answer describes a test set of real examples, graded outputs, and periodic re-evaluation. A weak answer describes a benchmark chart from a model provider's launch post. The first is a dispatcher who knows the crew. The second is a dispatcher guessing from résumés.