Every agent spawns a subagent the instant delegation looks possible, and almost none of them stop to ask if it’s actually worth it. This skill forces a four-question test before any subagent gets summoned, and running the test costs less than the mistake it prevents.
u/Parking-Kangaroo-63 built it after watching the same agent fail in two opposite directions inside one session. First it spun up a fresh subagent to answer something a single grep would’ve settled. Later in that same session, the poster watched it brief a different subagent way too thinly. That subagent burned three tool calls just reconstructing context the dispatcher already had sitting right there. No instinct for “is this worth delegating.” No instinct for “does this subagent need to start from zero, or can it inherit what I already know.”
That’s the key idea behind the skill: delegation is a cost-bearing decision, not a reflex. Every subagent’s output eventually lands back in the dispatcher’s context as a summary. Spawn one for a task that was already cheap, and you paid dispatch overhead for nothing. Brief a fresh agent too thinly, and it re-derives work you’d already finished, burning tool calls to catch up to where you started.
Old Way vs. New Way
The old way runs on instinct. An agent sees a task, decides in half a second whether delegating “feels right,” and moves on. There’s no consistent rule behind that call. The same kind of task gets treated differently depending on session length or how tired the reasoning has gotten by that point.
The new way runs everything through four fixed questions before a subagent ever spawns:
- Context cost: would doing this inline dump a pile of dead-weight output into the dispatcher’s context?
- Independence: can it run without the dispatcher’s step-by-step involvement?
- Reusability: does the dispatcher need the raw output, or just a distilled answer?
- Judgment value: would an unanchored read actually change the conclusion?
If neither context cost nor judgment value comes back “yes,” the task stays inline. That’s the default for anything answerable in one to three tool calls. It’s the rule that kills the reflexive-spawn habit the author kept running into.
Practical Steps 🧭
- Classify the task first. State the deliverable in one sentence. Is it something you’ll keep reasoning over, or a disposable trace where only the conclusion matters? A task still blocked on missing information isn’t a delegation candidate yet.
- Run the four-question test. Score context cost, independence, reusability, and judgment value. A “no” on both context cost and judgment value means you do it yourself.
- Pick the cheapest shape that works. A fork inherits everything the dispatcher already knows, and it’s nearly free to start. That’s the right default whenever a task only needs existing context plus new tool output. A fresh agent costs more to brief correctly, but it never leaks tool noise back into the dispatcher’s context. It earns its keep only when non-anchoring is the actual point, like an adversarial second opinion.
- Watch the tiebreaker. When a task is both context-heavy and needs an unanchored read, the instinct is to grab a fork because it’s cheaper to start. Don’t. A fork inherits the dispatcher’s own framing, which quietly defeats the reason you wanted an independent read in the first place. Fresh wins that tie.
- Use the batching exception, sparingly. A pile of individually-trivial, non-interfering edits doesn’t clear the delegation bar alone. Grouping several into one wave purely for wall-clock savings is the one case where a dispatch happens without either question firing “yes.” It only works when the tasks don’t touch the same file or resource.
- Brief a fresh agent like it has amnesia, because it does. State the goal and why it matters, name what’s already been ruled out, and draw the scope boundary. Give exact commands for a lookup, or the open question itself for an investigation. Skip any of that and the fresh agent quietly re-derives work you already threw away once.
- Verify before you trust. A subagent’s own report describes what it meant to do, not necessarily what it did. Check the diff, the file, or the command output. Don’t check the narration.
- Say the quiet part out loud. Every dispatch decision, including a decision not to delegate, gets one line stating the shape and the reason. A silent, unexplained spawn isn’t acceptable even when the shape choice was correct.
The two pieces the author didn’t expect to need until stress-testing the skill against real sessions were the batching exception and the tiebreaker. Both showed up as edge cases the four-question test didn’t cover cleanly on its own. That’s usually the sign a rule is load-bearing instead of decorative.
One commenter, u/TheQueasyEspionage, put the underlying problem bluntly. Everyone’s agent is out here spawning subagents for single greps, and the fix looks obvious only after someone names it out loud. Another, u/Future_AGI, pointed at a bigger shift this kind of work is part of. Writing a better prompt is a one-time gain, but building an eval that catches regressions is a permanent one.
If you’re running multi-agent workflows and can’t remember the last time you skipped a spawn on purpose, this one’s worth grabbing. Drop it straight into your skills folder. The full thread has the worked examples, and they cover the edge cases better than any summary can. Go check them out!
Frequently Asked Questions
Q: What is “fork bias” and when does it actually become a problem?
Fork bias is the instinct to spawn a subagent even when a simpler approach (like a single grep) would settle it. It also shows up as the opposite problem: briefing a subagent so thinly to save context that it burns multiple tool calls re-deriving information you already figured out. The real cost isn’t the spawn itself, it’s the hidden waste of spinning up context when you could’ve answered inline.
Q: How do I know if a task should stay inline versus get delegated?
Run the delegation test before spawning: (1) Context cost, would pulling the output back into your reasoning add dead weight? (2) Independence, does it need your ongoing involvement? (3) Reusability, do you need the raw output or just the final answer? (4) Judgment value, would an unanchored read actually produce a more trustworthy conclusion? If context cost and independence are both “no,” keep it inline. That’s the default.
Q: Should I focus on writing better prompts or building evaluation frameworks?
The bigger shift is moving from prompt engineering to eval engineering. A one-time prompt improvement gives you a single gain; an eval set that runs against your prompts every time they change catches regressions permanently. If you can’t measure whether a prompt change helped or hurt, you’re guessing. The prompts that survive are the ones tested against a frozen set of cases repeatedly.
Q: Why would I include context in a subagent brief that I already know?
Subagents start from zero memory of what you’ve already figured out. If you brief them too thinly, they’ll burn tool calls re-deriving information that’s sitting right in front of you. Including relevant context in the brief (even if it feels obvious) saves the subagent from wasted API calls and gives them a faster path to the answer.
Subagent Dispatch Economics skill.md
by u/Parking-Kangaroo-63 in PromptEngineering