When to delegate vs do-it-yourself
The 4-question test before you spawn a subagent.
What a subagent is for
A subagent is a separate Claude session, spawned with its own context, that does a scoped piece of work and returns a structured report. The parent agent (or you) reads the report and acts on it.
The mental model people import from human management is “delegate as much as possible.” That model is wrong here. With humans, delegation has roughly fixed overhead — a meeting, a brief, a check-in. With subagents, the overhead scales with the brief: a clear, well-scoped task is cheap; a fuzzy, unbounded one is expensive twice (once to write the brief, once to parse the response).
The right mental model: a subagent is a parallelizable scoped contractor. It’s the right tool when you have multiple independent pieces of work that each have a clear deliverable shape, and a wrong tool when you’re trying to think out loud or explore a fuzzy question.
The cost of getting this wrong: I’ve burned $5–20 per session on dispatches that returned essays I had to re-read and re-decide. The alternative — doing the same task inline in 10 minutes for $2 — was always available. The 4-question test in this lesson is what I use now to make the call honest.
The 4-question test
Run this in your head (or as a prompt) before every dispatch. Four yes/no questions. All four must be yes for dispatch to win.
| Question | What it catches | If no |
|---|---|---|
| 1. Parallelizable? | Tasks that need each other’s output should not be a chain of subagents | Do it inline. Chains add overhead without adding parallelism. |
| 2. Shaped deliverable? | Tasks where you can’t name the return format | Sharpen the deliverable first. If you can’t name it, you’re abdicating, not delegating. |
| 3. Specialist exists? | Tasks where a specialist’s loaded context makes them cheaper than a generalist | Generalist subagent is no better than inline. Do it inline. |
| 4. Load-bearing return? | Tasks where the return drives a decision or action | This is exploration, not work. File a wiki page, not a dispatch. |
The four questions are in order of fastest-to-fail. Question 1 fails most often (people reach for subagents for serial work). Question 4 fails most expensively (operator dispatches an essay-generator and then doesn’t use the essay).
Five failure patterns
Subagent-for-everything
The unbounded brief
The serial-pretending-to-be-parallel
The lost return
The wrong specialist
Pattern #5 (wrong specialist) is the routing-layer failure. If your roster has APEX/SUMMIT/VELOCITY/AXIOM/CIPHER (per TruPath rules), match the dispatch to the specialist. Generic dispatches lose the specialist’s loaded memory and ownership rules.
The dispatch prompt
Run this against any candidate dispatch. Four questions, four pass/fail answers. All four pass = dispatch. Any fail = inline.
Before I dispatch a subagent for this task, walk the 4-question test:
1. PARALLELIZABLE? Is this task independent of other in-flight
work — no shared state, no waiting for another result? If no,
do it inline.
2. SHAPED DELIVERABLE? Can I name the return format precisely
(bulleted list, table, file paths, checklist with green/yellow/
red)? If no, the brief is unshaped — sharpen the deliverable
first.
3. SPECIALIST EXISTS? Is there a specialist whose loaded context
makes this task cheaper for them than for a generalist (CIPHER
for legal, AXIOM for QC engineering, SUMMIT for MHG)? If no,
the dispatch saves nothing — do it inline.
4. LOAD-BEARING RETURN? Will I actually use what comes back to
make a decision or take an action? If no, this is exploration
that fits in a wiki page, not a dispatch.
Output: dispatch / inline. If dispatch, name the specialist and
write the shaped brief. If inline, name the next step.Catches subagent-for-everything, unbounded briefs, fake parallelism, and exploration-pretending-to-be-work.
Use the prompt for two weeks straight, in writing. After two weeks the questions become reflex and you can run them in your head. Until then, write them down — the discipline is what builds the intuition.
Three real dispatch decisions
A real morning: three tasks across three ventures (Parley Notebook 03 plan review, QC patent audit, MHG correspondence). Two dispatches, one inline. The 4-question test makes the call.
Parley Nb 03 plan review · QC patent audit · MHG correspondence reply
- operator
I have three things on my plate this morning: (1) review the Parley Notebook 03 plan, (2) audit QC patent package readiness, (3) draft a reply to Dustin Davis about the QC R&D testing space. What gets dispatched and what do I do myself?
- agent
Walking each through the 4-question test:
(1) Parley Notebook 03 plan review. Q1 (parallelizable?): No, single artifact. Q2 (shaped deliverable?): Yes, plan-review output is structured. Q3 (specialist exists?): Yes — Parley repo has CORTEX + BEACON. Q4 (will return be load-bearing?): Yes, you'll act on it. → Dispatch. Use the Parley repo's BEACON inspection pattern. Brief: "Inspect plan file
docs/plans/active/2026-05-nb03-tuning.md. Return: gaps, risks, suggested edits — bulleted, max 200 words per section."(2) QC patent package readiness audit. Q1: No, single review. Q2: Yes, audit checklist is shaped. Q3: Yes — CIPHER (legal/IP). Q4: Load-bearing — gates Patent Week 1 attorney engagement. → Dispatch to CIPHER. Brief: "Review patent package at <path>. Confirm: (a) all 482 lines complete, (b) 36-commit evidence ledger linked, (c) sensor-pivot IP implication addressed (FSR-specific claims replaced with broader method-level fusion claim), (d) no public-disclosure risks. Return checklist with green/yellow/red per item."
(3) Dustin reply. Q1: No. Q2: Yes (an email draft). Q3: Marginal — could go to APEX or SUMMIT, but the content is short and personal. Q4: Yes. → Do it yourself. Drafting an email reply to a known contact is faster inline than dispatching. The dispatch overhead exceeds the work.
- operator
Run the two dispatches in parallel. Don't summarize the returns — pass them through verbatim.
- agent
Dispatching:
- BEACON-style inspection on Parley Nb 03 plan
- CIPHER patent-package audit on QCBoth running in parallel. Will return verbatim reports as soon as both complete. While we wait — would you like me to start drafting the Dustin reply, or do that after the returns?
- operator
Start the Dustin reply now. Three sentences. Acknowledging the testing space isn't available, asking whether the Hickory deal status is clear (Hickory is dead now per April 28 Denver pivot), close with willingness to revisit.
- agent
Drafting inline:
Dustin, Thanks for the update on the testing space. We've since decided to pivot the venue site to Denver NC, so the Hickory framework is now closed on our end as well. Happy to revisit if anything opens up Lake Norman-side that fits the equipment-testing footprint. MikeThree sentences as asked. Acknowledges the no, communicates the Denver pivot (so he's not waiting on a stale Hickory question), leaves the door open. Per CEO rules — I'm drafting only, not sending. You review and send.
Prompt kit
Three prompts: the 4-question test, the dispatch brief shaper, the verbatim-return rule. Save in your CLAUDE.md.
Before I dispatch a subagent for this task, walk the 4-question test:
1. PARALLELIZABLE? Is this task independent of other in-flight
work — no shared state, no waiting for another result? If no,
do it inline.
2. SHAPED DELIVERABLE? Can I name the return format precisely
(bulleted list, table, file paths, checklist with green/yellow/
red)? If no, the brief is unshaped — sharpen the deliverable
first.
3. SPECIALIST EXISTS? Is there a specialist whose loaded context
makes this task cheaper for them than for a generalist (CIPHER
for legal, AXIOM for QC engineering, SUMMIT for MHG)? If no,
the dispatch saves nothing — do it inline.
4. LOAD-BEARING RETURN? Will I actually use what comes back to
make a decision or take an action? If no, this is exploration
that fits in a wiki page, not a dispatch.
Output: dispatch / inline. If dispatch, name the specialist and
write the shaped brief. If inline, name the next step.Task: <describe>
Write the dispatch brief:
- Specialist: <name from your roster>
- Deliverable name: <one line>
- Format: <bulleted list / table / checklist / file paths>
- Word ceiling: <200 / 500 / 1000 — pick one>
- Sources to read: <file paths or links>
- Out of scope: <what NOT to do>
The brief should be short enough that you could give it to the
specialist in one paragraph. If it's longer than 100 words, the
task isn't shaped enough — split it or sharpen it.When the subagent returns:
- Pass the report through VERBATIM. Do not summarize.
- If the report exceeds 1000 words, flag it as oversized but still
pass through.
- Do not paraphrase, do not extract bullets, do not "TLDR." The
operator reads the actual output.
The exception: if the subagent returns an error or runs over time,
report that fact but do not invent a summary of what it might
have said.Apply this
30-minute exercise. Audit recent dispatches. Build a brief template. Run a dispatch experiment.
Calibrate your dispatch threshold
Each step takes 5–10 minutes. Progress saves automatically.
- 01List 5 tasks you did this week. For each, walk the 4-question test.Be honest about which ones should have been inline (you spent more time briefing than doing) and which should have been dispatched (you got tunnel vision on something a specialist would have shipped faster).
- 02Pick a recurring task type that you keep dispatching badly. Write a reusable brief template.Examples: "plan review" template, "patent audit" template, "site-search shortlist" template. Each template names the specialist, the deliverable shape, and the out-of-scope.
- 03Add a verbatim-return rule to your CLAUDE.md.One line: "Subagent returns are passed through verbatim — never summarized by the parent agent."
- 04Run a dispatch experiment: same task, twice. Once dispatched to a specialist, once inline.Compare: time, cost, quality of result. The intuition you build from this is the most valuable output.
- 05Audit your last 10 dispatches. How many returned something load-bearing?If less than 7, your dispatch threshold is too loose. Tighten the 4-question test until the hit rate is 70%+.