Self-Correcting Agent Loops: How Agents Detect and Fix Their Own Mistakes

A self-correcting agent loop shows itself best in a small failure. An agent writes a database query, runs it, and gets back a syntax error. A brittle setup returns that error to the user or stops dead. A better one reads the error, sees it named a column that does not exist, rewrites the query, and runs it again.

That second behavior is the self-correcting agent loop at work. The agent noticed its own output was wrong and fixed it before anyone else had to. This piece breaks down how that works, the patterns behind it, and the cases where it quietly makes things worse.

TL;DR: A self-correcting agent loop checks its own output against explicit criteria while it runs, then revises when the check fails. It follows a generate, critique, revise shape with a retry cap. The hard part is the critic itself, which can miss the error or reinforce it.

What a self-correcting agent loop actually is

A self-correcting agent loop is an agent loop that inspects its own output mid-run and revises it when that output does not meet a standard you set. It does not return the first attempt by default. It generates, checks, and rewrites until the result passes or it runs out of tries.

The word that matters here is “own.” Plenty of systems have a human review step, or a separate approval stage. Self-correction is different: the same running loop produces the work and the judgment on that work, then acts on that judgment without waiting for a person.

That makes it a specific behavior, not a synonym for a careful agent. An agent that simply runs longer is not self-correcting. It becomes self-correcting only once there is a real check on its output and a real path to revise based on what that check found.

The underlying machinery is the ordinary agent loop: a model, tools, and a controller deciding what happens next. Self-correction is one job layered onto that loop, and it lives or dies on how honest the check is.

Self-correction is not an after-the-fact eval

This is the distinction people blur most, so it is worth being precise. Self-correction happens in real time, inside one execution, and changes the answer the user is about to get. An evaluation usually happens afterward, scoring a batch of finished runs to tell you how the system did.

Think of it as two different questions. Self-correction asks “is this specific output good enough to send, and if not, how do I fix it right now?” Evaluation asks “across the last thousand runs, how often was the output good?” The first is a live control step; the second is measurement.

Both use a check, and that is why they get confused. The difference is when the check fires and what happens next. A self-correction check fires before the output ships and triggers a rewrite. An eval check fires after and feeds a dashboard or a report.

You want both, and they support each other. The offline evals tell you whether your self-correction step is actually helping on real traffic, which is a question worth measuring rather than assuming, as this breakdown of self-reflection loops lays out. A correction step that fires constantly but never improves the output is just burning tokens.

General verification and stop conditions inside a loop are their own topic, covered by our what-is-loop-engineering piece. Here the focus is narrower: the correct-your-own-work step specifically.

Generate, critique, revise: the shape every version shares

Strip the names away and almost every self-correcting loop runs the same three beats. The agent generates an output, critiques that output against explicit criteria, and revises it based on the critique. Then it decides whether to stop or go around again.

The critique is the beat that does the work, and it needs something concrete to check against. “Is this good?” is too vague to act on. “Does this SQL run without error, and does it return the columns the question asked for?” is a criterion the loop can actually test and respond to.

The retry cap is the other non-negotiable part. Every self-correcting loop needs a hard limit on attempts, and you pick that limit from what an extra pass costs you, because each pass costs tokens and time. Without a cap, a loop that cannot fix its own error keeps trying forever, and the cost climbs with it.

Take a concrete before and after. On its first attempt an agent drafts a product description that invents a feature the source data never mentioned. The critique step checks the draft against the provided spec, flags the invented line, and the revise step rewrites the description using only the given facts.

That flagged-then-fixed cycle is the whole idea in one example. What changes between implementations is where the critique comes from and how much memory it carries between attempts.

The patterns behind self-correcting loops

The academic lineage here is worth knowing, because each named pattern adds one specific thing to the basic loop. Getting the attribution right also helps you pick the one that fits your task.

The base pattern is ReAct, which interleaves reasoning with tool calls so the model thinks, acts, and reads the result before its next thought (“ReAct: Synergizing Reasoning and Acting in Language Models,” Yao et al., arXiv 2210.03629). The observation from a real tool is an outside signal, which is what makes correction possible at all.

Reflexion adds a verbal self-critique the agent writes down and keeps in memory across attempts, so the next try is informed by a plain note on why the last one failed (“Reflexion: Language Agents with Verbal Reinforcement Learning,” Shinn et al., arXiv 2303.11366).

Self-Refine keeps it to a single output: one model produces a draft, critiques that draft, and rewrites, with no extra training (“Self-Refine: Iterative Refinement with Self-Feedback,” Madaan et al., arXiv 2303.17651).

The table shows the real split: some patterns critique using an outside signal, and some ask the model to grade itself. That split is exactly where self-correction gets risky, which is the next section. Related ideas like Tree of Thoughts and multi-agent debate extend the same instinct in other directions.

When self-correction makes things worse

Self-correction is not free upside, and the failure mode is specific. When the same model both writes the output and grades it, the critic shares the writer’s blind spots. An error the model could not see the first time is an error it often cannot see on review either.

That leads to two bad outcomes. In the first, the loop stays confidently wrong: the critique approves a flawed answer, and the extra pass just adds cost without adding correctness. In the second, over-correction, the loop rewrites an answer that was already fine and makes it worse, sometimes flip-flopping across attempts.

There is a sharper version of this. A critic that hallucinates can invent a reason the output is wrong, then “fix” a problem that never existed. Now the loop has degraded a good answer based on a made-up critique, and it did so with full confidence.

The fix is to give the critique an outside anchor whenever you can. A test that runs, a schema that validates, a tool result: any signal from outside the model beats the model’s own opinion of its work. Using a separate grader from the generator is the standard mitigation, so the critique does not just echo the writer.

When no outside signal exists, keep the retry cap tight and treat self-correction as a small boost, not a guarantee. Two attempts with an honest external check beat five attempts of a model reassuring itself.

A check that says why, not just pass or fail

Here is the detail that decides whether a correction loop can even function: the check has to say why it failed, not only that it failed. A bare pass or fail tells the loop to try again, but not what to change, so the retry is close to a blind reroll.

Compare the two. A check that returns “fail” gives the revise step nothing to work with. A check that returns “fail: the response cites a refund window of 30 days, but the policy says 14” hands the revise step the exact fix. The second is what turns a retry into a correction.

That reason is the load-bearing signal in the whole loop. A numeric score can gate an output, but it cannot guide a rewrite. Only a written critique carries enough detail for the next attempt to be better instead of just different.

So when you design the check for a self-correcting loop, spend the effort on making it explain itself. The quality of your corrections is capped by the quality of the reasons your check produces.

Where Future AGI fits

Since a correction step is only as good as the reason behind it, the eval you use has to carry that reason. This is the one place Future AGI touches the loop directly, and it is worth being exact about what it does and does not do.

Future AGI’s Agent Learning Kit (ai-evaluation, imported as from fi.evals import ...) returns an EvalResult for each check. That result holds the usual score in its output field, but it also carries a reason field with the judge’s own reasoning.

That reason is precisely the signal a correction step needs: not just that the output failed, but why. The correction logic itself is yours to write, and the eval supplies the critique it acts on. You can see the eval surface on the evaluate platform page.

There is also an offline analog, and the distinction matters. Future AGI’s agent-opt includes ProTeGi, a gradient-based optimizer that computes a “prompt gradient,” a critique of why a prompt failed, and uses it to generate improved prompt variants. The optimization docs cover how optimization runs in general.

But ProTeGi is not runtime self-correction. It is an offline optimizer over a dataset, called as optimizer.optimize(dataset, evaluator, initial_prompt, ...), that improves your prompt before you ship it. It does not sit in the live loop fixing individual outputs.

Keep the two apart. The reason field is what an in-flight corrector reads, while agent-opt is batch tuning you run ahead of time on a dataset.

Designing the correction step on purpose

Every self-correcting loop comes down to the same three beats: generate, critique, revise, with a hard cap on how many times it goes around. The shape is simple enough to add in an afternoon, which is part of why it gets added without much thought.

The honest version of the story is that the shape alone does not buy you much. A model grading its own work carries the same blind spots into the review, so the loop can approve a wrong answer or rewrite a right one. Extra attempts are not extra correctness.

What a correction step actually needs is an outside anchor and a reason. A test that runs, a schema that validates, a tool result: something that does not come from the model’s own confidence. And the check has to say why the output failed, because a bare verdict turns the retry into a blind reroll while a written reason turns it into a fix.

That is a design decision, not a default, and it is the same decision you face everywhere else in the loop: what the check is, what it returns, and when the loop is allowed to stop. If you are doing loop engineering, the correction step is one of the harder places to get those decisions right.