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

  1. 01Each has a distinct jobProduce, check, classify, compare. If two models have the same job, remove one.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Sources

Dates are when each source was last checked by the editor. Sources support specific claims; they are not endorsements.

  1. 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.