Routing rules: which tier gets which task

Last week I spent a whole post admitting the unit I'd been pricing everything in was shakier than I'd let on. The rankings survived — a worker tier is cheaper than an architect tier, and that's true however you count — but the false precision didn't. If you read it and thought fine, but then how do I actually decide anything?, this post is the answer. It's the least philosophical entry in the series and the most useful: a routing cheat-sheet you can copy.

Because here's the thing the token argument clears the ground for. Once you stop chasing the single best model, and stop pretending you can price the decision to three decimal places, the real skill comes into focus. It was never "which model is best." It's which task goes where.

The reframe: it's a dispatch problem

I spent the first few posts describing a three-tier stack — an architect tier for judgement, an orchestrator for decomposition and coordination, worker models for volume — as if the interesting question were the models. It isn't. The models are commodities that get better every quarter. The durable skill is running the dispatch: looking at an incoming task and knowing, quickly and without agonising, which tier should own it.

Managing a three-tier stack is closer to running an on-call rota than to picking a favourite tool. You're not asking "who's the strongest engineer" for every ticket. You're asking "what does this ticket need, and who's the cheapest person who can safely do it." Most tickets don't need your principal engineer. Some absolutely do, and handing them to a junior is how you pay in rework. Routing is that judgement, made fast and made consistently.

So the question this post answers is narrow and practical: given a task, how do I route it — without a spreadsheet, without overthinking, in about five seconds?

The three signals I route on

I've tried elaborate rubrics. They don't survive contact with a real backlog — you won't run a twelve-factor scoring model on a Tuesday afternoon. What survives is a small set of signals you can hold in your head. I route on three.

Signal 1 — Ambiguity and judgement. How fuzzy is the intent, and how much genuine judgement does resolving it require? A task like "figure out whether we should build this at all, and if so, how the pieces fit" is nearly all judgement — that's the architect tier's whole reason to exist. A task like "add this field to that form, matching the existing pattern" has almost no ambiguity; the judgement was already made. High judgement routes up; low judgement routes down.

Signal 2 — Blast radius and reversibility. If the model gets this wrong, how expensive is the mistake, and how easily can you undo it? A schema migration, a security boundary, a public API contract — high blast radius, hard to reverse. Those earn a higher tier even when the task itself looks small, because the cost of a wrong call dwarfs the cost of the call. A throwaway script, a draft, an internal one-off — low blast radius, trivially reversible. Route those down and don't feel guilty about it.

Signal 3 — Volume and parallelism. How many near-identical units of work is this, and can they run in parallel? Fifty test stubs, a batch of boilerplate CRUD endpoints, mechanical refactors across forty files — that's worker-tier work by definition. The architect tier adds nothing to the fiftieth stub that it didn't add to the first, and you'd pay a fortune for the privilege. High volume of similar work routes to the workers, coordinated by the orchestrator.

Notice these can pull against each other, and that's the point. A small task (looks like a worker job) with high blast radius (routes up) is exactly the case people get wrong — the one-line change to auth logic. When signals conflict, blast radius wins. Route on the cost of being wrong, not the size of the task.

The routing table

Here's the cheat-sheet itself — the part worth screenshotting. Task class on the left, the tier I route it to, and the one-line reason. It's not exhaustive; it's the eighty percent you hit every week.

That last row matters as much as the rest. Part of routing well is knowing when not to route at all — a lesson I learned the expensive way and wrote up in the overkill retrospective. The stack is a tool, not a toll booth.

Where routing goes wrong

Two failure modes, mirror images of each other, and both cost you.

Over-routing is sending a trivial task up-tier because the architect tier is right there and it feels responsible to use it. This is the overengineering tax: you pay architect-tier cost and latency to rename a variable. It's seductive because nothing visibly breaks — the output is fine, it's just wildly overpriced. The tell is that you can't say what judgement the higher tier actually contributed. If the answer is "none, but it did it well," you over-routed.

Under-routing is the opposite and worse: handing a judgement call to a worker because it looked small. The worker does exactly what you asked, confidently, and misses the structural implication you didn't spell out — because spelling it out was the judgement, and that's what you skipped. You don't pay for this at dispatch time. You pay for it two days later in rework, which is the most expensive tokens you'll ever spend.

The cheap heuristic that catches both: before you route down, ask what's the cost if this is wrong? If it's "I re-run it," route down freely. If it's "I unpick a decision that's now load-bearing," route up. Again — the cost of being wrong, not the size of the task.

Routing is where quality gets designed in

One last turn, because it's where this thread is heading. Routing isn't only about who does the work. It's about who checks it — and that's a routing decision people skip entirely.

If a worker produces code and the same worker reviews it, you haven't added a check; you've added a rubber stamp. Same-tier review is a blind spot, because the reviewer shares the exact failure modes of the author. Good routing sends the review across tiers, or at least across contexts — the check has to come from somewhere that doesn't share the author's assumptions. Where that gate sits, and who staffs it, is a routing question as much as the original work was.

That's the ground the forthcoming book chapter on "Quality at Machine Speed" stands on: quality isn't a stage you bolt on at the end, it's a property of how you route — including how you route the checking. This post is about routing the work. The harder half is routing the scrutiny, and that's the one the chapter takes apart.

The short version

Stop asking which model is best. Ask which task goes where. Route on three signals — ambiguity, blast radius, volume — and when they conflict, let blast radius win. Send bulk low-judgement work down, send high-consequence judgement up, and skip the stack entirely for the trivial and reversible. Then route the review across tiers, not within one. That's the whole cheat-sheet. Copy it, argue with it, make it yours.

If you're testing Fable 5 / Opus 5 too, where did it land for you? And the routing-specific version: what's the task class you most often route wrong — and did you catch it at dispatch, or in the rework?

Diagram 1: the routing decision flow — task in, one of four destinations out. Diagram 2: the copyable routing table — task class → tier → why.

Series: Post 1 — Fable 5 talks to machines better than to people · Show me the receipts · Show, don't tell · Why I took the architect tier out · The RPIQ loop · Where the stack was overkill · BowSmith case study · I lost my favourite tool · Opus Max as architect · Fable 5 came back · CAST26: open season as a quality gate · Opus 5: the middle ground I chose · Is the token even the right unit of account?