How to Use Subagents in Claude Code

Long Claude Code sessions die the same way every time: the context window fills up with search results, file dumps, and dead-end exploration, and the model gets dumber right when you need it sharp. Subagents are the built-in fix — separate workers that do the messy digging in their own context and hand back only the conclusion. Here’s how to actually use them.

What a subagent actually is

A subagent is a separate agent instance that Claude Code spins up with its own context window. It gets a task, works it — reading files, grepping, reasoning — and returns a single result message to the main conversation. All the intermediate noise stays in the subagent’s context and dies with it.

That buys you three things:

• A clean main context. The subagent burns its own tokens exploring; your main conversation only receives the conclusion. Fifty file reads on its side show up as one summary on yours.
• Parallel work. Multiple subagents can run at once. Three independent questions, three workers, answered simultaneously instead of serially.
• Specialization. A custom subagent carries its own system prompt and its own tool restrictions, so it behaves like a focused specialist instead of a generalist with your whole session on its mind.

Triggering one: automatic vs explicit

You don’t have to configure anything to start. Claude decides to delegate on its own when a task looks like broad search or research — “find everywhere we handle auth” is the kind of thing it will hand to a subagent without being asked.

When you want control, ask explicitly:

use a subagent to find every place we construct SQL queries by hand

spawn an agent to research how the payment webhook flow works, then summarize it

Plain language is the interface. Say “subagent” or “spawn an agent” and describe the task; Claude handles the rest.

One thing to know about the plumbing: subagent results come back to the main agent, not directly to you. The main agent reads the result and summarizes it in its reply. You’re always talking to the coordinator, never the worker.

Building a custom subagent

The real power move is defining your own. A custom subagent is one Markdown file with YAML frontmatter, and it lives in one of two places:

• .claude/agents/ in your repo — project-level. Commit it and your whole team gets the same specialist.
• ~/.claude/agents/ — personal, available in every project you open.

Here’s a read-only code reviewer:

---
name: code-reviewer
description: Use this agent when code has just been written or modified and needs review. Checks for bugs, security issues, and convention violations before anything ships.
tools: Read, Grep, Glob
---

You are a senior code reviewer. Review the changes you're pointed at
for correctness bugs first, then security issues, then convention
violations. Be specific: file and line, what's wrong, why it matters.
Do not suggest rewrites of code that works. Report findings ranked
by severity, worst first.

Four frontmatter fields matter:

• name — kebab-case identifier.
• description — when Claude should use it. This is the routing signal; more on it below, because it’s where most subagents fail.
• tools — optional allowlist. Everything not listed is off the table.
• model — optional; pin the model this subagent runs on.

Everything below the frontmatter is the subagent’s system prompt. If you’ve read how to write a system prompt for an AI agent, all of it applies here — concrete rules, explicit output shape, no vibes.

Don’t want to hand-write the file? Run /agents inside Claude Code — it opens an interactive manager for creating and editing subagents.

The description is the routing signal — write it like a trigger

Claude reads the description field to decide when to delegate. That makes it the single most important line in the file. Write it as a trigger condition:

# Weak — Claude has no idea when to reach for this
description: A helpful agent for code quality.

# Strong — reads like a rule Claude can match against
description: Use this agent when code has just been written or modified and needs review.

“Use this agent when…” followed by concrete situations is the pattern that works. If your subagent never fires automatically, fix the description before you touch anything else.

Restrict tools — it’s a safety feature, not a nicety

The tools allowlist is what makes specialists trustworthy. A reviewer with only Read, Grep, Glob cannot accidentally edit a file, no matter how confused it gets. That’s a guarantee, not a hope.

Good candidates for the specialist treatment, each with tools scoped to the job:

• Code reviewer — read-only.
• Test runner/fixer — needs to run commands and edit test files.
• Docs writer — read plus write, no shell.
• Security auditor — read-only, again.
• Read-only explorer — for “map this codebase” jobs where you want zero chance of side effects.

One structural limit to design around: a subagent cannot spawn further subagents. Delegation goes one level deep, so the main agent is always the coordinator fanning work out — build your workflows with that shape in mind.

The honest trade-off

Subagents are not free. Each one spins up its own instance, which means added latency before you see anything, and its exploration burns tokens even though they never land in your context. For a single quick file lookup, direct search is flat-out better — don’t spawn a worker to answer a one-line grep.

The rule of thumb: delegate when the search is broad or the task is self-contained. Keep it direct when the answer is one known location away.

The token side of this is also why I care about what backend the burn happens on. I run a lot of my Claude Code sessions against the z.ai GLM Coding Plan to keep costs near zero — setup walkthrough in how to set up Claude Code with the GLM API. Full disclosure: this GLM Coding Plan link is a referral, it helps fund our compute, and it’s the same plan you’d get without it. When subagents are doing the heavy exploring, cheap tokens are what make “spawn three workers” a shrug instead of a bill.

Where this fits

Subagents are one layer of a setup that compounds. Your CLAUDE.md file sets the standing rules every agent inherits, custom slash commands turn your repeated workflows into one-liners, and subagents give those workflows parallel hands with clean contexts. The common thread in all of it is instruction quality — a subagent is only as good as the system prompt in its body. That’s the exact problem Meta-Prompt Architect exists for: turning rough intent into reusable, high-signal instructions, so the tokens your workers burn — on the GLM plan (referral link above, disclosed) or anywhere else — do real work instead of thrashing. Write the description like a trigger, scope the tools, keep the prompt concrete, and the delegation starts feeling less like a gimmick and more like a team.