Should an Agent Spawn a Subagent? A Four-Question Test
September 18, 2026
An agent should delegate only when doing the work inline would flood its context, or when an independent read would give a better answer. The Subagent Dispatch Economics skill runs a four-question test before any spawn, then chooses fork or fresh, scopes the prompt, sizes the wave, and verifies results.
What failure does this fix?
I watched an agent spawn a fresh subagent to answer something a single grep would have settled. Then I watched it brief a different fresh subagent so thinly that the subagent burned three tool calls re-deriving context the dispatcher already had.
Same session, opposite failures. The agent had no default instinct for "is this worth delegating," and when it did delegate, none for "does this subagent need to start from zero or can it inherit what I already know."
What is the delegation test?
Four questions, each scored, before any subagent is spawned.
| Question | It asks | If yes |
|---|---|---|
| Q1: Context cost | Would doing this inline pull a large volume of output into the dispatcher's context that is dead weight after the conclusion? | Favors delegation |
| Q2: Independence | Can the task finish without the dispatcher's step-by-step involvement? | Favors delegation |
| Q3: Reusability | Does the dispatcher need the raw output, or only a distilled conclusion? | Raw output favors inline or a fork; a distilled answer favors a fresh agent |
| Q4: Judgment value | Would an unanchored read produce a different, more trustworthy answer? | Favors a fresh agent even when context cost is low |
If neither Q1 nor Q4 is yes, the task stays inline. That is the default for anything answerable in a couple of tool calls. If Q1 or Q4 is yes, the skill moves on to choosing a shape.
One exception exists. Several individually trivial tasks that don't interfere with each other can be batched into one wave purely to save wall-clock time. A lone trivial task never earns a subagent on its own.
Fork or fresh agent?
Fork versus fresh is not a coin flip.
| Shape | Use it when | Cost |
|---|---|---|
| Fork (inherits full context) | The task is exploratory, needs what the dispatcher already knows, and only the conclusion matters afterward | Cheap to start. The cost is in what comes back, so keep the return summary-shaped |
| Fresh agent (zero context) | Independent judgment is the point, or the task must run in isolation | Expensive to start correctly: every fact must be in the prompt |
| Inline | The delegation test said no | Zero dispatch overhead |
Fork by default. It inherits everything for free, so re-briefing it is wasted effort and a place for the restatement to silently drop something. Choose fresh only when non-anchoring is the point: an independent second opinion, or a check for something the dispatcher might be rationalizing past.
What breaks the tie when a task is both heavy and needs an independent read?
Fresh wins. A fork can still be told to write a short report and recover most of the cost savings, but it cannot unlearn the dispatcher's framing. If the whole point of delegating is an opinion the dispatcher's beliefs haven't biased, a fork defeats the purpose even though it looks cheaper.
How do you write a prompt for an agent with no memory?
This is the classic prompt-engineering stage, buried in the middle of the procedure.
- State the goal and why, not just the action.
- Name what has already been tried and ruled out. Omit this and the fresh agent re-derives a dead approach.
- Draw the scope boundary explicitly.
- Never lean on shared memory. "Based on what we found" means nothing to an agent that wasn't there.
How big should a wave of parallel agents be?
Group only tasks that don't touch the same file or resource, and cap the wave at a reviewable size, three to five as a starting point. Every subagent's result lands back in the dispatcher's context, and a wave sized past what can be checked lowers the odds of catching a bad result among the good ones.
Two tasks touching different files can still collide. In one of the skill's worked examples, two tasks call the same rate-limited API, so they run sequentially despite touching no shared file.
How should results be handled?
A subagent's report describes what it intended to do, not necessarily what it verifiably did. Check the artifact, the diff, the file, or the command output, not the subagent's narration. And never peek at a fork's output mid-flight or narrate what it will probably find.
Every decision, including the decision not to delegate, gets a one-line dispatch note stating the shape and why, before anything is sent.
How do I install it?
- Download
subagent-dispatch-economics.md. - Save it as
.claude/skills/subagent-dispatch-economics/SKILL.mdin your project or in~/.claude/skills/. - It runs whenever an agent is about to fork, spawn a subagent, or launch a wave.
The test is a scoring procedure, not a trained router or an API call. More skills are in the GitHub repository.
FAQ
When should an agent not delegate?
When neither Q1 nor Q4 is yes: the task is cheap to keep in context and an independent read would not change the answer.
Why default to a fork?
A fork inherits everything the dispatcher already knows, so there is no re-briefing and no chance a restatement drops something.
What is the risk with fresh agents?
A prompt that assumes shared context the agent doesn't have. The fresh agent comes back with a wrong take built on missing background.
Can independent tasks still run sequentially?
Yes. Independence isn't enough if the tasks compete for the same file or external resource.
Related: Agent Prompt Architecture covers designing the prompt and tools of the agent itself. This skill was first shared on r/PromptEngineering by u/Parking-Kangaroo-63.