When you build a custom agent, one of the setup choices is which AI model powers it. The picker shows several options grouped by relative cost, and the instinct is to choose the most capable one on the grounds that better is better.
That instinct is usually wrong, and expensively so. The right way to choose is by the shape of the job rather than by the name on the box — which has the useful side effect of giving you a rule that survives the next generation of models.
Why not just always pick the strongest model?
Because you pay for capability whether or not the task uses it, on every single run.
The cost difference between tiers is substantial, and agent work is repetitive by design — an agent triaging forty requests a day runs forty times a day, every day. A tier decision you make once quietly multiplies out across thousands of invocations.
There is a second reason, less obvious: stronger models are generally slower. For an agent that comments in a live thread while someone is waiting, the difference between two seconds and twenty is the difference between useful and abandoned. Nobody waits for a teammate that takes twenty seconds to answer a simple question.
And the quality gain is not uniform. On genuinely easy tasks — reformatting, extracting a field, writing a one-line summary — the tiers produce near-identical output. You are paying a premium for a difference you cannot see.
What job shapes map to a cheap, fast model?
Anything where the correct output is largely determined by the input, and the agent is transforming rather than deciding.
Use the cheapest tier that produces acceptable results for:
- Reformatting and extraction — pulling a date, a name, or a product area out of prose
- Short summaries where the source is already well-organised
- Classification into obvious categories — ones a new hire could learn in a day
- Tidying — fixing a description, normalising phrasing, filling an obvious blank
- Anything that runs at high volume and gets reviewed anyway
The common property: a reader can verify correctness at a glance, and the space of reasonable answers is narrow. Where those hold, the expensive model's extra capability has nowhere to show up. A support triage agent is the archetype — high volume, short output, reviewed by a human, and perfectly well served by the bottom tier.
What job shapes justify the expensive tier?
Work where the agent has to hold several things in mind at once and reach a conclusion that is not implied by any single one of them.
Reserve the strongest tier for:
- Synthesis across many sources — reading a long thread plus related items and producing a coherent picture
- Judgment calls with real consequences — anything where a subtly wrong answer would be acted upon
- Drafting that will be read externally, where tone and nuance matter
- Ambiguous input that requires working out what someone meant before doing anything
- Multi-step work where an early mistake compounds through everything that follows
That last one deserves emphasis. On single-step tasks a weaker model's occasional error is a single visible error. On multi-step work, an early misreading propagates, and you get a confidently wrong result with plausible-looking reasoning behind it. Capability buys you more than average quality there — it buys you fewer compounding failures.
How should you actually decide, in practice?
Start one tier below where instinct puts you, and upgrade only when you can point at a specific failure.
The procedure:
- Pick a mid or low tier model when you build the agent.
- Run it on ten pieces of real work.
- Read the output and ask: are the misses caused by reasoning, or by instructions?
- If the persona was ambiguous, fix the persona — a better model will not fix an unclear job description.
- If the persona is precise and the output is still wrong in ways that require more thinking, upgrade one tier and rerun the same ten.
Step 3 is where most of the value is. A great deal of disappointing agent output traces back to an underspecified persona rather than an underpowered model, and upgrading the model in that situation costs more and fixes nothing. Fix the instructions first; it is free.
Test the same inputs on both
When you do compare tiers, run the identical set of real items through each and read them side by side. Comparing a cheap model on Monday's requests with an expensive one on Tuesday's tells you nothing, because the requests differ more than the models do.
If you cannot tell the outputs apart, keep the cheap one. That is a real result, not a failure to detect a difference.
Does the choice have to be permanent?
No, and treating it as reversible removes most of the anxiety from the decision. The model behind an agent can be changed later without rebuilding the agent, rewriting the persona, or touching anything on your board. Its identity, scope and history all stay as they are.
This is why starting cheap is low-risk. The downside of guessing low is a week of slightly weaker output on work you were reviewing anyway. The downside of guessing high is a bill you do not notice until it has run for a quarter.
And the cheapest model of all is no model: if the job turns out to be a fixed rule, an automation does it instantly and for nothing.
What about model names — which specific one should you pick?
Deliberately not answered here, because any specific recommendation would be stale within months. The names in the picker change, the tiers get faster and cheaper, and today's premium model is next year's default.
What does not change is the mapping from job shape to tier. Transformation and classification sit at the bottom. Synthesis and judgment sit at the top. Anchor your decision to that, check the current picker for which model occupies each tier, and you will not have to relearn this every time the industry ships something new.
The short version
Match the tier to the job, not to your ambition for the agent. Start one tier lower than instinct. Fix the persona before you upgrade the model. Compare tiers on identical inputs, and keep the cheap one when you cannot tell the difference.
Start free and pick the model after you have written the job description — in that order.