The "second reader" pattern: subagents that review other subagents' output

Every LLM output has a specific failure mode: the confidently-wrong answer. Not obviously wrong — plausibly wrong. The kind of output that reads as authoritative and correct until someone spots the flaw. Single-reader review catches most of these; some slip through because the primary reader shares the same blindspots as the writer. The second-reader pattern — a distinct reviewing subagent — catches that specific class of failure. It's not the right pattern for every workflow, but for high-stakes outputs, it's worth the extra cost.

This post is when to add a second reader, how to design it to catch what the primary misses, and — importantly — when NOT to add one because the cost outweighs the benefit.

What "second reader" means for AI outputs

The pattern: subagent A produces some output (a PR review, a spec, an analysis). Subagent B receives A's output plus the original inputs, and reviews A's output for specific failure modes — factual errors, missed considerations, unjustified claims, unstated assumptions.

B is deliberately different from A. Different model choice sometimes (an Opus reader for a Sonnet writer, for instance). Different prompt framing (A tries to produce; B tries to verify). Different tools (B often has read-only access to source material). Different criteria (A optimizes for correctness; B optimizes for finding errors).

The output isn't just A's output — it's A's output plus B's review. Downstream consumers see both. B's findings can flag issues, request revisions, or bless A's output as ready to use.

Why this catches things a single reader can't

Single-reader workflows have three specific failure patterns that second readers address:

Pattern 1: Shared blindspots

When one LLM produces output and reviews itself (or another instance of the same model reviews it), they share failure modes. If both instances misunderstand a specific technical concept, both will accept the wrong output. The reviewer can't catch what it doesn't know is wrong.

A different reader — different model, different prompt framing, different criteria — has a chance of not sharing those blindspots. When a Sonnet-based writer produces output, an Opus-based reviewer sometimes catches issues Sonnet-self-review missed. The models aren't independent, but they're different enough that some errors visible to one aren't visible to the other.

Pattern 2: Confirmation bias

LLMs asked to review their own work tend to confirm it. The prompt sets up a task; the output is completed; asking "is this good?" biases toward "yes." Self-review is subject to a form of confirmation bias.

A second reader with a different framing — specifically "find problems with this output" rather than "verify this output" — produces less biased assessments. The framing shift matters. A reviewer asked "does this contain errors?" finds more errors than one asked "is this correct?"

Pattern 3: Missing context

The writer subagent works with the context needed to produce the output. Some considerations that should influence the output aren't in that context — they're in other parts of the codebase, in team conventions, in adjacent systems.

A second reader with different context (or the ability to fetch different context) can spot when the primary output missed something. This is especially valuable when the second reader has access to reference material the primary didn't consult.

When to use the pattern

Second readers cost real money — they're another subagent invocation, another set of context, another model call. The cost is justified when:

High stakes

The output has real consequences if wrong. Deployment scripts. Security-relevant code. Public-facing content. Anything where "confidently wrong" produces real damage.

For low-stakes outputs (draft docs, exploratory analysis, iteration on internal tools), the second reader is overhead. The primary can be wrong occasionally without meaningful damage; the review cost isn't justified.

Downstream automation

If the output feeds into downstream automation that will act on it without human review, second-reader review catches issues before they cascade. Human reviewers can catch primary errors; automated consumers can't. Second readers substitute for the human review that isn't happening.

Known-failure-mode patterns

When you've observed specific failure modes in a workflow — categories of errors that keep happening — a second reader specifically designed to catch those modes is worth the cost. The reader isn't generic; it's tuned to the specific failures the workflow tends to produce.

How the second reader differs from the primary

A second reader that's just "another instance of the primary" doesn't add much value. Deliberate differences matter. Four axes on which to differentiate:

Axis 1: Model tier

If the primary uses Sonnet, the reader might use Opus. The stronger model catches errors the weaker one made. Cost impact: reader is more expensive per invocation. Worth it when the primary's errors would be expensive.

Alternatively: reader uses same model but with a different system prompt or different sampling parameters. Different generation → different failure modes → more coverage.

Axis 2: Framing

Primary's prompt is "produce this output." Reader's prompt is "find problems with this output." The negative framing produces different behavior — the reader isn't trying to help complete the task; it's trying to catch issues.

Specific reader-prompt patterns that work:

• "List every claim in this output and rate confidence"
• "Assume this output has at least one error. Where is it most likely?"
• "Compare this output against the original inputs. What did the writer miss?"
• "What would a hostile reviewer catch in this output?"

Axis 3: Tool access

The reader has access to reference material the writer didn't. If the writer produced code without reading the style guide, the reader has the style guide. If the writer produced a spec without checking existing docs, the reader has the docs.

This is often the highest-leverage difference. The writer worked with focused context; the reader has broader context to verify against.

Axis 4: Criteria

The reader's success criteria differ from the writer's. Writer succeeds if the output looks correct; reader succeeds if they find issues. Different definitions of success drive different behavior.

For our pr-reviewer, the second reader's criteria include: does every "blocking" finding have concrete evidence? Are any findings likely to be false positives? Does the summary accurately reflect the findings? These are meta-criteria about the review itself, not the code being reviewed.

Three concrete second-reader implementations

Cases where we ship this pattern in production:

Example 1: PR reviewer + review-of-review

Primary: @pr-reviewer produces structured feedback on a PR (blocking issues, suggestions, questions).

Second reader: @review-verifier checks the review. Are the blocking issues actually blocking? Are any findings duplicative? Does the review miss any obvious category of issue?

Impact: catches ~15% of reviews where the primary flagged issues that weren't really blocking (false positives) or missed issues in categories it usually catches (false negatives). Cost: ~35% more per review. Worth it because pr-reviewer output goes to humans who trust it — false positives waste attention, false negatives let bugs through.

Example 2: Spec drafter + fact-checker

Primary: @spec-drafter produces a technical spec based on requirements plus codebase reading.

Second reader: @spec-fact-checker verifies claims in the spec against the actual codebase. When the spec says "the current auth flow uses X," the fact-checker reads the auth flow and confirms.

Impact: catches unjustified claims in specs — cases where the drafter asserted something plausible-sounding but factually wrong about existing code. Prevents specs from being built on incorrect assumptions. Cost: significant, because fact-checking requires reading the referenced code. Justified because bad specs are expensive downstream.

Example 3: Migration generator + safety reviewer

Primary: @migration-writer produces database migration code from a schema change spec.

Second reader: @migration-safety-reviewer checks the migration for known-dangerous patterns: table locks, non-reversible operations, missing backfill considerations, changes that would fail on large tables.

Impact: catches issues that would cause outages in production. Cost: modest. Justified because production database issues are extremely expensive to recover from.

When NOT to add a second reader

The pattern is over-applied by teams that discover it works well in a few cases. Cases where it's wrong:

Case 1: Low-stakes outputs

If the output is exploratory, iterative, or easily verified by the human who requested it, second-reader review is overhead. The primary can be wrong occasionally; the human catches it. Adding a second reader adds cost without adding value.

Case 2: When humans already review

If a human is going to review the output anyway (as with most interactive Claude Code sessions), the human is the second reader. Adding an AI second reader duplicates the check. Better to invest in making the primary better, or the human review workflow better, than to layer another AI check on top.

Case 3: Homogeneous readers

If the "second reader" is just another instance of the same model with the same prompt, it doesn't add coverage — it just doubles cost. Second readers add value only when they differ meaningfully from the primary. Same model, same framing, same context = no useful second reader.

Case 4: When latency matters

Second readers add latency (roughly double, since they run after the primary). For time-sensitive workflows, this can be prohibitive. A PR review that takes 30 seconds is fine; if the second reader adds another 25 seconds, the workflow becomes annoyingly slow.

Sometimes the fix is running second readers in parallel with subsequent human work — the human starts reading the primary output while the second reader finishes; findings appear as they're ready. But this is more complex than adding a second reader naively.

The cost/benefit calculation

Rough decision heuristic:

• Cost: ~30-100% more per invocation (second model call, possibly stronger model)
• Benefit: catches 10-25% of primary errors that would otherwise ship
• Justification: works when the cost of primary errors exceeds the added review cost by 4-10x

For low-stakes work (an error costs the same as re-running the task), the math doesn't work. For high-stakes work (an error costs 10-100x a task run), the second reader is a bargain — you're preventing 10x-cost failures for 1x-cost review.

How outputs get combined

The primary's output plus the second reader's findings need to be combined into something the downstream consumer can use. Three patterns work:

Pattern 1: Appended findings. Primary output with a "Second-reader findings" section appended. Simple; preserves everything. Downstream consumers can process the primary and separately see the review.

Pattern 2: Modified output. Second reader's findings get incorporated into a revised primary output. Requires the second reader to know how to modify the primary's format. More complex; produces cleaner final output.

Pattern 3: Blocking flag. If the second reader finds critical issues, the whole output is flagged as unready; consumers see the primary output plus "SECOND READER BLOCKED: [reasons]." Requires re-work before use.

Which to use depends on the consumer. Humans usually prefer appended findings (they can judge severity). Automated consumers usually need blocking flags (they need a machine-checkable "is this ready" signal).

What we learned

Six months of using this pattern in production taught us three things:

Diversity of framing matters more than model tier. An Opus reader with the same prompt as a Sonnet writer catches fewer errors than a Sonnet reader with a completely different framing. Getting the reader's job right is more valuable than getting a stronger model.

Reader-specific tests are essential. Just because the primary passes its tests doesn't mean the reader does its job. Test the reader separately — feed it known-flawed outputs, verify it catches the flaws. Untested readers give false confidence.

Readers benefit from evolution. As the primary's failure modes change (because you fixed the old ones), the reader needs updating to catch new patterns. Static readers become less valuable over time as the primary's failures shift.

The starting practice

If you have a high-stakes workflow with a subagent producing output that's consumed downstream without human review, try adding a second reader. Design it deliberately: different model or different framing, tool access to reference material the primary lacks, criteria focused on finding issues rather than confirming correctness.

Measure the impact for a month. Track: how often does the second reader catch things the primary missed? What kinds of things? How often does it produce false positives? Adjust based on data. If it earns its cost, keep it. If not, retire it — the pattern isn't universal, and being disciplined about when it applies is what makes it valuable when it does.