ModelRefs / Agent Reflection — AI Glossary

Agent Reflection — AI Glossary

A pattern where an agent critiques its own outputs or reasoning to identify errors and self-correct before finalizing.

Overview

Reflection (also called self-critique) adds a dedicated review step: the agent generates an answer, then evaluates it against a rubric, and revises if needed. Substantially improves accuracy on tasks with verifiable correctness. Powers evaluator-optimizer agent workflows.

Reference details

Topicagents
Last reviewed2026-06-24

How it works

  1. An initial answer is produced, then a second pass evaluates it against stated criteria, then a third revises it if the critique found problems.
  2. Separating generation from criticism is the mechanism: the critique pass is not committed to the first answer's framing and is prompted to look for specific failure classes rather than to judge generally.
  3. Criteria quality determines the result. A rubric naming concrete checks produces actionable critiques, and a general instruction to review produces agreement with the original.
  4. An external signal transforms it. A test suite, a validator, a retrieval check or an execution result gives the critique something to be right or wrong about, rather than asking the model to detect its own errors from the inside.
  5. Without an external signal the loop is bounded by the model's own blind spots: an error it could not see when generating is usually an error it cannot see when critiquing, since both passes share the same weights.
  6. The cost is multiplicative in model calls, so the pattern is worth it only where the accuracy gain exceeds the tripled spend — which makes it a routing decision rather than a default.

Example: Pricing the extra calls against the recovered tasks

A single-pass answer is one model call. Generate, critique, revise is three — so the pattern triples the calls for every request it is applied to. Suppose it lifts task success from 70% to 85% across 10,000 tasks. The gain is 10,000 x (0.85 - 0.70) = 10,000 x 0.15 = 1,500 recovered tasks, and the cost is 10,000 x 2 = 20,000 additional calls, which is 20,000 / 1,500 = 13.3 extra calls per recovered task. Whether that is worth paying follows directly: if a failed task costs a human intervention worth far more than 13 model calls, it is clearly positive; if a failure costs a user clicking retry, it is not. The arithmetic also argues against applying it uniformly. Reflecting only on the requests likely to fail — flagged by low confidence, by a validator, or by a cheap classifier — applies the 2 extra calls to a much smaller set: at 3,000 flagged requests capturing most of the 1,500 recoverable ones, the cost is 3,000 x 2 = 6,000 calls, or 6,000 / 1,500 = 4 per recovered task, a 3.3x improvement in efficiency from targeting rather than from any change to the reflection itself.

Commonly confused with

Reflection and verification are different in a way that decides whether the pattern works. Verification checks an answer against something outside the model — tests that run, a schema that validates, a retrieved source that agrees — so it can detect errors the model cannot see. Reflection asks the same model to evaluate its own output, so it shares the blind spots that produced the error. This is why reflection reliably improves tasks with a verifiable component and shows much weaker and less consistent gains on tasks where correctness is a judgement, and why a reflection loop with no external signal often just agrees with itself at triple the cost.

When to use it

Reach for it when:

  • Tasks with an external signal — code that must run, output that must validate, claims that must match a source.
  • Targeted at requests likely to fail rather than applied uniformly, which is where the cost efficiency is.
  • With concrete criteria naming specific failure classes, since a general review instruction produces agreement.
  • Where a failed task is expensive relative to a handful of model calls.

Reach for something else when:

  • Without an external signal on tasks where correctness is a judgement, where the loop shares the blind spots that caused the error.
  • Applied to every request, which triples the cost on the majority that would have succeeded.
  • With a vague review instruction, which produces self-agreement rather than critique.
  • In latency-sensitive paths, since the pattern adds two sequential model calls to the critical path.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Agent Reflection — AI Glossary.

Frequently asked questions

What is Agent Reflection?

A pattern where an agent critiques its own outputs or reasoning to identify errors and self-correct before finalizing.

What concepts are related to Agent Reflection?

Closely related concepts include agent, agentic loop, eval.