The Best Claude Code Subagents to Set Up in 2026

Once you understand how subagents work, the next question is which ones are worth building. You don’t want fifteen half-baked agents with overlapping jobs — that makes delegation worse, not better. You want a handful of sharp ones, each with a clear job, the right tools, and a sensible model.

This is an opinionated list of the subagent patterns that earn their place in 2026. For each, three things: what the agent’s job is, which tools to scope it to, and which model tier fits. If you’re new to the concept, start with the subagents guide; to build any of these from scratch, see how to build a custom subagent.

Real subagent catalogs to browse#

Community catalogs are useful when you want examples instead of a blank file. Do not install one blindly; most are written for someone else’s stack and conventions. Read the prompt, check the tool list, and rewrite before trusting it.

Code reviewer#

The first agent most people should set up. After Claude writes or changes code, the reviewer reads the diff and flags real problems — logic bugs, unhandled errors, missing input validation, security smells — and ranks them by severity. Because it runs in its own context, the review doesn’t crowd out the main thread’s working memory.

• Tools: Read, Grep, Glob, and Bash if you want it to run a linter. No write or edit tools — a reviewer changes nothing.
• Model: mid-tier. Review needs judgment but not your most expensive model.

Test writer#

A test writer scoped to your framework and file layout turns “add tests for this” into actual coverage that matches how your project already tests things. The value is in the scoping: tell it where tests live, what runner you use, and the naming convention, and it stops guessing.

• Tools: Read, Grep, Glob, Write, Edit, and Bash to run the suite.
• Model: mid-tier, or your stronger model if the logic under test is gnarly.

This one needs write access, which makes the system prompt matter more. Be explicit that it should only create or modify test files, never touch production code.

Debugger#

When something fails, the debugger reproduces it, reads the relevant logs and code, forms a hypothesis, and proposes a fix. Keeping this in a subagent is smart because debugging generates a lot of dead-end exploration you don’t want clogging the main context.

• Tools: Read, Grep, Glob, Bash to run and reproduce. Add Edit only if you want it to apply fixes directly.
• Model: mid-tier to strong. Diagnosis is judgment-heavy.

Security auditor#

A focused pass for security issues: hardcoded secrets, injection-prone queries, missing authorization checks, unsafe deserialization, and dependencies with known problems. Separating this from the general reviewer means it can be thorough about one thing instead of skimming everything.

• Tools: Read, Grep, Glob. Strictly read-only. An auditor that edits code is a liability.
• Model: mid-tier to strong, depending on how deep you want the analysis.

Docs writer#

A docs writer keeps READMEs, API docs, and inline comments in step with the code. Point it at your docs structure and tone, and have it update documentation after a feature lands. It’s a low-stakes agent that quietly prevents the usual drift between code and docs.

• Tools: Read, Grep, Glob, Write, Edit — scoped to docs and comment changes.
• Model: cheap to mid-tier. Writing prose from existing code is not the hardest job.

Refactorer#

The refactorer makes structural changes — extracting functions, renaming across files, splitting modules — without changing behavior. This is the agent that most needs a tight leash, because it touches a lot of files. A good system prompt insists on small, verifiable steps and running the tests after each one.

• Tools: Read, Grep, Glob, Edit, Write, Bash.
• Model: strong. Behavior-preserving change at scale is exactly where a weaker model breaks things.

Context-gatherer / explorer#

The unsung hero, especially in big repos. Before any real work, this agent maps how a feature works across the codebase — which files, which functions, how they connect — and returns a focused summary. The main thread then plans against that summary instead of reading everything itself.

• Tools: Read, Grep, Glob. Read-only by design.
• Model: cheap and fast. This is high-volume reading, so it’s the single best place to save tokens by routing to an inexpensive model.

Because exploration is where so much context gets consumed, scoping this agent to a cheap model is usually the biggest cost win you can make. The trade-off is summary quality — verify it on a real task first, as covered in the subagents guide.

Honorable mentions#

A few agents that aren’t first-tier for everyone but earn their place in specific workflows:

• Migration writer. For projects with database schemas, an agent that drafts migrations from model changes and checks they’re reversible. Needs Write and Edit, mid-tier model.
• Dependency auditor. Reads your lockfile and dependency manifests, flags outdated or risky packages, and suggests upgrades. Read-only, cheap model — it’s mostly pattern matching.
• Accessibility checker. For frontend work, an agent that reviews markup for missing labels, poor contrast patterns, and keyboard traps. Read-only, mid-tier. Like the security auditor, it raises the floor but doesn’t replace real testing with assistive technology.

The pattern across all of these is the same: a single clear job, tools scoped to exactly that job, and a model that matches how much judgment the work needs.

Keep them distinct and well named#

The fastest way to ruin a good set of subagents is to let their jobs blur together. When two descriptions overlap, Claude can’t reliably tell which one fits, and delegation gets flaky. A few habits keep things clean:

Names matter more than they seem. code-reviewer, security-auditor, and test-writer tell you and Claude exactly what each does. Generic names invite overlap and make explicit invocation awkward.

A starting set#

You don’t need all seven on day one. A practical first set:

Add the debugger, security auditor, docs writer, and refactorer as the need shows up. For sysadmins running Claude Code on servers and managing these agents at the user scope across machines, see the setup for sysadmins.

Wrapping up#

The best subagent setup isn’t the biggest — it’s the one where every agent has a distinct job, the right tools, and a model that matches the work. Start with a code reviewer and a context-gatherer, scope read-only agents to read-only tools, push exploration to a cheap model, and keep your strongest model on the main thread. Build the rest as your workflow reveals the patterns.