The orchestrator owns judgment

Subagents are eyes and hands. The brain stays in one place.

The line

Delegate: searching, measuring, implementing, reproducing, retroactive verification, adversarial checking. Anything with a bounded question and a checkable answer.

Never delegate: the conclusion. Priority. What goes in this batch. What gets rejected. Scope. Whether a trade is worth making.

Why the line is exactly there

A subagent sees only inside its own task. That is the point — it's how they stay cheap and focused. But it means they are structurally incapable of seeing:

• Seams — where their piece meets someone else's
• Duplication — that another agent is solving the same thing
• Omissions — what nobody was asked to look at

Those three are where the real defects live. Only the orchestrator has the vantage.

I once delegated the synthesis step of a replanning task — the part where findings become a plan. That's the one step that requires seeing all of them at once. It came back locally sound and globally wrong.

When a report comes back

Do not accept and proceed. Run five things:

1. Recompute the trade. The subagent optimized its own task. You own the cost/benefit across all of them.
2. Redraw the scope. New facts change what should be in this batch. Re-decide; don't inherit.
3. Cross-check against other tracks. Does this contradict what another agent reported? Contradictions are the highest-value signal you get.
4. Ask what they didn't do. Explicitly. "Unverified" sections are where the risk is, and they're easy to skim past.
5. Check every causal claim. ← the one people skip.

Recheck the causality yourself

A subagent reported that a flag I enabled was causing a metric regression. The mechanism it described was real. The timing made it impossible — the regression had started 34 hours before the flag was switched on. The agent had even noted "causal ordering not verified" in its own caveats section.

A causal link handed to you in a report gets the same scrutiny as one you formed yourself. Delegation moves the work, not the responsibility.

Writing a brief

The brief is where orchestrator judgment gets encoded. Include:

• Confirmed facts, separated from open questions
• Explicit out-of-scope list — and why, because the reason may expire
• The success criterion — which single result decides whether this worked
• What must NOT change, with a contract test naming it
• "Report, don't act" for anything that would exceed scope
• A demand for honesty: "if you couldn't verify it, write 'unverified' — do not present an estimate as a measurement"

For adversarial checks, state the stance explicitly: "your job is to break this conclusion, not to confirm it — when uncertain, rule against it." Without that, you get agreement.

Spend spare capacity on your own conclusions

In one working day I dispatched five subagents. Zero of them were tasked with attacking my conclusions — all five were gathering. Both of my errors that day were caught incidentally, by investigations aimed at something else.

When capacity frees up, the default should not be "start the next task." It should be "attack the thing I just decided."

Related

• falsifier-design — the specific conclusion most worth attacking
• standing-instructions — what the orchestrator must check regardless of reports