Subagents and Delegation

Watch a capable agent work on a big task and you'll see its context window fill up with the residue of exploration: twenty files it skimmed, three web pages it read for one fact each, a test log it scrolled through. By the time it needs to make the important decision, the important information is buried. The agent gets slower, more expensive, and noticeably worse.

Subagents fix this. Your main agent hands a self-contained chunk of work to a helper with a fresh context, and gets back only a short report. In this lesson you'll build a delegate_task tool that lets your agent spawn subagents on its own, learn to write briefs that subagents can actually act on, and see how the same idea appears in Claude Code and the Claude Agent SDK.

What a subagent is#

A subagent is an agent loop started by another agent, usually through a tool call. It has three defining traits:

1. A fresh context. It starts with nothing but its own system prompt and the brief it was given. It hasn't seen the main conversation.
2. Its own configuration. It can have different tools, a different model, and tighter limits than its parent.
3. A condensed return. When it finishes, only its final report flows back to the parent. All the reading, the dead ends, and the raw tool output stay in the subagent's context and are discarded.

That third trait is the reason subagents exist. A subagent can read 30,000 tokens of source files and return a 300-token summary. The parent pays for the reading once, through the subagent, and then carries only the summary forward on every later turn.

Compared with the orchestrator–worker pattern, the difference is who's in charge. There, your code decided to plan, dispatch, and synthesize. Here, the main agent stays in control and decides for itself when delegation is worth it, the way a senior engineer decides when to hand something to a colleague.