Position
More AI models do not automatically make a better system
Adding a second or third model to a business process only pays when one of them has a distinct job, including the job of disagreeing. Otherwise you have bought delay and cost.
- Published
- September 9, 2026
- Last checked
- September 9, 2026
- Written by
- Dryvn AI editorial
- Edited by
- Dryvn AI editorial
- Reviewed by
- Not yet reviewed by a named person
- Read as
- Editorial (Dryvn's practical method)
The instinct that more is safer
When people first see that different AI models give different answers, a reasonable instinct kicks in: use more of them. If one might be wrong, surely three are safer. We hear this in nearly every conversation about building a system, and we think it is half right in a way that makes it dangerous.
The half that is right: one model agreeing with you is not a check. The half that is wrong: three models producing the same kind of output are not a check either. They are three drafts. Somebody still has to decide, and now they have three times as much to read.
What a second model is for
Anthropic's guidance on building agents lays out a handful of public patterns that are worth knowing by name, because they explain when an extra model earns its keep. Routing sends different kinds of input to different specialists. Parallelization runs pieces at the same time, or runs the same task several times and votes. Evaluator-optimizer has one model produce and another evaluate, in a loop [S11]. The same document advises adding complexity only when it demonstrably improves outcomes, and starting from a single well-set-up call.
Look at what those patterns have in common. In every one, the second model has a different job from the first. It classifies, or it checks, or it produces a competing answer to be compared. What none of the patterns describes is three models each writing a version of the same thing for a person to pick from. That is not a system design. That is a lack of one.
So our test for a second model is simple. Does it have a job the first one does not have, and is one of those jobs to check or to disagree? If yes, it may be worth the cost. If no, you are paying for the same work twice.
The costs people skip
- Money. Every extra model call is paid for. Three calls per task, plus a fourth to reconcile them, is four times the bill for a task that may not need it.
- Time. Calls that wait on each other add delay. A customer reply that took two seconds now takes eight. That matters less for a monthly report and a lot for a text message.
- Failure points. Each handoff between models is a place where context is lost or the format breaks. More handoffs, more silent failures, and each one needs a person to notice.
- Attention. The most expensive cost. Three outputs with no rule for choosing between them means a person reads all three and decides. You have automated the drafting and manualised the deciding.
Illustrative example · fictional
One task, built two ways
A fictional accounting practice wants to sort incoming client emails into three bins: needs a partner, needs a bookkeeper, or can be answered from the standard replies. The first build uses three models. Each reads the email and proposes a bin. If all three agree, the email goes there; if not, it goes to a partner. Cost per email: three calls. Result: the models agree about nine times in ten, and the tenth goes to a partner with three opinions attached and no explanation of why they differed. Partners now read more email than before.
The second build uses one model and two rules. The model proposes a bin and, separately, names which client and which matter the email is about. Rule one: if the client or matter is not found in the practice's records, the email goes to a bookkeeper to identify first, whatever the model proposed. Rule two: any email mentioning a deadline, a penalty or a dispute goes to a partner, whatever the model proposed. Cost per email: one call. The rules catch the cases that matter, they are written in plain words the partners agreed to, and when an email lands in the wrong bin the practice can see which rule or which proposal was wrong.
Now suppose the practice wants a genuine check. It adds a second model with a single job: given the email and the proposed bin, say whether the bin is defensible and quote the sentence that decides it. When the checker disagrees with the proposer, the email goes to a partner with both reasons attached. That second model has a distinct role, it checks rather than produces, and disagreement has a route. This is where a second model earns its place. Three drafts never did.
When several models are worth it
- 01Each has a distinct jobProduce, check, classify, compare. If two models have the same job, remove one.
- 02At least one checksA checker's output is a verdict with a reason, not another draft. It should be able to say the first model was wrong.
- 03Disagreement has a written ruleWhat happens when they differ: which one wins, or does a person decide, and with what evidence in front of them.
- 04The cost is measured against the error it preventsIf the checker catches one costly mistake a month, it pays for itself. If it catches nothing in three months, it is a habit, not a control.
- 05A person still owns the outcomeModels do not carry responsibility. The system should make it obvious who does.
Our position, stated plainly
Dryvn's public view is that one chatbot agreeing with you is not a strategy, and that models do more useful work when they have distinct jobs and are made to disagree. We stand by that. It is not the same as saying more models are better. It is saying that the value comes from the roles and the checks, and that a system with no checker is not improved by adding producers.
For most business tasks, start with one model, a couple of rules written by the people who own the work, and a person deciding the exceptions. Add a checker when the cost of being wrong justifies it. Add anything beyond that only when you can name the job it does. The multi-model systems explainer has a worksheet for writing those roles down before you build anything, and the tools guide covers what to compare when you are choosing the models themselves.
The maintained resources behind this article
- How multi-model AI systems work, and when one model is enoughSee what happens when several AI models share a job, why disagreement is useful, what it costs, and how to write down roles and checks before you build.
- What should AI be allowed to do without asking?Decide, action by action, what an AI assistant or automation may do on its own, what it may do inside an approved scope, and what always waits for a person.
- AI models and tools: how to choose for the jobKnow what you are comparing across OpenAI, Claude, Gemini, Grok, Llama and Perplexity, and pick a tool for one business job with a trial plan, not a ranking.
- AI assistant, automation, agent or business software: which do you need?Tell the four categories apart by the job each one does, and pick the right one for a specific task in your business, including the case where what you already own is enough.
Sources
Dates are when each source was last checked by the editor. Sources support specific claims; they are not endorsements.
- S11Building effective agents · Anthropic · checked September 9, 2026Published 19 December 2024. Names workflow patterns such as routing, parallelization and evaluator-optimizer, and advises adding complexity only when it demonstrably improves outcomes. Used for the patterns and the simplicity advice, not for any claim about Dryvn's internals.
B02 · Published September 9, 2026 · Opinions are the author's. Vendor facts are dated and sourced above; scenarios are labelled as scenarios.
