A ladder of executors: cheap first, escalate only with a reason

🪜 The idea

Without a rule, work drifts to the most capable executor because that is the one people trust. It is also the most expensive and the slowest. A ladder replaces habit with a rule: each class of task has an entry level and a ceiling, and the choice is made by code, not by a model.

Our levels are four. Level zero is no model at all: a linter, a script, a database query. Level one is a low-cost model for volume. Level two is a mid-level model for harder single tasks. Level three is a senior arbiter for the rare decision.

🔑 Escalation needs a reason

A step above the entry level is allowed only with one of five reason codes: a deterministic check failed, two junior runs disagree, the task is an architecture decision, the task touches the money path, or the operator asked. Any other reason is refused. "Just in case" is not on the list, because that is exactly how the expensive executor ends up doing everything.

Two details matter. Where a task is a pure check, a failed check is a fact, not a reason to call a senior: the script said no, so fix the cause. (A junior's work that fails a deterministic check is a different case, and it is one of the five listed reasons.) And the reason goes into the trace of the call, so the ledger can say not only what an escalation cost but why it happened.

📏 Ceilings from measurement

Per-call cost ceilings are not guesses. We read the highest observed cost per call from thirty days of traces and set the ceiling at twice that for level one and four times for levels two and three. A ceiling is a runaway detector, not a price list: it catches a loop long before it becomes a bill.

🔬 What the ledger shows

Our metered transport records the level and the escalation reason of each call. On 3 November 2026, 21:53 UTC it held 10,062 rows at level one costing $15.76 in total, and 32 rows at level three costing $0.38. Level two had 0 rows. 54 rows carry no level; all of them fall inside three minutes on 22 September 2026. Only 18 rows carry an escalation reason, all "operator request", and they sit on level-one rows. None of the 32 level-three rows carries a reason.

That is a gap in our own practice, found while writing this page. The rule says a senior call needs a coded reason, and the ledger shows senior calls with none. We have not yet traced whether those calls bypassed the router or were logged before the field was enforced, and we will not guess here. The lesson is to check your own log against your own rule.

📉 The kill rule

We decided in advance what would end the ladder. We count the share of level-two and level-three calls that changed the result. If it stays under twenty percent for sixty days, the ladder collapses to two levels. The senior calls then are not paying for themselves. We have not yet collected enough escalations to apply the rule, and we say so.

🛠️ Practice: write your own ladder

1. List your task classes, for example check a file, summarise a ticket, review a design.
2. For each class pick the entry level and the ceiling level. Put level zero first wherever a script can decide.
3. Write the closed list of escalation reasons. Keep it under six.
4. Make the router refuse any escalation without a listed reason and write the reason to the call trace.
5. Set per-call cost ceilings from the highest cost you have actually seen.
6. Choose a kill rule and a date before you start.

✅ Check yourself

• Ask for a senior call with no reason. The router refuses.
• You can list last week's escalations and the reason for each. If a senior call has no reason, you know why.
• A failed linter run does not trigger a model call.
• You can state the share of senior calls that changed the result, or you say that you cannot yet.

🚧 When this does NOT work

• Too few escalations. A rule about "share that changed the result" needs a sample. With so few logged reasons it is only a trend.
• Reasons that become habit. If every call says "architecture decision", the list is decoration. Review the reasons monthly.
• Hard tasks that start hard. Some classes should enter at a high level. Say so in the config.
• Cheap level doing damage. A low-cost model on a task that needs judgement saves little and costs trust.
• A ladder without a ledger. If you do not log level and reason, you cannot learn anything from it.

📊 Evidence

➡️ Next

Count the cost of the levels in Costs, budgets and limits, and see what the routing control changes in Models and routing.

Sources

• Costs, budgets and limits: budgets per task.
• Models and routing: what routing changes.
• Splitting work across agents, and when not to: swarms.
• AI judging: why “it says it is done” is not acceptance: acceptance by checks.