Turn count is a proxy for nothing in particular

Meridian Freight wrote the rule down in an engineering doc in February: any task the agent estimates will take more than about ten turns gets delegated to a subagent. It was a good-faith attempt to make a judgement call routine, it was easy to explain, and everybody followed it. By August the median time to first useful output across their agent fleet had gone from 8 seconds to 21, spend was up 60% against a 20% increase in tickets handled, and an incident review in July had traced a corrupted migration to a child with write access acting on a schema snapshot the parent had taken eleven minutes earlier, before applying a different migration in the meantime. When the platform lead asked which of the roughly 340 delegations a week were actually helping, nobody could answer, because nothing was measured.

The instinct in that room was to tune the rule: raise the threshold to twenty turns, and require read-only grants unless a delegation explicitly asks otherwise. The second half of that is right and belongs in the defaults. The first half preserves the mistake.

The rule measures the wrong variable#

Turn count is a measure of conversational length. The thing delegation addresses is the volume of material sitting in the window competing with the objective, and those two quantities are close to uncorrelated in practice.

Meridian's own logs make the point without argument. Their shipment-status flow runs 24 turns on a busy ticket, and the tool calls in it are status lookups returning 40 to 120 tokens each, so the whole conversation including the system prompt sits around 9,000 tokens at the end. Under the rule, every one of those got delegated, paying an extra inference and a brief to isolate material that was never crowding anything. In the other direction, their log-triage task is five turns: fetch a bundle, read it, correlate, conclude, answer. The bundle is a gzipped day of structured logs for one service, around 90,000 tokens expanded, and the model's accuracy on the fourth turn is visibly worse than on a small bundle. That task never met the threshold and was never delegated.

Raising the threshold to twenty removes some of the first category and none of the second, so the rule keeps delegating tasks with no context problem and keeps failing to delegate the one that has a severe one. The bigger cost is that the change feels like a resolution, and a team that has just tuned a number does not revisit the question for another six months.

There is a second defect that survives any threshold, which is that the rule is evaluated before the task runs. Turn count is only known afterwards, so what the parent is actually doing is estimating, and that estimate is a model judgement with no calibration and no feedback loop — nobody ever compares the predicted twelve turns against the eight it took. A rule whose input is an unvalidated guess is not more objective than the judgement it replaced; it has moved the judgement somewhere nobody looks at it.

If you want a threshold rule, the honest version thresholds on something you can read at the moment of the decision. Current window occupancy is one: delegate a bulk-reading step when the parent's window is already above, say, 40% full, and read inline when it is at 5%. Expected tool output size is another, since a Read of a file whose size you can stat gives you the number in advance. Both are crude and both measure the variable the delegation is about, which puts them a category above turn count.

Where the handoff costs more than the isolation saves#

The clearest loss condition is when the parent must re-check everything the child returns. At that point the parent reads the child's sources, the bulk enters the window anyway, and you have paid for the child's tokens, the child's latency and the brief on top of an inline read. The delegation has become a prologue.

That happens for three distinguishable reasons, and only one of them is fixable by changing the contract. Sometimes the result is unverifiable in shape — a narrative summary with no identifiers — and returning references fixes it. Sometimes the task's output is the work itself, as with a refactor whose diff the parent has to read line by line before accepting, in which case there is no compressed form and the delegation was never going to save anything. And sometimes nobody trusts the child for reasons of policy rather than shape, which is common where money or customer-visible actions are involved and is a legitimate constraint rather than a bug; the answer there is to keep the action in the parent and delegate only the analysis behind it.

Several other costs sit under the same heading. A delegation is serialised unless you fan out, so the parent waits. It adds a second time-to-first-token, which is the bulk of the 12-second figures that show up in these comparisons. It costs a brief and a result parse. And it introduces a failure class the inline version does not have: an inline loop that gets confused leaves its confusion in the transcript where a human or a later turn can see it, whereas a child returns a confident, well-formed, wrong answer in 800 tokens with its working discarded. Meridian's July incident is the sharper version of the same thing — a stale brief is a failure that can only exist because a boundary was introduced, since an inline loop reads the schema at the moment it needs it.

Finding out which ones earn their keep#

You cannot replay-test 340 delegations a week, and you do not need to, because most of them can be judged from logs that cost nothing to collect. Instrument the boundary and record five numbers per delegation.

The compression ratio settles a large fraction of cases without an experiment. A delegation whose child consumes 4,000 tokens and returns 1,800 has a ratio of 2.2 and cannot be saving meaningful context, so it can be deleted on the arithmetic alone; Meridian found 14 of their 31 definitions sat below 3. The re-read flag settles most of the rest, because a delegation where the parent subsequently opens the child's sources in more than a small fraction of runs is one where the handoff is losing, whatever the ratio says. Those two columns took an afternoon to add and removed eleven definitions.

What survives that filter gets ranked by frequency times cost, and the top three or four go through the replay harness from the previous chapter. Meridian ran four and kept two. The point of the funnel is that measurement effort is spent in inverse proportion to how obvious the answer is, which is what makes the question tractable at 340 a week.

Two further signals are worth logging even though they do not directly answer the keep-or-kill question. Contract violations per definition — malformed results, budget overruns — tell you where a definition is fighting the model rather than directing it. And time-to-first-token for the child, separated from its generation time, tells you how much of the added latency is fixed overhead that no amount of narrowing the task will remove.

What replaces the rule#

Delegation goes back to being an exception that gets justified, with inline as the default, and the justification is a conjunction rather than a threshold. All four of these have to hold.

The bulk-to-conclusion ratio has to be large and estimable in advance. You have to be able to say, before running anything, that the input is tens of thousands of tokens and the answer is hundreds, usually because you know what file or endpoint is involved.

A contract has to exist that makes the result checkable without re-reading the input. If you cannot write the shape — references, identifiers, file and line — the parent will end up re-reading, and the delegation loses by the mechanism above.

No deterministic alternative has to answer it. This is where the first chapter's yq one-liner keeps coming back, and it is worth writing the extractor for ten minutes before conceding that the question needs judgement.

The parent has to have something to put in a brief, and the grant the child needs has to be narrow. An empty established-facts section means the task depends on nothing the parent discovered, which usually points back to the previous condition. A grant that needs writes or credentials is not disqualifying, and it does raise the bar on the other three, because the cost of a stale brief scales with what the child is allowed to do about it.

None of this makes the decision automatic, and pretending otherwise is how the ten-turn rule happened. The unsolved part is real: there is no reliable pre-hoc estimator of context pressure, meaning no way to know before the task runs how much of the window its material will end up occupying and how much of that will compete with the objective, so the best available inputs are window occupancy, known input sizes, and the accumulated evidence from your own replay results about which task shapes have helped before. That last one is the asset that compounds, and it is the argument for keeping the instrumentation on permanently rather than running it as a one-off audit.

Where to go from here is mostly a matter of building one and watching it. Pick a single task that passes all four conditions, write the definition with its tool grant and its default output shape, write one brief by hand, log the five numbers, and run it for a week before adding a second. The published examples are useful for calibrating scope rather than for copying — the write-up on ten custom subagents built for a 500K-line Clojure codebase is worth reading for how small each one's job is, and the Claude Code documentation on creating custom subagents is the reference for the definition format itself. The habit that matters is the one this topic has been circling: every delegation is a claim that a boundary is worth its handoff, and the claim is checkable.