Claude CodeClaude Code 2.1 · macOS, Linux, Windows
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
31 small wins to finish your pathNext lesson

Subagents

Some work produces a mountain of output you will never look at again. A subagent does that work somewhere else and comes back with the answer.

A subagent runs in its own context window, with its own system prompt, its own tool list and its own permissions. Your conversation never sees the fifty files it read. It sees the summary it returns.

Lesson 7 said the context window is mostly file reads and command output. This is the tool that keeps it that way.

One subagent

markdown
---
name: bug-hunter
description: Search the codebase for silent data loss, where a write can overwrite existing data without warning. Use when auditing, not when fixing.
tools: Read, Grep, Glob
model: haiku
---

You look for one thing: a write that can destroy data that is already there.

For each risk, report the file, the function, and one sentence saying how it
happens. Do not suggest fixes and do not edit anything.

The same shape as a skill and a different job. description is how Claude decides to delegate to it, tools is what it may use, and cutting that list down is a real constraint rather than a hint. This one cannot edit anything, because Edit is not in its list.

model: haiku is the other reason to reach for one. Searching does not need your most expensive model, and routing that work to a cheap one is the difference between an audit you run weekly and one you run once.

Using it

bash
> audit the project for silent data loss

Claude reads the description, hands the job to bug-hunter, and reports back what it found. Everything the subagent read on the way stays out of your conversation.

You can also call it directly by name, which is worth doing while you are still finding out whether the description is good enough to be picked on its own.

What it costs

  • It starts fresh. A subagent does not know your conversation unless it is a fork of it, so anything it needs has to be in the request or in the files.
  • You get a summary, not the work. Good when the detail is noise, bad when you wanted to read it yourself.
  • Descriptions live in your context. Every subagent's description is loaded at startup, so twenty verbose ones cost you before you type anything.
When to delegate
The test for whether something should be a subagent: would you be annoyed to scroll past its output? Searching, log reading and dependency archaeology all qualify. Writing the code you are about to review does not.
Try it yourself
  • Write a subagent that only reads, for a question you ask often.
  • Give it model: haiku and compare the answer with your usual model.

Every expert started right here.