Your Agent Reviewing Its Own Work Is Not a Check

The problem

You add a step: agent generates output → agent reviews output → agent ships. It feels safe because the step exists. It is not safe. A review from the same model is a second opinion from the same source. It cannot catch the errors the model is most likely to make, because those errors come from the model’s own blind spots.

This is the single most common gap in agent systems, and it hides in plain sight precisely because the step is labeled “review.”

The rule / frame

A check is something that can disagree with the generator using independent information. Same model, same weights, same priors, same blind spots = not independent. You need a different vantage point: a different model, a deterministic test, a schema validator, or a human.

The trap is renaming the same-model call with a different prompt. “Review my answer” is still the same model saying “yes, that’s what I would have written.” That is not a check; it is a confirmation.

This is the standard ML argument for independent verification. It is not a benchmark result; it is the textbook mechanism behind correlated errors.

Why same-model self-review fails

• Correlated errors. If the model misreads the spec, it misreads it the same way on review. The bug passes both passes.
• Confirmation bias by construction. The generator “believes” its output is right; the reviewer is the same system with the same priors. It rubber-stamps.
• No ground truth. Self-review measures “does this look like my other outputs,” not “does this match an external requirement.” Those are different things.
• Different prompt, same weights. Restating the task as a critique prompt is the most common fake fix. The weights haven’t changed. The priors haven’t changed.

What counts as a real check

Pick at least one that is independent of the generator. Combine cheap checks first, expensive checks last.

1. Schema / contract validation. Output must match a schema — types, required fields, ranges, enums, and structural rules. This proves output shape. It does not prove whether the action is intended or authorized. (OpenTelemetry logs data model is the canonical reference for the per-call attribute shape ABS uses.)
2. Deterministic tests. Unit tests, type checks, HTTP status assertions, exit codes, schema fixtures, golden-output comparisons. Code doesn’t “review” — it passes or fails. Strongest when the output is testable.
3. Second-model review. A different model (ideally a different family) reviews against the spec. Different blind spots → real disagreement surface. Cheapest real check for non-deterministic tasks.
4. Eval set. A fixed set of inputs with known-good outputs. Regression, not opinion. Use this when the output is non-deterministic but you have ground truth on a sample.
5. Human gate. A person approves before ship. Slow but undefeated for high-stakes or irreversible actions. This is a process check, not a code pattern. A schema validator cannot replace it.

A “review” step using the same model counts as none of these for purposes of safety or correctness.

A worked micro-example

Suppose your agent generates a JSON object describing a task to run:

• Generator: LLM-A writes { "tool": "delete_user", "id": 7 } based on a user request.
• Same-model review (the trap): LLM-A is asked “is this safe to execute?” → answers yes. Correlated error: if LLM-A misread the request as “delete” instead of “archive,” its review agrees.
• Real check — schema validation: does the JSON match { tool: enum, id: int }? Passes. This proves the JSON is well-formed; it does not prove deleting user 7 is correct.
• Real check — second model: a different model (different family) is asked the same yes/no question with the user’s original request attached. Different weights → can disagree.
• Real check — human gate: irreversible actions require a person. The check fails automatically if a human has not approved.

Combine them in layers. Cheap checks first (schema), expensive checks last (human). Each check proves a different thing.

The minimal pattern

generate  →  verify (independent)  →  act OR escalate
   ↑                                    │
   └──── on failure: re-prompt (≤ N times)  ──┘

Step by step:

1. Generate with your agent. Generation is fine; agents are good at it.
2. Verify with something independent: a schema validator, a test suite, a second model scored against the spec, or a human gate. Not the generator re-reading its own work.
3. Act only if the independent check passes. If it fails, route back to (1) with the check’s output as signal — what the check said it expected vs what the generator produced.
4. Cap the loop at a small retry budget (typically 2 attempts). After the budget, stop, escalate to a human, or queue the item for review. Never let an unbounded re-prompt loop run. The cost cap pattern (cost-cap guide) prevents the loop from running forever on cost; the retry budget prevents it from running forever on logic.
5. Log the check result separately from generation. Generation success and check success are different events. The observability hook guide covers per-call JSONL with separate kind: model and kind: error records.

If you cannot name the independent check, you don’t have one — you have a feel-good step.

Common failure modes

• Infinite self-review loops. Agent rewrites, re-reviews, rewrites… never converges, bill climbs. Cap the retry branch at 2 attempts. After that, escalate or stop.
• Review-as-the-only-gate on destructive actions. Letting the same model approve its own DB delete or send is how agents do damage. Require a human or deterministic gate for irreversible steps.
• “Tests passed” theater. Tests that only assert the output exists (not that it is correct) are a weak check. Assert behavior, not presence.
• Different prompt, same model = same blind spots. Renaming “review” as “critique” or “verify” doesn’t help. The only thing that helps is different information.
• Skipping the check on “obvious” outputs. The obvious outputs are where correlated errors hide best. Cheap schema checks catch cheap mistakes; don’t skip them.
• Reviewing the prompt instead of the output. The generator’s reasoning may look fine while the output is wrong. Check the output, not the rationale.

How to spot a fake check in your own code

Three signals you have a fake check:

1. You have a label that says “review” / “verify” / “critique” and it calls the same model as the generator.
2. The review step’s prompt is a paraphrase of the generator’s prompt.
3. The check has never failed in your production. (Either your outputs are perfect — unlikely — or the check isn’t actually checking.)

Fix for any of these: route the check to a different model, a deterministic test, or a human gate.

Done means

• A run can fail its own check and you see why in a log.
• The check is independent of the generator (different model / test / schema / human).
• Irreversible actions require a gate beyond self-review.
• The retry branch is bounded. A loop is a stop condition, not a background task.
• The check result is logged separately from the generation result.

What this article deliberately does NOT cover

• A formal verification framework. This guide is operational, not a proof system.
• A policy / authorization engine. Schema checks + a human gate are not the same as a full permission system; treat the gate as a process control, not a security boundary.
• Adversarial robustness. The patterns here reduce accidental failure, not determined attackers.
• A complete evaluation pipeline. Eval sets and second-model review are mentioned, not built; treat them as separate guides when you need them.
• Self-improvement via the review step. Same-model review is not a learning signal; that is a separate topic (Honcho / agent-curated memory).

Tie-ins

• The 1-line observability hook — log the check result separately from generation.
• Why every agent needs a cost cap on day one — cap the review-retry loop so it can’t run forever.
• The three-phase context loop — the “landing” phase is where a failed check should return, not where the agent declares victory.
• Start Here: Local AI and Agents — if you haven’t set up the harness yet, the hub first.
• How to find, download, evaluate local models — for second-model review via a local second model.

Related guides (internal links only)

• Why every agent needs a cost cap on day one
• The 1-line observability hook that fits any agent
• The three-phase context loop
• Start Here: Local AI and Agents Without Wasting a Weekend
• Cost-aware model routing for agents

Sources / what we ran

• Independent-check pattern: operational at ABS for the cost-cap, observability, and three-phase context patterns; not benchmarked in isolation.
• Correlated-error reduction from independent review: standard ML understanding; not benchmarked at ABS.
• Per-call attribute shape (model, tokens, latency): a simplified subset of the OpenTelemetry GenAI semantic conventions namespace — see the GenAI spec for the full canonical shape.