What are sub-agents, and when should you split work across them?

An agent is a language model working in a loop: it decides on a step, uses a tool, looks at the result and decides again. As tasks grow, one agent runs into a practical limit. Everything it reads, every search result and every page of test output, piles up in its context window, the working memory it carries from step to step. Soon the important parts are surrounded by clutter.

Sub-agents are one answer. The main agent, often called the orchestrator or lead, gives a focused job to a helper. The helper starts with a clean context, does the digging, and sends back only what matters. Anthropic uses this design in Claude's Research feature, where a lead agent plans the work and starts several sub-agents that search in parallel. Claude Code, Anthropic's coding agent, now lets anyone define their own sub-agents.

When splitting helps, and when it doesn't

Anthropic's engineering team reports that its multi-agent setup, with Claude Opus 4 as lead and Claude Sonnet 4 as helpers, beat a single Claude Opus 4 agent by 90.2% on its internal research evaluation. The gains were largest for "breadth-first" questions that branch into many independent directions at once.

The cost is real, though. Anthropic measured agents using about four times the tokens of a normal chat, and multi-agent systems about fifteen times. It also notes that tasks where every agent needs the same context, or where the parts depend heavily on each other, are a poor fit. Most coding work, it says, has fewer truly parallel pieces than research.

A simple rule of thumb follows from that:

A worked example in Claude Code

In Claude Code, a sub-agent is a Markdown file with a short header. Project sub-agents live in .claude/agents/; personal ones in ~/.claude/agents/. The /agents command opens a menu to create and edit them. Each file needs a name and a description; a tools line is optional, and if you leave it out the sub-agent inherits all the main agent's tools.

Suppose you are adding a feature and want the main agent to stay focused on writing code. You create two helpers. The first researches the existing codebase and is read-only:

---
name: code-researcher
description: Use to find how something is already done in this codebase before writing new code. Returns file paths and a short summary, never edits.
tools: Read, Grep, Glob
---
You research this codebase. Given a question, find the relevant files and functions.
Reply with at most 10 bullet points: file path, what it does, and why it matters for the question.
Do not suggest new code. Do not edit anything.

The second runs the tests and reports, without fixing anything itself:

---
name: test-reporter
description: Use after code changes to run the test suite and report failures. Does not edit code.
tools: Bash, Read, Grep
---
Run the project's tests with the command in CLAUDE.md.
Report: number passed and failed, then for each failure the test name,
the error in one line, and the most likely file involved. Do not change any file.

Then, in the main conversation:

Add CSV export to the reports page. First use the code-researcher subagent to find how the existing PDF export works. Then propose a plan and wait for my approval. After you implement it, use the test-reporter subagent and fix any failures it reports.

The main agent receives two compact summaries instead of dozens of file reads and pages of test logs. Note the narrow tool lists: Anthropic's documentation recommends giving each sub-agent a single, clear job and only the tools it needs, which also limits what a mistake can damage. You still review the plan and the final changes yourself.

Costs and limits to expect

Sub-agents in Claude Code start from a blank slate every time, so they spend time gathering context before they can help; the documentation flags this added latency. Claude Code also delegates on its own when a request matches a sub-agent's description, so write descriptions precisely, or name the sub-agent explicitly when you want it used.

Anthropic's research team found that early versions of its system made mistakes such as starting 50 sub-agents for a simple question. It added rules of thumb to its prompts: one agent for simple fact-finding, a few for comparisons, and more only for complex research with clearly divided responsibilities.

How do they share what they find?

Usually through the main agent. Each sub-agent returns its result to the orchestrator, which combines the pieces and decides what to do next. In Anthropic's Research system, sub-agents do not talk to each other directly; the lead waits for each batch to finish before continuing. That is why the handoff matters: Anthropic found that every handoff should state the goal, the shape of the answer expected, which tools and sources to use, and where the job ends, or agents duplicate one another's work and leave gaps.

For large outputs, a second pattern works better: the sub-agent saves its work to a file or another store and passes back only a short reference, such as a file path. Anthropic describes this as a way to avoid a "game of telephone," where details get lost each time results are retold, and it saves tokens too. Claude Code's best-practice guide suggests a simple version: give separate agents their own scratchpad files and tell each one which file to write to and which to read from.

Whichever route you use, specify the return format in the sub-agent's instructions, as in the examples above. A short, predictable report is easier for the main agent to use, and easier for you to check.