The default assumption when you wire up an LLM-powered workflow is that every step should use the same model. Whichever model is "best for the task" handles the task. It's a clean mental model and it's wrong for almost every multi-step workflow I run.
The pattern I've landed on instead: a cheaper, faster model handles the bulk of the writing, the one that produces the artifact. A more expensive, more capable model handles a separate role, reviewing, second-guessing, deciding whether the artifact is actually good. The executor produces. The advisor critiques. They never share a context.
I call this the advisor principle. It looks obvious in hindsight. It took me longer than I'd like to admit to start using it.
The shape of the pattern
In a typical workflow, a coding agent, an analysis pipeline, a research synthesis, the work splits naturally into two kinds of cognitive load. There's the load of producing something: writing code, drafting an analysis, summarizing a document. And there's the load of judging something: did this code introduce a bug, does this analysis follow from the data, did this summary miss the point.
Production benefits from speed and volume. You want lots of tokens, generated fast, at low cost. You don't need every line to be the smartest possible line. You need a coherent, mostly-correct draft, and you need it within a few seconds so the agent stays responsive.
Judgment benefits from depth and skepticism. You want the model to read what was produced and ask "is this actually right." This kind of cognition does not benefit from speed. It benefits from the model being good at noticing what's missing.
These are different jobs. Sending the same model to do both is paying for depth on the production phase, where it's wasted, and paying for speed on the judgment phase, where it actively works against you.
How I wire it up in practice
For agentic coding work, my default is something like this. The build-side agent runs on a fast, mid-tier model. It reads the spec, writes the code, runs the tests, iterates on failures. It produces a candidate change.
Before the change ships, a separate agent, fresh context, no history of the production work, runs on the more capable model. It reads the diff and the spec and the surrounding code. It asks one question: would I approve this change. It comments on what's wrong, what's missing, what assumptions look fragile. It does not edit code.
If the advisor approves, the change ships. If the advisor flags issues, the executor goes back and fixes them, usually without escalating to the advisor model itself. Most of the time the executor already had the capacity to fix the issue; what it lacked was the perspective to notice the issue existed.
The split context matters more than the model split. An advisor that has watched the executor produce the code is not really an advisor. It's complicit in the production. It has already made some of the same assumptions. It will defend them. A fresh context is what makes the critique honest.
The cost picture
For a representative coding workflow, a small feature, say, with one or two commits and a handful of test cases, the breakdown looks roughly like:
| Stage | Model | Tokens (rough) | Cost share |
|---|---|---|---|
| Production | Mid-tier | Most | ~70% |
| Advisor review | Top-tier | Less | ~25% |
| Touch-ups | Mid-tier | Small | ~5% |
If I had run the whole thing on the top-tier model, which was my default for too long, the cost would have been roughly three times higher, the latency on the production phase would have made the agent painful to work with, and the quality of the final output would have been only marginally better.
If I had run the whole thing on the mid-tier model, the cost would have been lower but I would have shipped more subtle bugs, the kind that a more skeptical reviewer catches but a tired same-model reviewer rubber-stamps.
The mix wins on every axis that matters.
When the executor should also be the top tier
There are exceptions. The advisor principle is about workflows where the production work is mechanical enough that depth is wasted on it. Some work isn't.
Architectural decisions, choosing between two patterns, designing a schema, picking a library, are not mechanical production. The first pass needs to be deep. For these I let the executor be the top-tier model and skip the advisor step entirely, because the cognition I'd want from an advisor is the cognition I need on the first pass.
Security-sensitive code is the other exception. The cost of a subtle vulnerability that a mid-tier model misses is high enough that I'd rather pay for depth on the production phase and accept that the advisor step is now mostly belt-and-suspenders.
Most code is neither of these. Most code is plumbing.
Failure modes
Two failure modes I've watched myself drift into. Both worth naming.
The first, the advisor gets ignored. The advisor flags something, the executor disagrees, the developer (me) sides with the executor without really thinking about it because the executor is in the active conversation and the advisor is a separate process I have to mentally context-switch to read. The fix is to make the advisor's output unavoidable. If the advisor says no, the change does not ship without a human acknowledgement of why the advisor is wrong.
The second, the advisor and the executor end up sharing context anyway. This happens when I get lazy about spawning a fresh agent for the review and instead just ask the executor to "review its own work." The output looks like a review. It isn't a review. It's the same model reasoning about its own work, which is the cognitive equivalent of grading your own exam. The advisor must have no prior context. If it does, you don't have an advisor. You have a producer pretending.
The broader pattern
The principle generalizes beyond code. In any workflow where you produce an artifact and then need to decide if the artifact is good, the production step and the judgment step are different jobs and should be assigned to different agents with different cost profiles.
It's a small idea. The reason it took me this long to adopt is that it requires admitting that the default, one model, one pipeline, was already wasteful. Most of us paid for that default for a year before the alternative got obvious.
The original framing I learned from is documented in vendor research on advisor patterns. The concrete cost numbers in the table above are from my own workflows and will be out of date by the time you read this.