In this article
Can Claude delegate work to itself? Yes — it's called a subagent. But knowing when not to use one matters more than knowing how.
What a subagent actually is
A subagent is a separate Claude conversation, spawned on your behalf, with its own tools and its own context window. The main agent gets back one message — a summary — instead of everything the subagent saw on the way to the answer.
That last part is the whole point. Subagents protect your main conversation from getting cluttered with dead ends and file fragments that don't matter once the answer's found.
The trap: delegating when you shouldn't
Subagents aren't free. Spawning one costs real tokens on top of your main conversation's tokens. It costs 30+ seconds of latency just to spin up, brief, and get a result back. And it costs a coordination tax — you have to write a prompt good enough that a subagent starting cold can actually act on it, since it can't see anything you've already discussed.
So: don't delegate "edit this one file." Don't delegate "rename this variable." Don't delegate anything you could just do.
The actual threshold: if the work involves 5 or more tool calls, and the result can be summarized in under 300 words, delegate. Otherwise, do it inline.
The three times it genuinely helps
Independent search across a lot of places. "Where is feature X implemented?" can either clutter your main conversation with grep results and dead ends, or a subagent can go do that digging and hand back: "Feature X lives in src/features/X/, entry point is index.ts:42, called from two places." Clean answer, no mess.
Truly parallel, unrelated work. Three independent prep steps — write tests, update docs, refactor a helper — can run as three subagents at once instead of one after another. The rule: only if none of them depend on another's output. The moment step two needs step one's result, you're not parallelizing anymore, you're just adding overhead.
A second, unbiased opinion. You've been staring at the same bug for an hour and you're anchored on a theory that might be wrong. A fresh subagent — "independent review, is this fix actually correct?" — didn't see your dead ends and doesn't share your bias. It catches what you've stopped seeing.
How to brief one well
Subagents start cold. Treat the prompt like a message to a smart colleague who just walked into the room — they need the goal, what to check, and a length cap, or you'll get a rambling response instead of a tight answer.
A good one:
Audit what's left before this branch can ship. Check: uncommitted changes, commits ahead of main, whether tests exist, whether the deploy gate is wired up. Report a punch list — done vs missing. Under 200 words.
A weak one just says "based on your findings, fix the bug" — that pushes the actual thinking onto the subagent instead of doing it yourself. Be specific about what you want done. Let the subagent execute, not decide.
Steal this template
Next time you're about to delegate, fill this in instead of winging it:
[Goal in one sentence]. Check: [specific thing 1], [specific thing 2], [specific thing 3]. Report [format — list, punch list, summary]. Under [word count].
Delegation instincts aren't one-size-fits-all — an Architect and a Rapid Launcher naturally over- or under-delegate in opposite directions. If you haven't taken the Builder DNA assessment yet, it's worth knowing which one you lean toward before you assume the 5-tool-calls rule above is the whole story for you. Discover your Builder DNA →
Ready to put this into action? Waymaker helps you go from idea to your first paying customer, with AI doing the heavy lifting alongside you.
Start building free
