An agent that cannot tell good work from bad work will keep making the same mistakes, confidently and at scale. Agent self-correction loops exist to break that pattern: the agent generates an output, evaluates it against some standard, revises it using the evaluation as feedback, and repeats until the output passes or a limit is reached. This article explains how agents evaluate their own outputs, walks through the loop step by step, compares the patterns that work in practice, and ends with concrete guidance for building one — including the research finding that a loop with no external signal can make results worse, not better.
What Self-Correction Means for an AI Agent
Self-correction is a closed loop with four stages: generate, evaluate, revise, and re-evaluate. The agent produces an initial output or action, judges it against a standard, produces a critique that says what is wrong and how to fix it, revises the output using that critique, and then evaluates the revision. The loop continues until the output passes or a stopping rule fires.
That is different from a plain retry after a tool error. A retry repeats the same action in the hope that a transient failure has cleared — a network timeout, a rate limit, a missing file. A self-correction loop changes the output itself based on feedback about its quality. The retry asks the world to behave differently; the correction loop asks the agent to do better.
In a typical agent run, the loop can sit in two places. It can run after each step, checking every intermediate action before the agent moves on — did the database query return what was expected, does the code compile, is the retrieved document relevant? Or it can run once at the end, reviewing the final output as a whole before it reaches the user. Step-level loops catch errors early, when they are cheap to fix; final-output loops catch errors that only become visible when the whole result is assembled. An agent can use both placements, choosing step-level checks where errors are cheap to catch and a final review where only the whole result can be judged.
How Agents Evaluate Their Own Outputs
Evaluation is the hard part of the loop, because the quality of the evaluation sets a ceiling on the quality of the correction. A weak judge cannot fix a weak generator. There are four evaluation mechanisms, each with a different relationship to the model that produced the output.
Self-critique needs no extra infrastructure beyond one more model call: the same model re-reads its own output against the task requirements and writes feedback on it. The cost of an evaluation mechanism depends on the checks and models used — a deterministic check costs almost nothing to run once written, while a model-based judge costs a call each time. Self-critique shares the generator’s blind spots — the same model that made the error is the one asked to spot it.
Rule-based checks are deterministic. A JSON schema validator, a format check, a unit test, a type checker — these give a yes-or-no verdict that the model cannot argue with. They only cover what can be specified as a rule, and they establish only the properties they actually test: a passing schema check says the format is right, not that the content is correct, and a passing test suite says the tested cases behave, not that the code is right in general.
Tool-grounded verification runs the output against the real world. The agent executes the code it wrote and reads the traceback. It queries the database and checks whether the result matches. It calls a search engine to check a factual claim. The verdict comes from a tool rather than from the model’s opinion, which makes it independent — but only as good as the check behind it. A test suite can be incomplete, a database can hold stale data, and a search result can be wrong; the usefulness of tool feedback depends on the validity and relevance of the check and the evidence it returns.
External judges sit outside the generating model entirely: a second model, a reward model trained to score outputs, or a human reviewer. A different model as critic can catch some errors that self-evaluation misses, because it does not reason in exactly the same way — though different models can still share failure patterns, so a second model is an improvement in odds, not a guarantee. Anthropic’s evaluator-optimizer workflow is this pattern in its simplest form: one LLM call generates a response while another provides evaluation and feedback in a loop, and it fits when there are clear evaluation criteria and iterative refinement provides measurable value.
The Self-Correction Loop Step by Step
Put the mechanisms together and the loop looks like this. First, the agent generates an initial output or action — a draft answer, a block of code, a tool call, a plan. Second, it evaluates that output and produces a structured critique, not just a pass or fail. A useful critique names the specific defect and the evidence for it: which test failed, which requirement is unmet, which fact is unsupported. Third, it decides: accept the output, revise it, or escalate to a human. Fourth, if revision is chosen, the generator produces a new version with the critique in its context, and the loop returns to evaluation.
The fifth element is the stopping rule, and it matters as much as the other four. Every loop needs an exit condition that does not depend on the model agreeing to stop. The standard rules are an iteration cap, an improvement threshold, and a time or cost budget. In practice, practitioners cap reflection loops at three iterations to bound cost — each round multiplies token usage and latency, and returns diminish fast.
The critique itself should be structured data, not free prose, so the generator can act on it mechanically. A common shape is a small JSON object with a verdict, a list of defects, and a concrete fix for each:
{
"verdict": "revise",
"defects": [
{
"field": "total",
"problem": "Total is 142.50 but the line items sum to 124.50",
"evidence": "sum(line_items) = 124.50",
"fix": "Recompute the total from the line items"
}
],
"stop": false
}The schema is deliberately narrow: a verdict, defects with evidence, and a fix per defect. The evidence field is the load-bearing part — it forces the evaluator to point at something checkable, which is what separates a critique from an opinion.
Common Self-Correction Patterns in Practice
Four named patterns illustrate the main approaches builders use. Reflexion, from Shinn and colleagues at NeurIPS 2023, converts feedback into verbal feedback — a short written reflection on what went wrong — and stores it in an episodic memory buffer that the agent reads on its next attempt. That feedback can come from three sources: binary environment signals, pre-defined heuristics for common failures, and self-evaluation such as an LLM judging its own output or self-written unit tests. It needs no weight updates and no fine-tuning. Its headline results are strong: 91% pass@1 on the HumanEval coding benchmark against a GPT-4 baseline of 80%, a 22-point absolute improvement on AlfWorld decision-making tasks over 12 iterative steps, and a 20% improvement on HotPotQA reasoning questions.
Self-consistency, from Wang and colleagues at Google Research in 2022, takes a different route. Instead of revising one output, it samples many diverse chain-of-thought reasoning paths for the same question and returns the answer most paths agree on, by majority vote. It works entirely at inference time with no weight changes, and the gains are large on reasoning benchmarks: 10.6 points on GSM8K, 14.4 points on SVAMP, and 23.9 points on MultiArith over a single chain of thought.
Critic models and debate put a second model in the evaluator’s seat. The generator and the critic can be different models, which can help: a critic that does not share the generator’s weights may not share its exact failure patterns. But different models can still share blind spots, so the choice of critic matters more than the mere fact of having one. Multi-agent debate extends the idea to several critics arguing about the output before a revision is attempted.
Plan-then-verify separates generation from verification structurally. One pass produces the plan or the answer; a dedicated verification pass checks it before the result is committed. Verification itself often involves executing something — CRITIC, for example, runs a code snippet in an interpreter to obtain its critique — so the distinction is between verifying a proposed action before committing to it and executing it blind, not between verification and execution as such. CRITIC, from Gou and colleagues at ICLR 2024, is the clearest version of this: a verify-then-correct loop where the model interacts with external tools — a search engine to check a factual claim, a code interpreter to run a snippet — and the tool’s output, not the model’s opinion, becomes the critique. Removing the tools sharply drops its effectiveness in CRITIC’s reported results, which is itself the point: the critique is only as strong as the evidence behind it, and for CRITIC the tool output is what makes that evidence strong.
What Makes a Correction Loop Work — and What Breaks It
The first condition for a working loop is a reliable evaluation signal. Reflexion works when the feedback is real — a test failure, a compiler error, a wrong answer flagged by the environment. Self-consistency works by aggregating across many diverse sampled reasoning paths and taking the majority answer; the reported benchmark gains come from that aggregation, not from any guarantee that the samples are independent. CRITIC works because the verdicts come from tools the model did not author — though a tool verdict is only as good as the check behind it.
The failure mode to take seriously is self-confirmation bias. A model asked to judge its own output tends to approve it, because the reasoning that produced the error is the same reasoning that evaluates it. The research record on this is unusually blunt. Huang and colleagues, in a 2024 ICLR paper titled Large Language Models Cannot Self-Correct Reasoning Yet, tested intrinsic self-correction — looping with no oracle and no external tool — and found it fails to improve reasoning and frequently makes it worse. On GSM8K grade-school math, GPT-4 scored 95.5% with standard prompting, 91.5% after one self-correction round, and 89.0% after two — while spending five model calls instead of one. On HotpotQA it went from 49.0% to 49.0% to 43.0%. The loop was more likely to fix a correct answer into a wrong one than to repair an actual error.
The same paper explains why earlier results looked so good. Several studies that reported successful self-correction had quietly used an oracle stopping rule: stop the loop as soon as the answer is correct. That rule leaks the ground truth into the procedure. With the oracle in place, GPT-4 on GSM8K went from 95.5% to 97.5%; with the model deciding for itself when to stop, the gains evaporated or inverted. Stechly and colleagues found the same collapse on planning and graph-colouring problems in 2024: self-critique hurt, sound external verification helped. A survey by Kamoi and colleagues (TACL 2024) concluded that no study demonstrates successful self-correction using only prompted LLM feedback except in tasks naturally suited to it, that self-correction works well with reliable external feedback, and that large-scale fine-tuning enables self-correction where prompting alone fails. The rule is not universal, though: Self-Refine, which uses one model as generator, feedback provider and refiner with no external signal at all, reported about 20% average improvement across seven tasks. Intrinsic self-correction is task- and training-dependent — it can help, it can hurt, and the outcome depends on the task and the model, not on which side of an internal-external line the feedback sits.
Two more failure modes deserve attention. Oscillation and drift: revisions that wander away from the goal, each round fixing one defect while introducing another, so the output never settles. And cost: every iteration multiplies tokens and latency, so a loop that runs five rounds to produce a slightly worse answer is worse than no loop at all.
Building Agent Self-Correction Loops in Your Own Agent
Start with deterministic checks before adding model-based judges. Schema validation, format checks, unit tests, and database lookups are cheap, fast, and deterministic — and they give the loop a foundation of verdicts that establish exactly the properties they test. A check that passes says the tested property holds; it says nothing about the properties nobody thought to test. Add an LLM critic only for the judgments no rule can express.
Write the critique as structured feedback the generator can act on. A free-form paragraph of praise and complaint is hard for the next generation pass to use; a verdict plus a list of defects, each with evidence and a concrete fix, is directly actionable. The JSON shape in the previous section is a reasonable starting point.
Ground the critique in a tool wherever possible. In LangGraph, the natural shape is a generator-critic graph: a generate node, a critique node, and a conditional edge that routes back for revision when the critique fails the output. When a tool is involved, let the tool speak first — a code-generation loop that runs the code, reads the traceback, and feeds the traceback to the critic works far better than a critic guessing at what might be wrong, because the critic is reading a real failure signal. LangGraph’s ToolNode supports this directly: with error handling enabled, a failed tool call returns its error text as a message the model can self-correct from, instead of crashing the graph.
The skeleton below is a fragment, not a complete program — the generate and critique functions are the parts you supply, and the loop shows only the control flow around them:
MAX_ROUNDS = 3
def run_with_correction(task):
output = generate(task)
for round_no in range(MAX_ROUNDS):
critique = critique_output(task, output)
if critique["verdict"] == "accept":
return output
output = generate(task, feedback=critique)
return escalate_to_human(task, output)Log every iteration so failures are inspectable. Each round’s output, critique, and verdict should be persisted — when a loop oscillates or drifts, the log is the only way to see what happened, and it is also the training data for improving the critic. And set hard caps: a maximum number of iterations, a maximum token budget, and a clear escalation path to a human when the loop exhausts its rounds without a passing output. The escalation is not a failure of the design; it is the design working as intended.
Limits and Open Questions
Self-correction cannot create knowledge the model does not have. If the generator cannot produce the right answer in the first place, no amount of re-reading its own work will conjure it — the loop can only select and refine among outputs the model is already capable of producing. And when the evaluator and the generator share the same blind spots, the loop is an echo chamber: both agree, both are wrong.
The open research questions follow directly from those limits. Can models learn reliable self-evaluation — calibrated confidence that actually predicts correctness — rather than confident approval of their own errors? Can judges be made cheaper, so that verification does not cost more than generation? And which tasks genuinely benefit from intrinsic self-correction at all, given that the evidence is mixed — reliable external feedback helps in the studies that have it, while intrinsic self-correction has produced both gains and regressions depending on the task and the model?
The practical conclusion is narrower than the hype and more useful than the scepticism. The evidence gives the most consistent support to loops whose evaluation is anchored in something the model did not author: a test, a tool, a schema, a second model, a human. Reliable external feedback can help, while intrinsic self-correction has task- and training-dependent results and can degrade reasoning — though the Self-Refine result shows it is not always doomed, and fine-tuning can change the picture. Build the loop around the strongest verdict you can get, cap the iterations, log everything, and escalate when the loop cannot converge — reliable evaluation can support correction, but whether a loop helps must be measured for the particular task and model, including checking for regressions, and neither external provenance nor the recommended safeguards guarantees success.
