Why one AI agent is never enough.
Based on The Doubt Loop by Fozbe Engineering
AI coding agents are overconfident. They build features, announce success, and move on. The code compiles. The tests pass. The agent says "Done!" with the conviction of someone who has never been wrong.
Then you ship it and discover the race condition, the null check, the auth bypass.
The issue is not that agents make mistakes. Humans make mistakes. The issue is that a single agent reviewing its own work has the same blind spots that produced the bugs in the first place. It cannot see what it cannot see.
"Audit and validate these claims. Find the gaps."
Not "find any gaps." Not "please review." Not "check for issues."
"Find the gaps."
The definite article matters. "Find any gaps" implies they might not exist. "Find the gaps" presumes they do. This framing biases the model's context window toward skepticism rather than confirmation. The auditor does not ask whether problems exist -- it hunts for the ones that are already there.
The Doubt Loop is a four-step adversarial cycle between a builder agent and an auditor agent with a fresh context window:
The critical detail: this is not one pass. The builder often introduces new issues while fixing old ones. Three to five iterations is typical before the auditor finds nothing significant.
Fresh context. The auditor has no sunk cost in the implementation. It did not write the code, so it has no bias toward defending decisions it made. Every line is suspect.
Adversarial framing. "Find the gaps" surfaces different findings than "please review." The former is a hunt. The latter is a courtesy.
Permission to criticize. Explicit instruction to doubt changes what agents report. Without it, agents default to politeness -- they note minor style issues and declare the code sound. With it, they dig.
Separate sessions. Even using the same model, a separate context window approaches code differently. The builder's context is polluted with its own reasoning chain. The auditor reads the code cold.
These are real findings from pre-deployment audits on code the builder declared complete:
Every one of these existed in code the builder agent had confidently marked as done.
You do not need Context Foundry to use the Doubt Loop. Two terminals and a clipboard are enough:
# Terminal 1: Builder (Claude Code, Cursor, Copilot, etc.)
# Work normally. When the agent says "done", copy its summary.
# Terminal 2: Auditor (different session, same directory)
# Paste the builder's claims and add:
"Audit and validate these claims. Find the gaps."
# Copy the auditor's findings back to Terminal 1.
# The builder fixes. Repeat until the auditor finds nothing.The human stays in the loop as the router -- copy, paste, decide when to stop. This alone catches a surprising number of issues that would otherwise ship.
Context Foundry bakes the Doubt Loop into its pipeline as a first-class stage. After the builder finishes, it writes a structured build-claims.md file:
# Build Claims -- T23.1
## Files Changed
- [MODIFY] src/prompts.rs -- added silent execution directive
## Verification Results
- Build: PASS (cargo build --release)
- Tests: PASS (cargo test)
## Claims
- [ ] Silent execution directive added to all 5 prompt functions
- [ ] No existing tests broken by the change
## Gaps and Assumptions
- Did not test with Codex provider (only Claude)A fresh-context reviewer agent then reads this file and the actual code. It verifies every claim, re-runs the build and tests independently, and fixes any HIGH or MEDIUM issues it finds. The reviewer writes a structured report with severity-classified findings, provenance evidence, and confidence scores.
The cycle is fully autonomous. No clipboard. No copy-paste. The human reviews the final diff.
Anthropic's own evaluation framework for Claude identifies multi-instance and multi-pass review as a distinct capability area. Their internal task statements describe three properties that make independent review effective:
Self-review limitations: A model retains reasoning context from generation, making it less likely to question its own decisions in the same session.
This is exactly what the Doubt Loop exploits. The builder's context window is contaminated with its own reasoning chain -- the justifications for every decision it made. A reviewer in the same session would inherit those justifications. A fresh-context auditor does not.
Independent review instances (without prior reasoning context) are more effective at catching subtle issues than self-review instructions or extended thinking.
You cannot prompt your way out of self-review bias. Telling an agent "now review your own work carefully" is less effective than handing the code to a second instance that never saw the builder's reasoning. The independence is structural, not instructional.
Multi-pass review: Splitting large reviews into per-file local analysis passes plus cross-file integration passes to avoid attention dilution and contradictory findings.
Context Foundry implements this directly. The reviewer stage runs per-file analysis first (each file reviewed in isolation for local bugs), then an integration pass that looks for cross-file issues: interface mismatches, data flow bugs, missing error propagation across module boundaries. Splitting the review this way prevents a single long context window from losing focus and contradicting itself.
The practical version: a second agent with "find the gaps" catches more than a first agent with "review your work." The research explains why -- context contamination from generation makes self-review structurally weaker than independent review.
The Doubt Loop reduces risk. It does not eliminate it.
Two agents sharing the same model have correlated blind spots. They are better at catching implementation errors than architectural mistakes. The loop supplements -- never replaces -- traditional testing, code review, and security audits.
But it catches enough that shipping without it feels like skipping tests. Once you see what the auditor finds in code you were about to merge, you do not go back.