The Reflection Pattern: How AI Agents Self-Correct

What Reflection Solves

Language models produce their best output on the first attempt only when the task is simple and well-specified. For complex tasks, writing production code, conducting multi-source research, drafting legal or technical documents, the first output almost always has problems: missing edge cases, factual gaps, unclear reasoning, or structural weaknesses. Humans handle this naturally by reviewing their work, and reflection gives agents the same capability.

Without reflection, improving agent output requires either better prompts (which have diminishing returns past a certain point) or human review (which eliminates the automation benefit). Reflection creates a third option: the agent reviews its own work using a separate evaluation pass and fixes what it finds. This is cheaper than human review, more scalable, and often catches different types of errors than prompt engineering alone because the evaluation step can apply criteria that are difficult to encode in a generation prompt.

The academic foundation for reflection in agents comes from the Reflexion paper (Shinn et al., 2023), which demonstrated that language models can use verbal self-reflection to learn from mistakes within a single task episode. The model generates a solution, receives feedback (from a test suite, a validator, or its own evaluation), generates a reflection that identifies what went wrong and why, and then uses that reflection as additional context for its next attempt. The results showed significant improvement on coding, reasoning, and decision-making benchmarks, often matching or exceeding human-level performance after 2 to 3 reflection cycles.

Self-Reflection vs Critic-Agent Reflection

There are two fundamentally different ways to implement reflection, and the choice matters more than most developers realize.

Self-reflection uses the same model that generated the output to also critique it. The model is prompted with its own output and asked to evaluate it against specific criteria: correctness, completeness, clarity, edge case coverage, or whatever quality dimensions matter for the task. This is simple to implement, you just add a second model call with an evaluation prompt, and it requires no additional infrastructure. The weakness is that the model has a systematic bias toward its own output. It generated the solution, so it is predisposed to consider it correct. This bias is not universal, models can and do identify their own errors, but it means self-reflection catches fewer issues than an independent evaluation.

Critic-agent reflection uses a separate evaluation agent, potentially running a different model or the same model with a fundamentally different system prompt, to critique the output. The critic has no stake in the original solution and can be specifically instructed to be adversarial: find every flaw, question every assumption, test every edge case. This produces substantially better critiques. In practice, using GPT-4o to critique Claude's output (or vice versa) catches errors that neither model would catch in its own work, because each model has different blind spots.

The cost difference is meaningful. Self-reflection adds one model call per reflection cycle. Critic-agent reflection adds one call to a potentially different (and potentially more expensive) model. For tasks where quality directly affects outcomes, like code that will run in production or documents that will be reviewed by customers, the additional cost of critic-agent reflection is almost always justified. For internal or lower-stakes tasks, self-reflection provides most of the benefit at lower cost.

How Many Reflection Cycles

The optimal number of reflection cycles depends on the task, but the pattern of returns is consistent across domains: the first reflection produces the largest improvement, the second produces a meaningful but smaller improvement, and improvements after the third cycle are typically negligible. This happens because the most obvious errors are caught first, and each subsequent cycle works on increasingly subtle issues that contribute less to overall quality.

For code generation, two reflection cycles is the practical standard. The first pass generates the solution, the first reflection catches bugs and missing edge cases, and the second reflection catches code quality issues and optimization opportunities. Running the code's test suite between reflection cycles provides objective feedback that grounds the reflection, preventing the model from over-optimizing on subjective criteria at the expense of correctness.

For text generation (reports, articles, customer communications), one to two cycles is typical. More than two cycles risks the model making changes for the sake of changing something rather than making genuine improvements, a pattern sometimes called "reflection churn" where the model alternates between two equally valid approaches without converging on either.

The practical implementation is to set a maximum reflection count (usually 2 to 3) and also define a convergence criterion: if the reflection step identifies no significant issues, stop iterating regardless of the count. This prevents unnecessary cycles when the first attempt is already good, while allowing full iteration when the task is genuinely difficult.

Structured Reflection Prompts

The quality of reflection depends heavily on the evaluation prompt. A vague prompt like "review this and suggest improvements" produces vague feedback. A structured prompt with explicit criteria produces actionable feedback that the generation step can use to make specific improvements.

Effective reflection prompts share several characteristics. They specify the evaluation dimensions explicitly: correctness, completeness, efficiency, readability, edge case handling, security, or whatever matters for the task. They ask the model to rate each dimension, not just provide a pass/fail, because a rating forces the model to calibrate its assessment. They require the model to cite specific examples from the output that illustrate each issue, because specific citations are actionable while general commentary is not. And they ask for the model's confidence in each finding, because distinguishing between "this is definitely wrong" and "this might be improved" helps the generation step prioritize fixes.

A practical reflection prompt for code review might look like: "Evaluate this code on five dimensions: correctness (does it produce the right output for all valid inputs), edge cases (does it handle null, empty, and boundary values), efficiency (are there unnecessary computations or allocations), readability (are variable names clear and is the structure logical), and security (are inputs validated, are there injection risks). For each dimension, rate 1 to 5, cite specific lines, and state your confidence. Then provide a prioritized list of specific changes, most important first."

Reflection with External Feedback

The most powerful form of reflection combines the model's self-evaluation with external signals. For code, this means running tests and using test results as input to the reflection step. For data analysis, this means running validation queries and checking the results against known constraints. For customer-facing text, this means checking it against brand guidelines, readability scores, or compliance rules using specialized tools.

External feedback grounds the reflection in objective reality rather than the model's judgment alone. A model might look at its code and decide it handles edge cases correctly, but a test suite will prove whether it actually does. A model might consider its report comprehensive, but a checklist of required sections will expose gaps. The combination of model evaluation (which catches qualitative issues) and external validation (which catches objective errors) produces much better results than either alone.

This is where reflection connects to the broader LLM evaluation ecosystem. The evaluation tools and frameworks used to test LLM outputs in general, DeepEval, Ragas, LangSmith, are the same tools that can provide external feedback signals for reflection loops. The RAG evaluation guide covers techniques for evaluating retrieval quality that apply directly to evaluating agent actions that involve search and retrieval.

Reflection and Memory

Reflection becomes significantly more powerful when connected to a persistent memory layer. Without memory, each reflection cycle's insights are lost when the session ends. The agent learns to avoid a particular error in this task but repeats it in the next task because it has no mechanism to transfer that learning. With memory, reflections can be stored as learned procedures or general knowledge that the agent retrieves in future sessions.

Consider a coding agent that reflects on its output and discovers that it consistently forgets to handle the empty array case in JavaScript array methods. Without memory, it will forget this tendency and repeat the error next session. With a memory system like agent memory, the reflection can be stored as a self-correction rule: "When writing JavaScript array operations, always check for empty array input." The agent retrieves this rule in future sessions and avoids the error without needing another reflection cycle to discover it.

This connection between reflection and memory is what enables agents to genuinely improve over time rather than just improving within a single session. Each reflection cycle produces not only a better immediate output but also knowledge about common errors and effective solutions that the agent can reuse. The self-improving AI pillar covers the broader architecture of systems that learn from their own experience, and reflection is the mechanism that generates the learning signal.

When Reflection Does Not Help

Reflection is not universally beneficial, and knowing when to skip it saves cost and latency. Tasks with objectively verifiable outputs, mathematical calculations, database queries, API calls with binary success/failure, do not benefit from model-based reflection because the output is either correct or it is not, and running the operation is cheaper and more reliable than asking the model to evaluate it. Just run the test or check the result directly.

Reflection also adds limited value when the model is operating near the limits of its capability. If a model cannot solve a problem on the first attempt because the problem exceeds its reasoning ability, reflection will not help because the model lacks the capability to evaluate the solution correctly either. In these cases, a better model, better tools, or a different problem decomposition is needed rather than more reflection cycles on the same model.

Finally, reflection has diminishing value for highly constrained tasks where the prompt already specifies the output format, content, and quality criteria in detail. If the generation prompt is specific enough that the model produces correct output 95% of the time, adding reflection to catch the remaining 5% costs 100% more per task. At that point, it is usually cheaper to handle the 5% failure rate through retries or human review rather than doubling the model cost for every task.