Delegation Discipline

Delegation Discipline

Purpose

Delegation multiplies throughput and divides accountability — unless discipline restores it. A subagent is a capable worker with zero context you didn't give it and outputs that are claims, not facts until checked. The two failure poles: trusting delegated output blindly (their confabulations become your confabulations, with your confidence attached), and delegating so vaguely the work comes back plausible-but-useless. This skill is the contract layer between you and your delegates.

When to use this skill

• Before spawning any subagent, background task, or parallel worker.
• When incorporating delegated results into your own deliverable — the verification half applies even if someone else did the delegating.
• When a task exceeds one context window or one attention span: broad searches, multi-file audits, independent parallel workstreams.

When NOT to use this skill

• Two-minute lookups you can do directly — delegation overhead (writing the brief, verifying the result) exceeds the task. Delegate work, not errands.
• Judgment calls that are the actual heart of the task (the architecture decision, the final recommendation). Delegate the inputs to judgment — research, enumeration, verification — not the judgment itself.

Operating procedure

1 — Decide whether to delegate. Delegate when: work is independent and parallelizable; it's context-heavy exploration whose conclusion you need but whose details you don't; it would flood your context with material you'd only skim. Keep when: it's tightly coupled to your working state; the brief would be longer than the task; verifying the result costs more than producing it.

2 — Write the brief as a contract. A subagent knows nothing you don't tell it. The brief includes:

• Goal and why (one line of mission prevents a page of misfire).
• Inputs: exact paths, links, constraints — not "the config file" but which one.
• Deliverable shape: exactly what to return (a list of file:line findings; a table of options with tradeoffs; a yes/no with evidence). Vague deliverable specs return essays.
• Done-criteria and boundaries: what NOT to do (don't edit, don't fix, report only), scope limits, effort cap.
• The authoritative evidence layer, when the delegate judges something: which source wins on conflict (the diff over the narration, the data over the summary, the code over the report). Delegates drift toward the easiest-to-read evidence unless told which layer is truth.