One Claude is fast. Several are faster.
Claude Code can delegate work to other Claude instances — smaller agents that run in isolation, do focused work, and return only the result. You get a cleaner main conversation, tighter tool control, and the ability to run tasks in parallel.
There are two modes: subagents work within your current session and return a summary to the parent. Agent teams coordinate across separate sessions for long-running, parallel work that would exceed any single context window.
Spawn specialized Claude instances to handle focused tasks — each runs in its own context, returns only what the parent needs, and disappears.
A subagent is like sending an intern to research something. You get the summary, not their browser history. Agent teams are like hiring a full crew — each person owns a lane, coordinates through shared tools, and reports back independently.
Built-in subagents you already have
Claude Code ships with Explore (fast, read-only codebase search), Plan (research for plan mode), and General-purpose (full tool access for complex tasks). These run automatically when Claude decides to delegate — no setup required.
The core distinction: session vs. cross-session
The decision between subagents and agent teams comes down to one question: does the work fit in a single session, or does it need sustained parallelism across many?
Why not just use one long conversation?
Verbose tool output floods your main context with noise you won't reference again. A subagent absorbs that noise and hands back only the result. For teams, some tasks genuinely require more context than any single session holds.
Nesting is blocked by design. A subagent in plan mode that needs to research your codebase delegates to the built-in Plan subagent — but that's the floor. No deeper nesting.
When to use which
The right tool depends on session scope, parallelism needs, and whether the work is independent enough to delegate cleanly.
Use when the task produces logs, search results, or file contents you won't need in your main conversation.
Use when you want to limit what the agent can do — read-only analysis, no write access, specific MCP servers only.
Define once in .claude/agents/, check into version control, share with your team. Use across every project.
Use when work splits into independent lanes — separate failing tests, separate files, separate features — that can run simultaneously without blocking each other.
Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to enable the SendMessage tool, which lets agents coordinate across sessions. The feature is in research preview.
Create a custom subagent
Subagents are Markdown files with YAML frontmatter. The fastest path is /agents — but you can also write the file directly.
Opens the subagent interface. Switch to the Library tab, select Create new agent, then choose Personal (user-level, all projects) or Project (current codebase only).
Required: name (lowercase, hyphens) and description (when Claude should delegate here). Optional: tools, model, permissionMode, color, isolation, maxTurns.
The Markdown body becomes the agent's only system prompt — it does not inherit the full Claude Code prompt. Be specific about what the agent should do and how to return results.
Omitting tools inherits everything. Specify tools: Read, Glob, Grep to restrict to read-only. Add disallowedTools to block specific tools from an inherited set.
Project agents live in .claude/agents/. User agents in ~/.claude/agents/. Restart or run /agents to load immediately. Then: 'Use the code-reviewer agent on this file.'
Pass --agents '{"name": {...}}' when launching Claude Code to define session-only agents without saving to disk. Useful for automation scripts or one-off testing.
16 agents, one C compiler, $20k
Anthropic's research team set out to build a Rust-based C compiler from scratch — capable of compiling the Linux kernel — using only a team of parallel Claude instances.
Task-locking was simple: if two agents tried to claim the same task, git conflicts forced one to pick a different one.
At 80% test pass rate, each agent picked a different failing test. When a monolithic task (compiling all of Linux) blocked progress, GCC was used as an oracle — agents fixed one file at a time.
Once the compiler worked, specialized agents handled documentation, code deduplication, and performance optimization — parallelism enabled roles, not just speed.
The project also hit a ceiling: agents couldn't implement a 16-bit x86 code generator within the size limit — GCC handled that component.
Agent teams are not faster Claude — they are more Claude, running simultaneously. The constraint is task design: work must be divisible into independent, verifiable units. Where it is, the scale of what's achievable changes entirely.