How I think about which AI model does which job, and why the answer is "it depends" in a way that actually means something.
There's a question I get asked, in slightly different forms, almost weekly now: which AI should I use?
Usually the person asking has tried ChatGPT for a few months, maybe Claude, maybe both, and they're confused about which is better. I never quite know how to answer the question because it's the wrong question, in roughly the way that "which member of a small business is the most valuable" is the wrong question. The right answer is: they do different jobs.
I've been building a multi-AI system for the better part of a year. It runs on a Mac mini in my studio. The orchestration is genuinely complicated under the bonnet, and I've made the architectural decisions deliberately rather than by accident, so I have opinions worth sharing.
Here is how I've staffed my AI team. Not as a template (your circumstances will differ) but as a worked example of what staffing an AI team actually means in practice.
The Senior Partner: Claude Sonnet
Sonnet is the orchestrator. It's the model that picks up a request from me, decides what kind of request it is, holds the full context of what we've been doing across multiple sessions, and either does the work itself or delegates it to a more specialist team member.
I chose Sonnet for this role specifically because it does three things well that nobody else in the team does as reliably: it proactively reaches for context (reads files, consults memory, asks clarifying questions when ambiguous) rather than confabulating from training data; it holds long sessions coherently; and it reliably quality-checks its own and others' work before presenting it as done.
Sonnet costs more per token than the other team members. That's fine. It also produces less work per token because most of what I need from it is judgment, not output. Judgment doesn't cost many tokens. A good orchestrator's job is to say "yes do that", "no don't", "ask the worker to redo this with these changes", "I'll handle this one myself". Sonnet is a great senior partner.
I tried demoting Sonnet to make the system cheaper. Put Haiku in the orchestrator role. The system fell over within a day — described in painful detail in another piece I've written. The lesson: do not staff your senior judgment role with a junior model just because the senior model is more expensive per token. The hidden costs of bad judgment vastly exceed the visible cost of paying for good judgment.
The Bounded Executor: Claude Haiku
Haiku is fast and cheap and excellent at doing things with clear specifications. "Format this list." "Write 200 words of Facebook copy for this workshop." "Check whether this matches this schema." These are not judgment tasks. They are execution tasks. Haiku does them brilliantly at a fraction of Sonnet's cost.
Haiku is also the model I use for every cron job in the system: the morning briefings, the inbox sweeps, the departure alerts. Cron work is bounded, repetitive, and time-sensitive. Sonnet would be overkill. Haiku is exactly right.
The architectural rule I've encoded into the layer stack is: all cron jobs use Haiku, no exceptions. Even one cron firing on Sonnet costs more than a full Haiku working day, and crons fire dozens of times per day. The rule is hard because the consequence of getting it wrong is significant.
The Structured Writer: GPT-4o
GPT-4o is the team's structured-output specialist. When I need a long-form piece with consistent formatting (a multi-section worksheet, a structured comparison table, a CV-style document), GPT-4o produces cleaner output more reliably than the others. Not always better output, but more reliably formatted output, which matters when something has to slot into a downstream template.
I delegate to it via a delegate_task tool that Sonnet uses when it identifies the request as a formatting-heavy task. The user (me) typically doesn't know which model handled their request unless they ask. That's the way it should be.
The Trivial-Turn Router: Gemini 2.5 Flash
This one is a router, not a worker. Turns that are five words or fewer, with no contextual depth ("yes", "go on", "thanks", "next") get automatically routed to Gemini Flash, which is nearly free per token. Sonnet doesn't see these turns at all. They don't cost what a Sonnet turn would cost.
The threshold matters. I originally had it at 28 words. That was too generous: it was catching turns that had operational meaning and routing them away from Sonnet's contextual awareness. I tightened it to 5 words. The bill dropped. The quality stayed up. The lesson: routing thresholds need to be informed by the worst case for the cheaper model, not the average case.
The Critic: a second Sonnet instance with a different prompt
This one is the team's quality-control function. When the primary Sonnet has delegated a complex task to GPT-4o or Haiku, the Critic (a second instance of Sonnet with a critic-shaped prompt) reads the worker's output, scores it against a pass/fail rubric, and either approves it for delivery to me or routes it back for a second attempt.
Most of the time the worker's output passes. When it fails, the system either tries again with a refined brief or escalates to Sonnet to do the work directly. Two attempts maximum before escalation, because three attempts at a stuck task is usually a sign the task needs to be re-scoped, not retried.
This is the most expensive part of the architecture per task. It's also the part that makes the difference between "the system gave me something" and "the system gave me something I can actually use without re-doing it".
The principle behind all of this is one I learned from running a bespoke software business decades before AI was a thing.
You don't hire one person to do everything. You build a team where each person is excellent at a specific role, you trust them to do it, you have a mechanism for catching errors before they reach the customer, and you have someone whose job is to look across the whole and make sure the right person is doing the right work at the right time.
The orchestrator-Sonnet is the manager. The workers are the specialists. The critic is the QA. The router is the receptionist. The crons are the night shift.
That's the staffing model. Most AI users don't have one yet because the tools are presented as "an AI" rather than "an AI team". The next 12 months will, I think, see this change rapidly. The people who set it up well now will have systems that work reliably, cost less than they'd expect, and produce output they trust.
The people who don't will have a single model trying to do all jobs, costing more than it should, and producing mixed results.
There's an ADHD-shaped reason this matters to me personally that I'll be unsubtle about. My brain runs constantly. Ideas arrive in tsunami waves. I cannot afford to spend cognitive energy deciding which AI handles which request: that's exactly the kind of micro-decision-fatigue that drains people like me before lunch.
Building the team architecture once, properly, means I never have to think about it again. I make a request. Sonnet handles or delegates. The right person picks it up. The output arrives. I review and ship.
This is what staffing an AI team buys you. Not just lower bills. Lower cognitive load. For some of us, that's the entire point.
How I think about the whole team is in How To Train Your AI CoPilot (£3.99, creativepath52.com), and the build-it-yourself companion, Build Your Own Multi-Lane Claude CoPilot, is coming next. Subscribe free so you don't miss it.
The AI Architecture series.
