Claude Code Subagents: 3 Patterns That Actually Earn Their Keep

The first time I read about Claude Code subagents, the pitch was basically: "install a hundred specialists and you'll be unstoppable."

I tried that. I had agents I never called, named after job titles I didn't have. Most of them just sat there. The ones I actually use — the ones that genuinely change the quality of my work — are a much smaller set, and the trick isn't which ones I have. It's how I dispatch them.

So this post isn't a "click here, install 100 agents" guide. It's the three patterns I keep coming back to. If you use Claude Code at all, one of these will probably stick.

Quick Refresher: What a Subagent Actually Is

A subagent is just a separate Claude session, with its own system prompt, tool permissions, and context window, that the main session can dispatch a task to. You give it a job, it does the job in isolation, it returns a report. The main session keeps coordinating.

The interesting property — and the reason these patterns work — is that each subagent has a fresh context. It doesn't see your conversation history. It only sees what you give it in the dispatch prompt. So you can use the same model in three different "headspaces" at the same time, and they won't contaminate each other.

That's the lever. Everything below is about pulling it intelligently.

Pattern 1 — Structured Dispatch (Decisions by Mini-Panel)

This is the one I use most often, and it's the opposite of "delegate to one expert and trust the answer."

When I need to make a judgment call where the framing matters — not just the facts — I dispatch 3 to 5 subagents in parallel, each with a different prior, and then have them debate.

When I use it

Reviewing a blog post for AdSense policy risk
Deciding whether a piece of trading logic is overfit
Picking between two architectural directions where neither is obviously wrong
Anything where I suspect a single agent will just agree with itself

How the prompt actually looks

For an AdSense policy review, I dispatched three agents in parallel from the main session, each with a different stance baked into its system prompt:

Agent A — Conservative risk-averse reviewer. "Assume Google's reviewers will read this in the worst possible light. Flag anything that could plausibly be misread as policy violation, even if the literal reading is fine."

Agent B — Content-value preservationist. "Your job is to protect the post's substance. Push back on flags that would gut the post's actual usefulness. Distinguish between real policy issues and over-cautious paranoia."

Agent C — Strict policy textualist. "Read the AdSense policy literally. Don't speculate about reviewer mood. Only flag things that violate the actual written rules."

Round 1: each one returns its findings independently. The main session puts the three reports side-by-side.

Round 2: I only re-dispatch on the items that diverge. "A flagged this paragraph, B says it's fine, C didn't mention it. Each of you, respond to the other two." Now they're arguing with each other's actual reasoning, not with a strawman.

Round 3 is usually unnecessary. By round 2 you can see whether one position is collapsing or whether there's a genuine tradeoff. The main session writes the final call.

Why this beats one "smart" agent

A single agent flatters its own first instinct. Three agents with different priors force the disagreements out into the open, where you can actually look at them. It's the difference between asking one friend "is this a good idea?" and getting three friends with different temperaments in the same room.

This isn't a roster of specialists. It's a 3-person panel, briefed on opposing priors, on demand.

When you should not do this

The question has a single objectively correct answer ("does this regex match?", "is this SQL syntactically valid?"). Three perspectives on a fact is just three copies of the same answer with extra steps.
You're early in exploration and don't yet know which axes the disagreement should run on. Pick the priors after you've thought about the framing, not before.
The cost of the panel exceeds the cost of just being wrong and iterating. Not every decision deserves a panel.

Pattern 2 — Mandatory Review Gates (Autonomous Work, Forced Second Opinion)

This is the pattern that makes autonomous workflows actually trustworthy.

When I run Claude Code in semi-autonomous mode — long sessions where it implements task after task without me babysitting each step — the failure mode isn't bad code. It's the implementer agent declaring "done" when it isn't done. It writes the feature, runs the tests it wrote, sees green, moves on. Three tasks later you realize task one didn't actually meet the spec.

So I make the workflow itself enforce a second opinion. After every task, before the next task can start, two reviewer subagents must explicitly approve.

The two gates

SPEC_OK reviewer. Reads only the spec and the diff. Its single job: does the diff actually do what the spec said? Not "is the code good", just "is the spec satisfied". Returns SPEC_OK: true or SPEC_OK: false with reasoning.
QUALITY_OK reviewer. Reads the diff and the surrounding code. Checks for the failure modes the implementer is structurally blind to: tests that test the implementation instead of the behavior, error paths that swallow exceptions, edge cases the spec implied but didn't enumerate. Returns QUALITY_OK: true or QUALITY_OK: false.

If either returns false, the workflow does not advance. The implementer gets the reviewer's reasoning back and has to either fix it or argue against it. If it argues, the reviewer gets one more round. If they still disagree, control bubbles up to me.

Why dispatch this instead of just adding "also review your work" to the implementer

Because the implementer is the one who just wrote the bug. Asking the same context to grade itself is the whole problem. The reviewer subagents start from a clean context — they didn't go through the reasoning that produced the bug, so they're not invested in that reasoning being correct. They just see the artifact.

Same model. Different context. Different conclusions. That's the entire trick.

When you should not do this

One-off scripts you're going to throw away in an hour. The gate is overhead.
Exploratory spikes where "is this even the right direction?" matters more than "is this right?". Reviewers will dutifully approve a well-built thing in the wrong direction.
Tasks where the spec genuinely is "I'll know it when I see it." If you can't write the spec down, SPEC_OK has nothing to check.

Pattern 3 — Workload Partition (Same Agent, Many Slices, In Parallel)

The first two patterns are about different perspectives. This one is about same perspective, more throughput.

When I have a big analysis job that's embarrassingly parallel — same kind of check, applied to a lot of items — I split the items into groups and dispatch the same specialist subagent to each group simultaneously.

The case that made this click for me

I had 47 blog posts and a question: which ones have AdSense policy risk?

The naive approach is to feed all 47 to one agent. That agent runs out of attention budget around post 15, starts pattern-matching instead of reading carefully, and the posts at the end get a weaker review than the posts at the beginning. I've watched this happen.

The partition approach:

Group the 47 posts by series (VIBE.LOG, VORA B.LOG, PK·SWIFT B.LOG, etc.) — three groups, roughly balanced.
Dispatch one adsense-reviewer subagent per group, in parallel. Each one only sees ~15 posts. Each one has a clean, focused context.
The main session waits for all three to return, then does a meta-pass: "are the standards consistent across groups? are there cross-group patterns?"

Three groups, three contexts, three reports. Then one synthesis. The total wall-clock time is about the same as one big agent, but the per-post review quality is dramatically better, because no single agent's attention got diluted.

How the dispatch prompt looks

To each adsense-reviewer subagent: "Here are the posts in [series name]. For each post, evaluate against [explicit checklist]. Return a table: post slug, risk level (none / low / medium / high), specific concerns, suggested fix. Do not speculate beyond the checklist."

Identical prompt, three different post lists. The main session glues the three tables together, looks for inconsistencies, and re-dispatches only on the ambiguous cases.

When you should not do this

The items are not actually independent. If reviewing post 12 needs the conclusions from post 5, partitioning breaks the analysis. Sequential agents, not parallel.
The total workload is small. Two posts? Just do them in one agent. The partition overhead is real.
The grouping itself is the question. ("Are these posts even from the same series?") If the groups aren't already obvious, figure that out first, then partition.

How These Three Stack

These patterns aren't alternatives. They compose.

A real workflow I ran last month:

Workload partition — split 47 posts into 3 groups, dispatch 3 reviewers, get 3 risk reports.
Structured dispatch — for each high-risk post, send it to the 3-perspective AdSense panel (conservative / preservationist / textualist) for the actual rewrite call.
Mandatory review gate — when implementing the rewrites, every rewrite has to pass SPEC_OK (does it address the flagged risk?) and QUALITY_OK (does it preserve the post's voice?).

Same three patterns, layered. No agent in this workflow was doing more than one job at a time, and no decision rested on a single agent's first instinct.

When a Single Agent Is Still the Right Call

I want to be honest about when none of this matters.

Tight, well-specified coding tasks. "Add a loading prop to this component." One agent. Done. A panel would be theater.
Quick lookups and one-shot questions. "What's the syntax for X in Y?" One agent. Stop.
Anything where you already know the answer and you're just looking for a typing assistant. This is most of my Claude Code usage, honestly. I'm not running panels for "rename this variable everywhere." I'm running panels for the calls where being wrong is expensive.

The patterns above are for the expensive calls. For the cheap calls, one agent is fine, and pretending otherwise is just bureaucracy with extra steps.

Where to Start

If you want a starter set of subagent definitions to riff on, the community keeps decent collections on GitHub — search for "claude code subagents" and you'll find a few curated lists. Pick three or four roles that map to work you actually do, copy them into ~/.claude/agents/, and ignore the rest. You can always add more later. You will almost certainly never need a hundred.

The skill isn't installing them. It's knowing which of the three patterns above the situation calls for, and dispatching accordingly.

2026.03.07