Assign each recurring AI task to a model based on what a wrong answer costs you. Write the rule down where someone else can read it. Re-test when the work changes. That habit will outlast every model release this year, and it takes an afternoon to install.<\/p>\n
Leaderboards are downstream of this. They can tell you which model performed well on someone else’s benchmark. Your refund queue has its own benchmark, and you are the only person holding it.<\/p>\n
Most teams settle on a single model because it removes a decision, and for a quarter or two that feels like maturity. Underneath, four different jobs are now running on one set of characteristics: support drafting, the weekly research memo, the classifier that routes inbound mail, and the code review assistant.<\/p>\n
They were one decision wearing four names.<\/p>\n
And the four want different things. The classifier needs a stable output shape at cheap volume. The code assistant needs scope control. The research memo needs a route tested for how it behaves when the evidence runs thin. Support needs one that recognises a case it should hand to a person. One route applies the same model characteristics to four jobs with different requirements, and different consequences when the output is wrong.<\/p>\n
Prices move. Capabilities move. A route chosen in March can be a worse fit by September. So the durable question is which model is good enough for this task, asked again whenever the task or the model changes.<\/p>\n
Routing means deciding which model handles which job before anyone writes a prompt. Start it as a line in a shared document. Automate it later, once the rule has been boring for a month.<\/p>\n
A workable policy answers four questions:<\/p>\n
Here is the part teams underrate. Routing is an operating decision that a developer implements. Marketing owns the copy routes. Engineering owns the coding routes. Support owns the customer-response routes. A developer can build the switch in a morning; deciding when it moves takes longer and matters more.<\/p>\n
Use this when you are choosing a model for work that repeats. Score each factor from 1 to 5. Some factors are gates, so resist the urge to average.<\/p>\n
The decision rule: take the cheapest, fastest model that clears the quality, privacy and review gates for that task. On high-risk work, eval confidence and review path outrank cost every time.<\/p>\n
What you produce is one line per workflow. Invented here for an example team, it reads like this. Support classification runs on the lower-cost model, which matched our policy labels on 94 of 100 test tickets. Reply drafting runs on the stronger model with the approved policy set supplied. Sending stays with an agent.<\/em> Three sentences, and the argument is settled until something changes.<\/p>\n The same card produces different answers depending on the work. These four cover most of what a business actually runs.<\/p>\n Tolerant of variance, unforgiving on unsupported claims. Gate on evidence discipline. A model that writes a gorgeous paragraph and invents a market-share figure has failed this class, however good the paragraph was.<\/p>\n Gate on scope control and output stability. The expensive part is review time. A patch that fixes your bug and quietly reformats two unrelated files costs more than a slower model that stays inside the brief.<\/p>\n Gate on source discipline. The model has to separate what a document says from what it infers, and say so when the sources fall silent. Fluency is a hazard here, because a confident summary of nothing reads exactly like a confident summary of something.<\/p>\n Gate on escalation behaviour. The model you want is the one that recognises a case it should hand over. Smooth handling of a refund edge case it misread is the worst outcome available, because it looks like success until the customer replies.<\/p>\n Before: every ticket goes to one model, which classifies it, drafts the reply and proposes the resolution. Classification tolerates variance. A misread refund policy reaches a customer. Both run under the same settings anyway, so when a customer receives a confident wrong answer, working out which step produced it takes a reconstruction — one model performed all three.<\/p>\n After: classification runs on the cheaper model that matched policy labels in testing. Drafting runs on the stronger model with the current policy set attached. An agent sends.<\/p>\n Same tools, same budget. Each step now has its own quality bar and its own named reviewer, so a wrong answer points at the step that produced it.<\/p>\n Sometimes you should. A small team, low volume, everything reviewed by a person before it leaves: standardise on one strong model and skip the overhead. That is a reasonable answer and plenty of good businesses run it.<\/p>\n It stops being reasonable at three thresholds. When volume rises far enough that cost per accepted result starts to matter. When a workflow begins taking actions on its own conclusions. When two classes of work need different things from the model and one of them is quietly losing. Cross any of those and “use the best model” becomes a preference standing in for a decision.<\/p>\n Two. Testing one model tells you whether it works; testing two tells you which one fits this class of work. Beyond that you have a routing layer only its author understands, which becomes its own failure mode around the time the person who built it goes on leave.<\/p>\n Once the manual rule has been stable long enough to feel dull. Automating a rule you are still arguing about hard-codes the argument, and arguments are harder to debug than code.<\/p>\n Then it belongs in the classes where the gates tolerate variance, and it stays out of the ones where they hold firm. “Almost as good” describes an average. Your gates exist for the worst case, which is the one that reaches a customer.<\/p>\n Quarterly for stable work, immediately when a provider changes pricing or capability. Put the review in a calendar, because the failure mode here is drift, and drift is silent.<\/p>\n Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\nFour task classes, four different gates<\/h2>\n
Copy and content<\/h3>\n
Coding<\/h3>\n
Research and synthesis<\/h3>\n
Customer support<\/h3>\n
A support queue, routed two ways<\/h2>\n
“Should we just use the strongest model everywhere?”<\/h2>\n
What to do this week<\/h2>\n
\n
Questions teams ask<\/h2>\n
How many models should a small team test?<\/h3>\n
Should routing be automated?<\/h3>\n
What if the cheaper model is almost as good?<\/h3>\n
How often should routes be reviewed?<\/h3>\n