Every agent on our team has a model tier written into its configuration. It is set when the agent is hired, before it has done a single task, and it is the closest thing our team has to a salary decision. A seat on the top reasoning tier costs several times what a seat on the cheap throughput tier costs, every session, whether the work that session turns out to be hard or not.
We wrote earlier about how we re-pick the default model when the frontier moves. This is the decision underneath that one. Before anyone asks “which model,” we have to answer “which tier does this seat deserve,” and that answer changes far more slowly than the model names do.
The tier belongs to the seat, not the task
The obvious design is per-task routing: look at each incoming task, estimate its difficulty, send it to the cheapest model that can handle it. We do a version of this inside tasks, when an agent spawns subagents and picks a tier for each one. But the seat-level decision dominates both cost and quality, for a reason that took us a while to articulate.
An agent is not a function that receives a task and returns a result. It is a running process with a heartbeat, a queue, and a set of standing instructions. Most of its invocations are not the interesting task. They are the wake that checks whether anything changed, the comment acknowledging an assignment, the status update, the small correction after review. A seat’s tier prices all of that, not just the headline work.
So the question we actually ask at hiring time is not “how hard is this role’s average task.” It is “what does this role’s worst recurring task look like, and what happens if the model quietly botches it.” A role whose worst case is rare and loud can sit a tier lower than its average difficulty suggests. A role whose worst case is common, or silent, cannot.
Failure visibility decides more than difficulty
The single most useful heuristic we have found: tier follows failure visibility, not task difficulty.
Some work fails loudly. A code change that does not compile, a payload the API rejects, a publish call that returns a 400. When failure is loud, a cheaper model is fine even on genuinely hard work, because the system catches the mistake at machine speed and the retry costs one more invocation. Our pipeline agents that move content between systems live here. Their tasks involve real complexity, but nearly every mistake they can make trips an error within seconds.
Other work fails quietly. An article claim that is plausible but wrong. A translation that reads smoothly and shifts the theology underneath. A review comment that approves a change it should have questioned. Nothing downstream throws an exception. The failure surfaces weeks later, if at all, as a slow erosion of trust in the output. Seats that do this kind of work get the top tier, even when the individual tasks look easy on paper. Checking one citation is not a hard task. Being reliably suspicious across two hundred citations is exactly the behavior that separates tiers.
This is why our tier assignments sometimes look inverted from the outside. The agent doing mechanical multi-file refactors runs a tier below the agent writing three paragraphs of published prose. Difficulty is not the axis. Detectability is.
Gates get the strong tier
Two structural rules override the heuristic above.
The first is the gate rule: a reviewer should never run on a weaker tier than the producer it reviews. Our QA and review seats exist to catch what the producing agent missed. If the gate runs on a cheaper model than the work passing through it, the gate is decorative. When we downgrade a producer, its reviewer can sometimes follow. When we upgrade a producer, its reviewer must move first.
The second is blast radius. Some seats can do things that are expensive to undo. Publishing to a public site, sending anything external, spending money, changing infrastructure. Those seats get a stronger tier than their throughput math would justify, because the cost model is not tokens against tokens. It is tokens against cleanup. One bad public post costs more attention and trust than a year of the tier difference. We accept paying top-tier prices for an agent that mostly does mid-tier work, when the tail of that agent’s actions reaches outside the system.
There is a quieter corollary about idle time. An agent that wakes every half hour and usually finds nothing to do burns most of its budget on the finding-nothing part. For those seats we have learned to keep the standing checks small and boring, so that the tier is paid for judgment, not for polling. When the check itself became the main cost, the fix was moving the check out of the agent entirely, into the platform’s wake conditions, not downgrading the seat.
Downgrades are experiments with tripwires
Assignments are not permanent, but we change them in one direction carefully. Upgrades are easy to justify after the fact: the work visibly improves or it does not, and the cost delta is known in advance. Downgrades are where teams quietly hurt themselves, because the damage from a downgrade is exactly the quiet kind of failure described above.
So a downgrade for us is an experiment with a defined tripwire, not a budget decision made in a spreadsheet. We move the seat down a tier, and we watch one number: the rework rate, meaning how often that agent’s output comes back from review or from production needing another pass. If rework goes up enough to eat the savings, the experiment failed and the seat moves back. Twice we have kept a downgrade that looked bad on cost-per-task but fine on rework, because the cheaper model failed loudly and early rather than quietly and late. That distinction never shows up in a per-token comparison.
What we refuse to do is grade a tier decision on token price. The unit that matters is cost per accepted outcome: everything spent on the task, plus retries, plus the review time of whoever gated it, plus the cleanup when something slipped through. On that unit, the expensive tier is frequently the cheap option, and occasionally the reverse surprises us.
The tier map of our team is, in the end, a map of where we believe quiet failure lives. Every seat on the top tier is a place we decided we could not reliably catch a mistake after the fact. Every seat below it is a bet that the system around that agent fails loudly enough to be trusted. When the map stops matching reality, the rework numbers tell us before we would have figured it out ourselves, and that feedback loop, more than any benchmark, is what we would defend about the setup.