Investigation & Adversarial Verification

What a subagent is and why it exists

A subagent is a helper session your main agent spawns: it has its own separate context window (its own working memory), does a task, and returns only a summary to the parent. The parent never sees the hundred file reads the subagent did — just the condensed findings.

That isolation is the whole point, and it powers two distinct daily-work patterns: investigation (research without polluting your session) and adversarial verification (review without bias).

Pattern 1: Investigation subagents

Codebase research is context-hungry. "Figure out how caching works here" might mean reading twenty files — and if your main session does that reading, those twenty files sit in its memory for the rest of the conversation, crowding out the implementation work you actually care about.

The fix is one phrase:

Use subagents to investigate how cache invalidation works in this repo.

The subagent burns its own context on the exploration and returns a tight summary. Your main session stays clean for implementation.

One warning: an unscoped "investigate this" causes infinite exploration — the agent keeps finding one more interesting file. Scope the question narrowly ("how does cache invalidation work," not "understand the caching system"), or push it into a subagent where the wandering at least can't fill your main context.

Pattern 2: Adversarial verification

Here's the bias problem: an agent reviewing code it just wrote is compromised. It carries the full reasoning that produced the code — every assumption, every "this edge case can't happen" judgment — so it re-confirms its own logic instead of testing it.

A fresh context has no such loyalty. After implementation:

Use a subagent to review this code for edge cases.

The reviewer sees only the code, not the reasoning that produced it, so it evaluates what's actually on the page. This is the same reason human teams don't let authors approve their own pull requests.

The strongest version reviews the work against the plan:

Use a subagent to review the rate limiter diff against PLAN.md.
Check every requirement is implemented, listed edge cases have
tests, and nothing out of scope changed.
Report gaps, not style preferences.

Three checks in one prompt: completeness (every requirement), quality (edge cases tested), and scope discipline (nothing extra changed). The findings return into the implementing session, which fixes them and re-reviews — you never ferry text between windows.

Scope your reviewer, or it will over-deliver

Critical caveat: a reviewer instructed to find gaps will find some, even in sound work. That's what you asked for. If you treat every finding as a defect to fix, you'll chase style nits and hypothetical edge cases into defensive, over-engineered code.

Two defenses:

1. Scope the review to correctness and stated requirements — "report gaps, not style preferences" is doing real work in the prompt above.
2. Triage findings; don't auto-fix them. A finding is a claim to evaluate, not an order.

Scaling up: writer/reviewer as separate sessions

The subagent pattern generalizes to fully separate Claude sessions:

• Writer/Reviewer: session A implements; session B (fresh context) reviews the diff; A addresses the feedback. Same anti-bias logic, more powerful because B is a full interactive session.
• Test-writer/Coder: one session writes the tests, another writes code to pass them — the coder can't quietly weaken tests it never owned.
• Git worktrees give each parallel session an isolated checkout of the repo, so two sessions editing simultaneously never collide on files.

A realistic end-to-end flow for a rate limiter feature: worktree A implements; session B reviews the middleware for edge cases, race conditions, and consistency with the codebase's middleware patterns; A fixes what's confirmed; a final subagent checks the diff against PLAN.md before merge.

The two patterns side by side

The habit in one sentence

Research you don't want in your context and review you don't want biased both go to a fresh window — investigate with subagents, verify adversarially, scope the reviewer to gaps that matter, and triage rather than obey its findings.