The Doubt Loop, Automated

← Back to Engineering

Three days ago, I wrote about The Doubt Loop, a pattern where a second AI agent audits the first agent's work. The pattern works. But there is a problem: I am still sitting in the middle, copying and pasting between two terminal windows. We have been here before.

A year ago, we were copying code from editors into ChatGPT and back. We did this because ChatGPT could not see our files. Then Claude Code and Codex arrived with filesystem access, and that particular copy-paste dance ended.

Now I am doing the same dance again, just one layer up. The builder finishes. I copy its claims. I paste them to the auditor. The auditor responds. I copy its findings. I paste them back to the builder. Repeat three to five times until convergence.

The human is the router. And routers can be automated.

This is not a novel insight. The industry is converging on it from multiple directions. Platform engineering teams call it "actionable observability." Security teams call it "continuous remediation." Startups like Cloudgeni generate pull requests to fix compliance violations automatically. The pattern is the same: close the loop between detection and action.

The Cyclical Nature of Progress

Before diving into automation, I want to pause on what we are observing. The Doubt Loop is not unique. It is an instance of a pattern that appears everywhere.

This cycle appears in biology (growth, metabolism, repair). In astronomy (lunar phases, planetary orbits). In business (payroll cycles, quarterly reviews). In software (write, test, debug, deploy). The create-verify-correct loop is not an invention. It is a discovery of something fundamental.

The Doubt Loop is a specific instantiation: AI creates, AI claims completion, AI verifies, AI corrects. The question is not whether this cycle should exist. The question is whether a human needs to sit at each transition point, manually carrying information from one phase to the next.

The answer, increasingly, is no.

Three Architectures for Closing the Loop

I have been researching how to automate the Doubt Loop. The industry is converging on several patterns, each with different trade-offs.

Architecture 1: Sequential Orchestration

The simplest approach: a parent process spawns agents in sequence, passing outputs as inputs.

This is what Replit's Agent 3 does internally. Their "self-healing testing framework" runs builds, detects failures, and loops back to fix them without human intervention. The agent runtime increased dramatically because the loop runs autonomously.

Tools like Claude Code already support this via the Task tool, which spawns subagents. The orchestrator is the outer agent; the builder and auditor are inner agents with fresh context.

Architecture 2: Parallel Verification with Consensus

Instead of one auditor, spawn multiple auditors simultaneously. Aggregate their findings.

This exploits the observation from the original Doubt Loop article: different sessions notice different things. Three auditors with fresh context will catch more than one. Consensus filtering reduces false positives.

Research from recent multi-agent systems papers shows that ensemble verification significantly improves reliability, though it multiplies compute costs.

Architecture 3: Continuous Learning Loop

The most sophisticated approach: the system learns from each cycle and improves its prompts automatically.

OpenAI's Self-Evolving Agents cookbook describes this pattern. The loop is not just build-verify-fix. It is build-verify-fix-learn:

1. Builder creates code
2. Auditor finds gaps
3. Builder fixes gaps
4. System records what types of gaps were found
5. System refines builder prompts to prevent those gap types
6. Next iteration starts with improved prompts

The cookbook calls this "GEPA (Genetic-Pareto) Reflection." The system maintains a population of prompt variants, tests them against validation sets, and evolves toward prompts that produce fewer auditor findings.

This is where it gets interesting. The Doubt Loop becomes not just a verification mechanism, but a training signal. Every gap the auditor finds is data that improves the builder.

Implementation: The Automated Doubt Loop

The pattern is simple: after completing work, the builder generates structured claims about what it did. An auditor agent verifies those claims against the actual code. If gaps are found, the builder fixes them and the auditor runs again. The loop continues until convergence.

1. Builder completes work and outputs claims: files modified, functions changed, edge cases handled
2. Auditor spawns with fresh context, reads the code, verifies each claim
3. Findings returned as high/medium/low severity issues
4. Builder fixes high-severity issues, auditor re-runs
5. Convergence when no high-severity findings remain

The key insight: the human does not need to be the router. The outer agent can spawn inner agents, pass context programmatically, and loop until convergence. The human reviews the final result, not every intermediate step.

How to Do This with Claude Code

We implemented this pattern and it works. Here is exactly how to replicate it.

The Mechanism: Task Tool with General-Purpose Subagent

Claude Code has a built-in Task tool that spawns fresh agent instances. We use the general-purpose subagent type with explicit model selection and tool restrictions to create a read-only auditor.

Task(
  subagent_type: "general-purpose",
  model: "opus",
  allowed_tools: ["Read", "Glob", "Grep"],
  prompt: "AUDITOR (READ-ONLY): You are a skeptical code reviewer...",
  description: "Audit code changes"
)

Three key design decisions here:

• Explicit model selection. Without model: "opus", the subagent might inherit a weaker model or default to Haiku for "fast" tasks. Auditing requires deep reasoning, not speed.
• Tool restrictions. The allowed_tools parameter enforces read-only access. The auditor literally cannot call Edit, Write, or Bash. This is not a suggestion in the prompt; it is a hard constraint.
• Fresh context. Each spawn starts clean. No memory of building the code. No attachment to defending it.

Real Example: Modal Border Fix

We ran this pattern on a CSS fix where a gradient border was being clipped. What seemed like a one-file fix became an 8-file consistency problem. Here is exactly what happened:

Three agents. Three iterations. Eight files fixed instead of one. Without the loop, we would have fixed one modal and shipped seven broken ones.

Why Not Explore Subagent?

Our initial version used the Explore subagent. We changed it after discovering two problems:

• Model inheritance is unreliable. Explore is described as "fast" in the tool documentation, which biases toward Haiku. Even when the parent agent runs on Opus, the guidance to "prefer haiku for quick tasks" can override inheritance. Explicit is better than implicit.
• Explore is optimized for finding, not reasoning. It excels at file discovery and pattern matching. Auditing requires deeper analysis: understanding race conditions, security implications, architectural consistency. The general-purpose agent is framed for "complex, multi-step tasks" and better suited for this work.

The allowed_tools parameter gives us the read-only constraint we need without limiting the agent's reasoning capability.

The Complete Template

Add this to your project's CLAUDE.md file. When you finish a feature, the agent will automatically generate claims, spawn an auditor, fix issues, and loop until convergence. You review the final report, not every intermediate step.

### Doubt Loop

Auto-run after non-trivial changes. User can also trigger with "exec doubt" or "run auditor".

**Skip for**: typo fixes, comment-only, config files, docs-only changes.

#### 1. Claims (output before spawning auditor)

```json
{"files": ["path:lines"], "claims": ["What the code now does"], "not_handled": ["Known gaps"]}
```

#### 2. Spawn Auditor

```
Task tool → subagent_type: "general-purpose"
           model: "opus"
           allowed_tools: ["Read", "Glob", "Grep"]
prompt: "AUDITOR (READ-ONLY): Verify these claims against the code. Find gaps.
Do NOT fix anything. Only report findings.
[paste claims]
Check: logic errors, race conditions, error handling, types, UI states, security, pattern consistency.
Return: {high: [{issue, file, line, fix}], medium: [...], low: [...], validated: [...]}"
```

#### 3. Loop

- **High findings**: Fix → re-audit (max 5 iterations)
- **Medium findings**: Fix → re-audit (max 3 iterations)
- **Converged**: No high, no new medium

#### 4. Report

```
## Doubt Loop Complete
**Iterations**: N | **Status**: Converged
### Validated: [claims confirmed]
### Fixed: [issues addressed]
### Low Priority: [deferred items]
```

Policy vs Mechanism

The Task tool exists whether or not you configure anything. Claude Code can spawn subagents out of the box. What CLAUDE.md provides is the policy: when to use it, what to check for, when to stop. Without the policy, the mechanism sits unused. The pattern works because you codify the behavior you want, and the agent follows it.

This is the key insight: capability without policy is just potential. Write down when you want verification to happen, and it will happen consistently.

Future Direction: CLAUDE.md Invoking Skills

Embedding the full doubt loop in CLAUDE.md works, but it has limitations. The audit logic is duplicated across every project. Improvements to the pattern require updating every CLAUDE.md file. There is no shared learning.

The better architecture, if this pattern proves valuable across projects: CLAUDE.md invokes a standalone skill. The project file defines when to audit and project-specific context. The skill defines how to audit with battle-tested prompts that improve independently.

This separation of concerns is standard practice: policy in configuration, mechanism in shared code. We have not built this yet because we are still learning the pattern's failure modes. But the architecture is clear.

The Self-Healing Pattern

This is not speculative. Replit's Agent 3 uses self-healing loops internally. OpenAI's coding agents run verification passes automatically. The pattern is converging because it works: having the AI check its own work before a human sees it catches the obvious mistakes that waste human attention.

Our experience confirms this. In the modal fix example, three auditor passes caught issues across eight files. Total cost: a few cents in API calls. Alternative cost: a bug report, context switching, and another coding session. The economics favor automation.

When to Keep the Human in the Loop

Automation is not always the answer. Keep the human as router when:

• Stakes are high. Security-critical code, financial systems, medical applications. The cost of a missed gap exceeds the cost of human routing.
• Context is ambiguous. When the auditor's findings require judgment calls about product direction, not just code correctness.
• The problem is novel. The loop works best for well-understood issues: missing error handling, inconsistent patterns, forgotten edge cases. It is not yet suited for complex architectural decisions.
• Learning the pattern. Run the loop manually first. Understand its failure modes before automating.

The goal is not to remove humans entirely. It is to remove humans from mechanical routing so they can focus on judgment and oversight.

A Bridge for Vibe Coders

If you have spent any time with AI-assisted development, you know the pattern: you ask the AI to fix one thing, and three other things break. You fix those three things, and five more appear. The context window fills up. The agent forgets what it did twenty minutes ago. You start over.

This is arguably the biggest problem facing vibe coders today. The promise of AI development is rapid iteration. The reality is often a game of whack-a-mole where the moles multiply.

The Doubt Loop does not solve this problem completely. But early results suggest it helps significantly. When an auditor agent systematically checks what the builder claimed to do, regression errors surface before they compound. The CSS fix that touched eight files? Without the loop, we would have fixed one and broken seven. With the loop, we caught all eight in three iterations.

More testing is needed. We have run dozens of loops, not thousands. The pattern has failure modes we have not discovered yet. But the early signal is promising: systematic verification catches the "fix one, break three" problem at its source.

If this pattern holds, the Doubt Loop could become a bridge, not a final solution, but a practical step forward while we figure out better approaches. Perhaps future AI systems will have longer context, better memory, or architectural solutions we cannot imagine today. Until then, having a second agent check the first agent's work is a simple pattern that delivers measurable improvement.

For vibe coders tired of the regression treadmill, that might be enough.

The Next Cycle

A year ago: copy code to ChatGPT, copy response back. Then: agents with filesystem access.

Today: copy claims to auditor, copy findings back. Tomorrow: agents that spawn auditors automatically.

Next year: something we have not imagined yet, and we will look back at today's manual orchestration the way we now look back at copy-pasting code into chat windows.

The cycles continue. The human's position in the cycle shifts. The pattern remains.

The Doubt Loop taught us that AI checking AI produces more reliable software than AI alone. The next step is letting the loop run without a human in the middle. Not because humans are unnecessary, but because their attention is better spent on judgment calls that machines cannot make.

Organizations that close the feedback loop between detection and action see measurably faster incident response. The pattern works. The only question is whether you automate it or remain the router.

The loop closes. The cycle continues. The human moves up a level.

---

This post was written by the Fozbe engineering team. We build AI-powered software tools and believe the future of software development is human-AI collaboration with autonomous verification loops.

Further reading: The Doubt Loop: Why I Never Trust a Single AI Agent