Understand AI

How multi-model AI systems work, and when one model is enough

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

For: Owners and managers who keep hearing about AI agents and orchestration and want to know what it means for a real task.

Format: Explainer + roles worksheet
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)

One model, many hats

When you ask an assistant to draft a customer email and then ask it whether the email is any good, you are talking to the same model twice. It will usually say the draft is fine. It wrote it. That is not a character flaw; it is what happens when the checker and the writer share the same view of the problem.

A multi-model system breaks that up. It gives the drafting job to one model and the checking job to a different one, with different instructions and, ideally, different information. The checker does not know how the draft was reasoned out. It only sees the draft and the facts it is supposed to check against. When the two disagree, that is the moment a person needs to look.

Anthropic's engineering guide describes the building blocks in public terms. A workflow is a system where models and tools run through predefined steps in code. An agent is a system where the model directs its own process and tool use. The guide names patterns like prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer, and its strongest advice is to start simple and add complexity only when it demonstrably improves outcomes [S11]. Everything on this page sits inside those public patterns. It is not a description of any company's private setup, including Dryvn's.

The four roles in a small system

Roles, not brands. Any capable model can hold any role; the point is that the checker is separate from the drafter.
Role	What it is given	What it produces	What it must not do
Drafter	The task, your examples and rules, the relevant records.	A first version: an email, a summary, a classification.	Decide anything. It proposes.
Checker	The draft and the source records only, not the drafter's reasoning.	A list of specific mismatches: wrong amount, missing date, unsupported claim.	Rewrite the draft. It reports.
Challenger (optional)	The draft, the check, and a question: what would go wrong if this were sent?	Risks and missing cases the first two did not raise.	Block the work. It flags.
Person	The draft, the mismatches, the flags, and the authority to decide.	Approve, edit, or send it back with a reason.	Skip the check because the draft reads well.

A task moving through a small multi-model system · Diamonds are decisions; dashed boxes are waiting states; red dashed arrows go back or escalate.

Text version of this diagram

Task arrives (start; with records attached) → go to Drafter
Drafter (step; proposes) → go to Checker
Checker (step; compares to records) → go to Disagreement?
Disagreement? (decision; list of mismatches) → none: go to Done + evidence; yes: go to Person decides
Person decides (escalation to a person; approve / edit / return) → approve / edit: go to Done + evidence; return, once: go to Drafter
Done + evidence (end; what was sent, by whom)

Handoffs are where systems break

Each arrow in the diagram is a handoff, and a handoff between two models has the same failure modes as a handoff between two people: the receiver did not get everything it needed, the format changed, or nobody noticed the step was skipped. The workflows and loops explainer covers this for any system. For a multi-model system, three handoffs deserve special care.

Records into the drafter. If the drafter gets the wrong invoice or an old version of the contract, everything downstream checks the wrong thing beautifully. The documents and retrieval explainer covers how to keep that honest.
Draft into the checker. The checker must see the source records itself. If it only sees the draft, it can only judge whether the draft sounds right, which is the trap you were trying to escape.
Disagreement into the person. A mismatch that lands in an inbox nobody reads is the same as no check. Decide where disagreements go, who reviews them and by when. That is an exception route, the same control the handoff assessment looks for.

When one model and ordinary automation are enough

Most tasks in a small business do not need more than one model. The honest test is whether a person can check the output quickly and whether a wrong output is cheap to reverse. If both are true, one model plus a human glance is the right system, and adding a checker model is paying for a second opinion you can give yourself in thirty seconds.

Cost, delay and failure points as the system grows
Setup	Cost per task	Delay	New failure points	Fits when
Ordinary automation, no AI	Lowest	Seconds	A rule that no longer matches reality.	The task is the same every time and the inputs are clean.
One model + human check	One model call	Seconds to minutes	Confident wrong output; a tired reviewer.	Outputs are short, easy to verify, cheap to reverse.
Drafter + checker + person	Two calls plus review time	Minutes	Checker given the wrong records; disagreements nobody reads.	Wrong output is expensive: money, commitments, customer trust.
Drafter + checker + challenger + person	Three calls plus review	Longer	Too many flags; people start ignoring them.	High-stakes, infrequent decisions where missing a case costs more than the review.

Illustrative example · fictional

A small accounting firm checks month-end summaries

A fictional four-person accounting firm sends each client a plain-language month-end summary: what came in, what went out, anything unusual, and what the client needs to do. Writing thirty of these used to take a partner most of a day. They set up a small system.

The drafter gets the client's ledger totals, last month's summary and the firm's rules (never comment on tax position, always name the source report). It writes the summary. The checker gets only the draft and the ledger totals, and is asked for one thing: every number or claim in the draft that does not match the ledger, as a list. The challenger gets the draft and the check and one question: what in here would embarrass the firm if the client forwarded it to their bank? A partner reads the draft with the two lists beside it and decides.

In the first month the checker flags four summaries where the drafter rounded a figure in a way that changed the meaning, and the challenger flags one where "cash is comfortable" was not a claim the firm should make. The partner's review drops from a day to about two hours, most of it on the flagged five. The disagreement rule is written down: any mismatch on a dollar figure means the draft goes back with the correction; any challenger flag means the partner rewrites that sentence personally. This example is fictional and shows the shape of a system, not a measured result.

Deciding what happens when the models disagree

Disagreement is the product. The mistake is treating it as a problem to make go away, usually by asking the drafter to fix its own draft until the checker stops complaining. Instead, decide in advance what each kind of disagreement means and who resolves it.

01Classify the disagreementA fact mismatch (the number is wrong), a judgement mismatch (the tone is wrong), or a missing case (something neither model handled). Each gets a different route.
02Fact mismatches go back automaticallyThe draft returns to the drafter with the checker's list attached. One round only. If it fails twice, a person looks.
03Judgement mismatches go to a personNo model breaks a tie about what your business should say. Name the person and the deadline.
04Missing cases become rulesEvery time the challenger finds something new, decide whether it becomes a standing instruction for the drafter, the checker, or a human-only step.
05Keep the evidenceStore the draft, the lists and the decision together. That is how you find out, in three months, whether the checker is earning its keep.

Worksheet

Multi-model system design sheet

One row per task. If you cannot fill in the checker and the disagreement rule, you are not ready to add a second model.

Task: One task, in one sentence
Owner / model role: Who owns the outcome; which role (drafter, checker, challenger) does what
Input: Exactly what each role is given, and what it is not given
Expected output: Format and length of each role's output
Checker: What it compares against, and the list it must produce
Disagreement rule: Fact mismatch → ? Judgement mismatch → ? Missing case → ?
Human decision: Who decides, by when, and what evidence is kept

Downloads · no email required

Multi-model system design sheet
The roles and disagreement-rule worksheet as a fill-in Markdown file, with a separate fictional example.
Download .md

Questions people ask

When is using multiple AI models worthwhile?: When a wrong output is expensive or hard to reverse, when a person cannot check it quickly, and when a second model can be given the source records independently. If any of those is missing, one model and a human check is the better system.
How do you handle disagreement between AI models?: Decide the rule before you run the system. Fact mismatches go back to the drafter once; judgement mismatches go to a named person; missing cases become new rules. Never let the drafter grade its own work, and never leave disagreements in a place nobody reads.
Do the models need to be from different companies?: Not necessarily. Independence comes mostly from what each role is given and asked, not from the logo. Different providers can add independence, at the cost of managing two vendors. Choose by the job, as in choosing AI models and tools.
Is this how Dryvn works inside?: This page teaches public patterns. Dryvn's company view is that combining specialized roles, checks and human responsibility beats one agreeable chatbot, and you can read that position on the about page. How Dryvn is built inside is not described here.

What is an AI system, a workflow and a loop?Learn the difference between a system, a workflow, an automation, an agent and a feedback loop using two everyday business examples, and map one of your own on a worksheet.
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.
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 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.
BlogMore AI models do not automatically make a better systemAdding 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.

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. Supports the distinction between workflows (predefined code paths) and agents (models directing their own process), the named patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer), and the advice to add complexity only when it demonstrably improves outcomes.

R14 · Published September 9, 2026 · Next scheduled review December 9, 2026 · Teaches process management; not legal, warranty, safety or engineering advice. Examples are fictional unless stated. Part of the Dryvn resource library (17 resources).