A level pays when routing a branch has become a full task

The previous chapters priced a delegation boundary from every side that costs money or reliability: an extra inference call, an extra restatement of the premise, an extra place a constraint can be paraphrased, and an extra hop that the tracing may not reach. What none of them gave is the positive condition — the thing that has to be true before a level is worth those costs. A design review with no such condition falls back on preference, and preference in these reviews reliably takes the form of an argument about specialisation.

The condition can now be stated as a threshold, because both sides of the trade are numbers. The case that makes it concrete is the brief service's infrastructure branch, which had three companies in it when the tree was built and two quarters later has nineteen, because infrastructure is where the competitive set grew and adding a company to an existing branch is a one-line change to a list. The sector supervisor that owns that branch writes nineteen delegation briefs per run and reconciles nineteen returns into one summary.

The condition, stated as a threshold rather than a preference#

Inserting a level between a parent and its workers earns its extra inference when routing and reconciling one branch is itself a full task the parent is measurably failing at. Every clause in that sentence is doing work, and the sentence is useless without all of them.

One branch — the condition is local. A tree can justify a level under its widest branch while every other branch stays flat, and the common mistake is to treat depth as a property of the tree rather than of a branch.

A full task — enough work that an agent given only that work would be fully occupied by it. The test is not whether the parent has a lot to do in total; it is whether one of its branches, on its own, would fill an agent.

Measurably failing at — you owe a number, taken before the change. And the number is a defect rate rather than a worker count, which is the substantive part of the condition and the part most often dropped.

It is worth being concrete about why routing becomes hard at all, because the mechanism is not obvious and the chapter rests on it. A parent does not write its children's briefs one at a time in separate calls. It writes all of them in a single inference call, as one generation, so the care available for the job is divided across however many briefs the call has to produce. Each individual brief stays easy — naming three companies and repeating a three-item constraint list is not a hard piece of writing. What changes with the count is how much attention any one of them receives inside a generation that has to produce all of them. So the probability that some constraint is dropped from some brief rises with the number of briefs, even though no single brief ever became difficult. That is the shape to expect: a defect rate that stays near zero while a branch is small, and then moves quickly, rather than a task that gradually gets harder.

The reason it has to be a defect rate follows from what a supervisor does. A supervisor performs no research. It does two things: it hands work down without losing anything on the way, and it puts what comes back together without dropping any of it. So the evidence that a parent has stopped being able to supervise a branch is evidence that one of those two operations has started to fail — constraints going missing on the way down, or companies going missing on the way up. A worker count is at best a predictor of when that will happen, and the relationship between the count and the failure is a property of your task rather than a constant.

Three measurements taken from artefacts the tree already produces#

All three are computable from records the tree emits anyway, which matters because a condition that requires new instrumentation will be argued about instead of measured.

Dispatch fidelity asks whether the constraints and scope the parent received survive into the briefs it emits. It is deterministic, and it takes ten lines, because the constraint list is already a list rather than a paragraph.

def dispatch_defects(parent: DelegationBrief, children: list[DelegationBrief]) -> list[str]:
    defects = []
    for child in children:
        missing = set(parent.constraints) - set(child.constraints)
        if missing:
            defects.append(f"{child.boundary_id}: dropped {sorted(missing)}")
        if not set(child.scope) <= set(parent.scope):
            defects.append(f"{child.boundary_id}: out of scope "
                           f"{sorted(set(child.scope) - set(parent.scope))}")
    covered = {c for child in children for c in child.scope}
    if covered != set(parent.scope):
        defects.append(f"coverage gap: {sorted(set(parent.scope) - covered)}")
    return defects

Three set operations carry the whole check. A constraint the parent held and a child does not is a set difference. A child claiming something outside the parent's scope is a failed subset test. A company in the parent's scope that no child covers is a set difference the other way. None of them needs a model, and none of them can be wrong about a case it was not designed for, which is what makes the resulting rate arguable-with rather than arguable-about.

Constraints are compared by identity here, and that is a design decision with a consequence. It works only because constraints travel as list elements rather than as sentences a supervisor restates. A supervisor that paraphrases a constraint into its own words has already destroyed the property this check depends on, and the fix for that is to make constraints data rather than prose — not to build a fuzzy comparison that would forgive the paraphrase and hide the loosening.

One detail of how that rate is sampled matters when a branch has grown, and it is easy to get wrong. The number of briefs a run produces is the branch width, so a fixed number of runs yields a different number of briefs at different sizes: five runs of a nineteen-company branch give 95 briefs, while reaching 190 briefs at the old three-company size took many more runs. Comparing 11 of 95 against 2 of 190 is comparing two rates, and it is only fair because both are per-brief. Comparing raw counts across the two sizes, or holding the run count fixed and comparing counts, would report the branch as improving while it degraded.

Reconciliation fidelity asks whether what the parent sends up accounts for everything that came back to it. The contract check from chapter 3 already does most of this: a sector summary whose companies array does not match scope is a violation. What sampling adds is the first-attempt rate, which is the honest one. A supervisor that gets it right on its third attempt is telling you the task sits at the edge of what it can do in one pass, and a rate computed after retries hides exactly that.

Attention share asks what fraction of the parent's context at reconciliation time is one branch's raw material. It is the weakest of the three, because it is a proxy for difficulty rather than a measure of failure. It is also the earliest warning, and the two facts are connected: it rises smoothly as the branch grows, while the two defect rates sit near zero and then move quickly. A smooth signal that leads a step change is worth having precisely because you cannot schedule work off a step change.

Thresholds on these are workload-specific and should be set from your own baseline rather than copied. On this tree the team set them at a dispatch defect rate above 5%, or any in-scope omission in the last twenty runs, sustained across two consecutive weeks. The sustained clause is what keeps a single bad week from buying a permanent level.

Everything cheaper, tried first#

The measurements say a branch is failing. They do not say a level is the fix, and three cheaper interventions address the same symptoms without adding a boundary, a restatement of the premise, or a hop chapter 6's tracing cannot see.

Read that diagram as a ladder of increasing cost rather than as a classification. Each rung is more expensive and more permanent than the one above it, and a level is the bottom rung because it is the only one that changes the shape of the tree.

The first branch resolves most cases. A parent that enumerates its own children's scopes from a theme will produce overlap and gaps at nineteen companies for exactly the reasons chapter 2 laid out, and moving the enumeration into the orchestrator's partition function fixes the coverage-gap defects without touching topology at all.

The second addresses attention share directly, and the arithmetic is the argument. A worker that returns 4,200 tokens of extracted prose costs its parent nineteen times that at reconciliation time, since the parent holds every worker's return at once while it writes. A worker that returns eight structured claims costs about 600 tokens instead. Tightening the return contract therefore removes the parent's context problem without a summarisation layer being inserted to solve it — which is worth dwelling on, because inserting that layer is what a supervisor is, and this rung obtains the same relief without the boundary.

That rung is also what the attention-share proxy is measuring, which is why the two belong together. When 78% of a parent's context at reconciliation time is raw worker material, the raw material is the compressible part, and the contract is what compresses it. Attention share falling after a contract change is therefore the expected result rather than a pleasant surprise, and a branch whose attention share does not fall after that change is a branch whose context is filled by something else — which is a different problem, and not one a level fixes.

The third is the one teams skip because it looks like it does not scale. Rebalancing nineteen companies across three sibling sector supervisors under the same orchestrator is breadth rather than depth. It costs three extra briefs at the root and no additional restatement of the premise, and by chapter 6's accounting breadth is the cheap direction and depth the expensive one. Skipping it is how a wide branch becomes a deep tree.

Which design you build first, and what would change your mind#

Return to the two designs from chapter 1 — the flat orchestrator with six workers, and the two-level tree with sector supervisors over them — and the answer is now derivable rather than tasteful. Build the flat one. It has six boundaries instead of eight, one restatement of the premise instead of two, and a critical path chapter 6's tracing can attribute end to end. Every quality argument made for the tree at six companies is a system-prompt argument the flat design can absorb for nothing.

What would have to appear in the results before adding the middle layer is the same three measurements, taken on the running flat system. Dispatch fidelity below threshold on the orchestrator's own briefs, sustained rather than spiked, meaning it is dropping constraints or mis-scoping as it writes six briefs — which at six is unlikely and at twenty is not. In-scope omissions in the final brief that survive the return-contract check. And attention share high enough that the orchestrator is writing the brief with more raw material in front of it than it can weigh, which shows up as claims that appear in worker output and not in the brief.

There is a fourth condition, and it is prospective rather than measured. If the competitive set is going from six to sixty over the next two quarters, the level you will need is worth designing for at eighteen rather than retrofitting at sixty — as long as the trigger stays the measurement and not the roadmap slide. A growth curve justifies preparing for a level. It does not justify having one.

Worker counts, specialisation, and a premise from above#

The condition rules out worker-count rules, which is the shape this heuristic usually takes in a design doc. "More than eight workers means add a supervisor" is wrong in both directions. A branch of twelve trivially-scoped workers with a two-constraint brief will route cleanly forever, and a branch of five workers whose briefs each carry a dozen interacting constraints can fail dispatch fidelity at five. The count predicts the defect rate loosely, and the relationship between them is a property of your task rather than a number to carry between systems.

It rules out specialisation as a justification, which is where chapter 1 started and where design reviews still tend to land. The segment supervisors that went into the infrastructure branch are the same model as their parent with a system prompt that names six companies. If naming those six companies is what improved things, the parent could have named them in its own briefs at no cost whatsoever. What improved things is that the count of briefs any single agent writes per run fell from nineteen to seven — a property of the arrangement rather than of any agent's expertise, and the reason the defect rate moved is that writing seven careful briefs in one call is a smaller job than writing nineteen.

That identity is worth holding on to, along with its price. The improvement is purchased by the fall from nineteen to seven, and it costs three extra inference calls, about $0.21 per run, 4.1 seconds at p95, and one more restatement of the premise on every path. The last of those is not on the invoice and is the one chapter 4 measured.

Finally, the condition rules out inserting a level in response to a quality problem whose origin is above the parent. If a run is failing because the top-level task framing was ambiguous — chapter 4's correlated q, the share of runs carrying a defect at the top that no downstream diligence can repair — a new level makes it worse, because the ambiguous premise now gets paraphrased one more time before it reaches the work. The measured shared-origin rate rose from 2.5% to 5.5% for exactly one such level on this workload. The empirical taxonomy in Why Do Multi-Agent LLM Systems Fail? is worth reading on this point: a large share of multi-agent failures are specification and inter-agent alignment problems rather than capability problems, and those are the ones that grow with each delegation layer rather than shrinking.

The comparative treatments of supervisor, hierarchical and network topologies — a network topology being one where agents hand work to each other directly, with no parent standing between them — in LangChain's Conceptual Guide: Multi Agent Architectures are a useful cross-check here. They make plain that the hierarchical arrangement is one point on a spectrum rather than the destination, and that most systems described as hierarchies are a supervisor with wide fan-out.

That is the case for adding a level: a local branch, a defect rate measured after the cheap fixes, and a price paid in calls, seconds and restatements. The situation most engineers actually inherit is the opposite one — a level that is already there, that nobody measured before adding, and that may never have met this condition at all. Deleting it is a cheap experiment to run and a surprisingly easy one to get wrong, because the evidence that comes back looks conclusive and is measuring the wrong population.