The 10 Claude Code sub-agents we actually use to ship software in 2026
- Claude Code's
/agentscommand lets you define named sub-agents with isolated system prompts that the orchestrator can spin up mid-task — per the official docs, each agent "operates with full tool access in a separate context." - Every agent below has a single, narrow job. Narrow jobs mean cheaper runs, easier debugging, and lower token burn when one agent misbehaves.
- The full 10-agent pack — prompts, CLAUDE.md wiring, and trigger rules — is available as a $49 download. Link mid-post.
Why bother with sub-agents at all
A single Claude Code session that handles architecture, code review, test generation, documentation, and security scanning in one context window is expensive, slow, and prone to context contamination — earlier decisions bleed into later ones in ways that are hard to trace.
Sub-agents fix this by giving each concern its own context. According to Anthropic's Claude Code documentation, sub-agents are "spawned by an orchestrator and run tools independently." That independence is the point: the Reviewer agent never sees the Architect's deliberation. The Tester never sees the Debugger's half-formed hypotheses. Each agent gets a clean slate, a tight prompt, and one job.
The /agents command in Claude Code manages this. You define agents in .claude/agents/ as Markdown files. The orchestrator picks which to fire based on context, or you call them explicitly. Scope creep from an agent that was "just going to check one thing" is the main failure mode — which is why every agent below has an explicit "do not" clause in its prompt.
The 10 agents
When to fire: Before any new feature that touches more than two files. Before a refactor that crosses module boundaries. Never mid-implementation — at that point it's too late to influence structure without rewriting.
When to fire: After any commit-ready change. The Reviewer sees only the diff, not the broader codebase — this is intentional. Scope creep into unrelated files wastes its context and produces noise.
When to fire: After implementation is done, before the PR is opened. Firing Tester before the code stabilizes produces tests that get thrown away. One function, one agent invocation — don't batch five modules into one run.
When to fire: When a test fails or a production error surfaces. Separating diagnosis from fixing prevents the agent from reaching for the nearest plausible fix rather than the correct one. Read the diagnosis, then decide whether to fix it yourself or fire a second agent.
When to fire: After a function or module is merged and stable. Writing docs before the API is settled means rewriting them. Docs is the cheapest agent to run — short context, deterministic output — so it's fine to fire it on small functions.
Want all 10 agent files, pre-wired?
The Septim Agents Pack is a $49 download: 10 .md agent definition files, a CLAUDE.md orchestrator config, trigger rules, and a token-budget guide for each agent. Drop the folder into .claude/agents/ and you're running in under five minutes.
When to fire: Any time a database schema change is needed. Migrator's constraint — touch nothing outside the migration file — prevents it from "helpfully" updating ORM models or API handlers, which belong to separate review cycles.
When to fire: Before any PR that touches auth, user input handling, or external API calls. Security's value is in the report, not the fix — if it patches in the same pass, it can paper over the finding rather than surface it for review.
When to fire: When you're about to pick a dependency or third-party API and you're not certain which option fits your constraints. Researcher doesn't decide — it structures the decision so you or another agent can.
When to fire: At the start of any feature that will take more than one session. Planner's output becomes the orchestrator's task list. A feature that starts with a numbered list from Planner rarely gets scope-crept mid-session, because the boundary is visible.
When to fire: Always — run this as a PreToolUse hook on every session, not on demand. Cost Guard is the one agent that should be invisible when things are going well and loud when they aren't. Without it, a runaway multi-agent session compounds token spend before you notice the bill.
How to wire these in Claude Code
Each agent lives as a Markdown file at .claude/agents/<agent-name>.md. The file format is straightforward:
---
name: reviewer
description: Reviews code diffs for correctness and edge cases
---
Review the diff for correctness, readability, and edge cases — do not rewrite, only comment.The orchestrator (your main CLAUDE.md session) references agents by name. Per Anthropic's documentation, the orchestrator "delegates tasks to sub-agents" automatically when the description matches the context, or you can call them explicitly with /agents reviewer.
A few wiring rules that save you from the common failure modes:
- Put a hard token budget in each agent's Markdown file. An agent with no budget will use everything available.
- Give every agent a "do not" clause. Agents without explicit constraints drift toward helpfulness — which means touching things they weren't asked to touch.
- Log agent outputs to a file, not just the terminal. When a session crashes, the terminal is gone. The file isn't.
What this setup costs per working session
Running all 10 agents across a full feature build — architecture through security review — costs roughly 80,000–140,000 tokens on a medium-complexity feature with Claude Sonnet. At current API rates that's approximately $0.40–$0.70 per feature cycle. The variance comes almost entirely from how tightly the individual agent prompts are scoped. A Tester with a vague prompt that decides to also check adjacent modules can triple its token usage on a single run.
The Agents Pack includes a per-agent token budget recommendation based on what we've seen in production. Cost Guard enforces it.
The one thing most sub-agent setups get wrong
Most developers build agents that can do anything the orchestrator can do, then wonder why the orchestrator isn't actually delegating. The fix is counterintuitive: make each agent less capable, not more. An agent that can only read files and report findings will be called for exactly that. An agent with full tool access gets treated as a backup orchestrator, which means it handles things it shouldn't, consumes more context, and produces noisier output.
Narrow tools get used precisely. Wide tools get used hopefully. Every agent above has one job, stated in a single sentence.
Need a custom team built for your codebase?
If your repo has constraints that don't fit a generic pack — specific frameworks, compliance requirements, a monorepo with unusual patterns — we'll build a custom agent team for your stack. One working session, we design and wire the agents together, and you get the files at the end.
Further reading
- Claude Code invisible token burn (April 2026) — what happens when agents run without a Cost Guard hook.
- The Tokenocalypse: why your Claude sub-agents burned $47K — real numbers from a multi-agent session gone wrong.
- Anthropic: Claude Code sub-agents documentation — the canonical reference for the
/agentscommand and agent file format.