Agent Self-Correction: When Reflection Helps and When It Does Not

Self-correction is the idea that an agent can improve its own output by reviewing it. The literature is genuinely mixed on this, and the mixed results are not noise — they track a specific property of the task.

The property is whether the correction step has access to information the original attempt did not. When it does, self-correction works reliably. When it does not, it mostly produces confident revisions that are no better and often worse.

The distinction that predicts the outcome

Consider two review prompts. The first says: here is your patch, look at it again and fix any problems. The second says: here is your patch, here is the test suite output showing three failures, fix them.

The second works because it introduces a signal from outside the model. The first asks the same weights that produced the answer to evaluate the answer, using the same reasoning that made the mistake.

Everything useful about self-correction follows from this. The mechanism is not reflection; it is the feedback channel. Reflection is what the model does with the feedback once it has it.

Pure reflection has a specific failure mode

Ask a model to review correct output and it will frequently find something to change, because the request implies a problem exists and producing a criticism is the compliant response.

The result is drift: a correct implementation gets rewritten into a slightly different one with a new bug, and the transcript now contains a confident justification for why the change was needed. That justification makes the regression harder to spot in review, not easier.

The mitigation is to make no-change a first-class outcome. State explicitly that most work under review is acceptable and that approving unchanged is the expected result, then ask for a verdict before any revision. A step that can only produce edits will produce edits.

Build the feedback channel first

If self-correction depends on external signal, the engineering work is in producing signal rather than in prompting.

For code, the signal already exists and is usually underused: the compiler, the type checker, the linter, the test suite. Each is a fast, deterministic oracle that the model cannot argue with, and wiring them into the loop as tools does more than any reflection prompt.

Order them by cost. A type error found in a second is worth more than the same error found by a test run in two minutes, because the loop turns faster and the transcript stays shorter. Run the cheap checks on every edit and the expensive ones at completion.

For output that is not code, the signal has to be constructed: schema validation for structured responses, a retrieval step that checks claims against sources, a second model with different information. Structured outputs and JSON mode covers the validation route.

Correction is a loop and needs the same bounds

Failure to converge is common: a fix breaks something else, the next fix breaks the first thing back, and the cycle repeats until a limit intervenes.

Cap correction attempts at two or three. Beyond that, the marginal probability of success falls sharply while cost keeps rising, and continuing is usually worse than stopping and reporting.

Track whether the failure signature is changing between attempts. The same error three times means the model does not understand the problem and more attempts will not help; different errors each time means progress even if nothing passes yet. That distinction is a better stopping rule than a raw count. Detecting agent loops covers the detection.

The transcript works against later attempts

By the third correction attempt, the conversation contains several failed approaches and their justifications, and that history biases the model towards variations on what it has already tried.

Resetting helps more than it should. Discard the failed attempts, keep the original task and the accumulated error information, and start again with a clean transcript. This routinely succeeds where a fourth in-context attempt does not.

It also costs less, because the retry starts from a short context rather than a long one. Where the failure is a wrong initial approach rather than a small mistake, a clean restart is the cheaper and better option. Agent memory and context management covers what to carry across.

Separating the roles helps, mildly

Having a distinct reviewer look at the work — a separate call with a separate prompt, and ideally a different model — measurably outperforms asking the same conversation to reconsider.

The gain comes from the reviewer lacking the author's context and therefore not inheriting its assumptions. It is a real effect and a modest one; it does not substitute for a test suite. Critic agent patterns covers structuring the review, and verifier agents covers the stricter pass-or-fail variant.

Be honest about the cost. A separate review pass roughly doubles the token spend for the reviewed step, which is worth it before an irreversible action and hard to justify on every edit.

What to implement

Wire deterministic checks into the loop as tools, cheapest first, and let their output drive correction. Cap attempts at three, watching whether the failure signature changes. Reset the transcript rather than continuing when it does not.

Add a separate reviewer only at consequential boundaries, and give it permission to approve unchanged. Skip pure reflection with no external signal entirely — it costs tokens and buys drift. Evaluating agent reliability covers measuring whether any of it helped on your own work.