Some goals cannot be scoped until the first worker returns

Sequential dependence is the property of a goal whose later sub-questions are determined by what an earlier piece of research turned up. It is a property of the task rather than of any system built to serve it, which is what makes it worth naming: it can be established with a whiteboard and a list of real questions, and it decides whether a fan-out design can serve those questions at all. The previous chapter's validator assumes a question set exists before dispatch. This chapter is about the goals for which that assumption is false, and about the specific way the failure disguises itself as something else.

The example this chapter works from is a run of Scout, an internal competitive-research assistant, against a question about Kestrel — a small workflow product that a competitor called Vantage had acquired fourteen months earlier. A product manager wanted to know what had happened to Kestrel and whether it still competed with anything in our line. Scout's orchestrator enumerated five sub-questions, assigned them cleanly to four subtasks, and passed every check in the validator: current Kestrel pricing, current Kestrel feature set, Kestrel's customer reception since the acquisition, and how Kestrel's positioning compares to ours. Disjoint at the question level, disjoint at the source level, budgets within caps, nothing unassigned. Three of the four workers returned nothing usable.

An ordering constraint is not sequential dependence#

The two are easy to conflate and they call for completely different responses, so the distinction is worth making before anything else.

Every decomposition has data dependencies in the trivial sense that a synthesis needs its workers' outputs. Beyond that, some goals have a genuine order. If the goal were "compare Vantage's enterprise price to ours as a percentage", you would need the Vantage figure before you could compute the ratio, so the two operations have to happen in sequence. But notice what is true of that goal anyway: both questions are perfectly writable in advance. You can write down what is Vantage's enterprise price and what is ours and what is the ratio without knowing any of the three answers. An ordering constraint is a dependency between subtask outputs, and a decomposition can express it with an edge from one node to another.

Sequential dependence in the sense that matters here is a dependency between an output and the existence of a subtask. No edge can express it, because you cannot draw an edge to a node you have not got. That is the whole difference, and it is the reason the usual remedies for ordering — a dependency graph, a topological sort, a wait — do not touch it.

The questions are the unknown, not just the answers#

The Vantage pricing goal from the previous chapters has a knowable question set. You can write down "what were the list prices", "what packaging changed", "which segments were affected", "did partner discounts change", and "how are customers reacting" without knowing a single answer, because the questions are determined by the goal alone. What the workers return fills in blanks whose shape was fixed in advance.

The Kestrel goal has a question set that is a function of an answer. Until you know the product's fate, you cannot write the list, and the lists for the different fates share almost nothing:

At planning time the orchestrator is standing at the diamond, and the consequence follows in four steps that are each worth checking separately. The orchestrator must emit scopes before any worker has run, so it must emit them before any answer exists. The question set depends on which branch is true. Any set of scopes it emits therefore either commits to one branch, which is a guess, or covers all three, which sends most of its workers to research a world that does not exist. Both outcomes are guaranteed by the structure of the goal rather than by the wording of the prompt.

The validator from the previous chapter passes both of those plans, and it is worth being precise about why, because the reflex on seeing a validator pass a bad plan is to strengthen the validator. Coverage asks whether every sub-question the orchestrator wrote down has an owner. Disjointness asks whether any of them has two. Both quantify over the question set the orchestrator produced. Neither has any access to the world the question set was supposed to describe, so neither can tell that four of the five questions were about a product that no longer exists. A plan can be perfectly conserved and entirely counterfactual.

That is the stumble this chapter exists to name. The validator's verdict is a quantity that stayed constant — it passed the Kestrel plan exactly as it passes a good one — while the property that decided the run varied underneath it, that property being whether the questions were answerable at the moment they were written. A green check is a defence against one class of defect and is silent about this one, and silence reads like approval.

Recursive delegation does not restore what the validator was checking#

One tempting response is to push the problem down: let workers spawn workers, so the pricing worker, on discovering that Kestrel was absorbed, dispatches its own children to research the absorption. Recursive delegation is a real pattern and it does make the system able to finish the Kestrel goal.

What it does not do is restore the properties the previous chapter's validator was checking, and the reason is that those properties were global. Coverage is now asserted at three levels by three different model calls, none of which can see the others' scopes, so two grandchildren in different branches can research the same thing with nothing in a position to notice. The token bill becomes a function of how deep the tree happened to go on that run, which is decided at runtime by findings nobody can predict. And a single miscarved scope near the root multiplies, because everything beneath it inherits the mistake. The Kestrel goal is not hard because the orchestrator lacked a mechanism for creating more work. It is hard because the shape of the work was unknown at the moment the design demanded it be stated.

This is the property to name in a design review when someone proposes an orchestrator for a research assistant. The requirement an orchestrator has that a sequential planner does not is the synthesis step that reconciles conflicting worker outputs, established in chapter 1. The property of a task that makes the orchestrator the wrong choice is that its later sub-questions are defined by earlier findings. Those are two different arguments, and they point in opposite directions — one is a cost the orchestrator pays, the other is a case where it cannot buy anything at all.

A test you can run before writing code#

The useful thing about sequential dependence is that it is checkable from a sample of goals with no system in place. Take thirty real questions from whatever queue the assistant is meant to serve — support requests, analyst asks, a quarter of Slack messages to the competitive-intel channel — and try to write the sub-question list for each one, by hand, without doing any research. Not the answers: only the questions.

The right-hand column is where that table teaches something, and the split in it is cleaner than the middle column suggests. Every yes row names its entities in the goal itself: pricing dimensions known from the domain, three companies listed by name, a press-release archive you can enumerate. Every no row has to discover an entity before it knows what to research: a product's fate, a reason for a loss, a set of people. The question to ask of a new goal is therefore not whether it feels complicated. It is whether the things the research is about are named in the request or found during it.

Scout's sample of thirty came out at nineteen writable and eleven not, which is a design input rather than a verdict. It says a fan-out design serves roughly two-thirds of the traffic and is structurally unable to serve the rest, and it says the eleven are not a long tail of odd requests but a recognisable class: goals that begin with what happened, why did, or who is, where the first finding names the entities the rest of the work is about. A planner–executor design handles all thirty, less efficiently on the nineteen.

The test is cheap and people skip it because the conclusion feels like it should come from measurement. It does not need to. Whether a question set can be written before the research starts is a fact about the questions, available for the cost of an afternoon with a whiteboard, and it decides the architecture more firmly than any latency number will later.

Staging is the honest hybrid, and it has a cost#

The real systems do not choose once. Anthropic's How we built our multi-agent research system describes a lead agent that thinks, dispatches subagents, reads what comes back, and then dispatches again — which is to say the decomposition is re-derived after each round rather than fixed at the start. That structure handles the Kestrel goal: round one dispatches a single worker to establish the product's fate, round two decomposes the correct branch into three or four parallel subtasks, and the fan-out happens where it is genuinely available.

def staged_run(goal: str, max_rounds: int = 3) -> Answer:
    findings: list[Finding] = []
    for _ in range(max_rounds):
        plan = plan_with_validation(goal, context=findings)
        if plan.is_terminal:
            break
        results = dispatch_all(plan.subtasks)     # parallel within a round
        findings.extend(collect(results))
    return synthesise(goal, findings)

Two costs fall out of that loop, and both are requirements of re-deriving a plan rather than choices anyone made. Every round is a serial barrier: the round cannot start until the previous round's slowest worker has finished, so the latency of a three-round run is the sum of three tail latencies rather than one. A tail latency is the slow end of the response-time distribution rather than its middle, and it is what a round actually waits on, because the round finishes only when its slowest worker does. And the orchestrator pays a planning call per round with the accumulated findings in its context, which grows with every round.

max_rounds is the decision sitting next to those requirements. It bounds how many barriers a run may pay for, and somebody chose the value.

The measured cost on Scout's own traffic was a median 2.1 rounds on the eleven sequentially dependent goals, with p95 latency of 71 seconds against 26 seconds for the single-round fan-out on the other nineteen, meaning 95 runs in every 100 finished inside those times and the remaining five took longer. It used 1.6 times the tokens of the plain sequential planner on the same eleven goals. The quality gain was, on the first evaluation, within noise — smaller than the variation you get from simply grading the same system twice, and therefore not yet distinguishable from no gain at all.

That last number is the honest limitation, and it is worth stating as a residual rather than as a disappointment. What staging licenses is applicability: the orchestrator can now finish a Kestrel goal instead of producing four workers' worth of research about a product that was discontinued. What it does not license is any claim of superiority on those goals, because the evaluation could not separate it from the sequential planner. Whether the parallelism inside each round earns back the extra planning rounds is a question that has to be settled per workload rather than assumed. The condition under which staging clearly wins is a goal whose branch, once discovered, opens into many genuinely independent sub-questions — a discovery step followed by a wide fan-out. The condition under which it clearly loses is a goal that stays narrow after the discovery, where each round dispatches one or two workers and you have paid for an orchestrator to run a sequence.

Forcing it produces the failure from the previous chapter#

There is a specific trap in going ahead anyway, which is that the symptoms show up as decomposition defects rather than as a mismatch between pattern and task. An orchestrator asked to decompose a goal whose questions it cannot yet know does not refuse. It produces a plan, because producing a plan is what it was asked to do, and the plan it produces hedges: several subtasks that circle the unknown from different angles, which is what overlapping scopes look like from the inside, plus a gap wherever the true branch lay.

The Kestrel run shows both. Three of the four scopes were near-duplicates once you know that Kestrel had been absorbed — pricing, features and positioning were all really the same question, what does Kestrel look like today, asked three times because the orchestrator had no better way to spend four subtasks. The sub-question that mattered, what happened to Kestrel's customers and whether any of them were winnable, appears nowhere.

A team that only had the duplicated-and-missing symptom in front of them would reasonably conclude that the decomposition prompt needed work, spend two weeks on it, and get slightly different duplicates. The validator, meanwhile, keeps passing these plans, because they are well-formed statements about a question set that was doomed at the moment it was written. Two chapters' worth of machinery are functioning correctly and reporting green, and the thing they are correct about is not the thing that went wrong.

Recognising the class early also changes what you build first. If a third of your traffic is sequentially dependent, the sequential path is not a fallback you add later; it is the path most of the interesting questions take, and the orchestrator is an optimisation layered on the subset where the questions are enumerable.

Suppose the task passes the test, the decomposition validates, and the workers go out. The next thing that decides whether the design is trustworthy is what the parent does when one of them does not come back, and the uncomfortable part is that the default behaviour there is not an error at all.