Also known as: self-critique, self-evaluation, self-refine, reflexion
Reflection is the agent self-evaluation pattern: produce an answer, evaluate it against the goal or known criteria, refine if needed. It catches errors that one-shot generation misses, at the cost of extra tokens and latency.
Reflection (sometimes called self-critique, self-refine, or Reflexion) is the pattern of having a model evaluate its own output and revise it. The basic shape: generate an answer, then prompt the model (or a separate evaluator) to critique it, then optionally regenerate using the critique as feedback. Over multiple rounds, errors that one-shot generation produced get caught and corrected.
Recognition is often easier than generation. A model that produces a buggy line of code might fail to write it correctly first try, but happily flag the bug if shown the code with a “review this” prompt. Same for arithmetic mistakes, missed cases in plans, ungrounded claims against retrieved context. Reflection exploits this asymmetry.
It also exploits a different sampling trajectory: the second pass starts from a different prompt (the original output plus a critique request), so the model isn’t anchored on its first chain of thought. Self-consistency aggregates multiple parallel samples; reflection is the sequential cousin.
A model and its critic share the same parametric memory and the same blind spots. If the model generates “the capital of Australia is Sydney” because that’s what its weights weakly encode, it will also affirm that fact when asked to verify — the critic uses the same recall mechanism that produced the error. Self-critique gains traction only when the critic prompt unlocks a different reasoning path: “list all reasons this might be wrong” steers the model toward error-search behavior the original prompt didn’t, similar to chain-of-thought activating different intermediate computations. Empirically, the lift from same-model critique is measurable but capped at 2-3 rounds before diminishing returns hit hard. Cross-model critique (different family, different training data, different blind spots) consistently beats same-model — error correlations across model families are weaker, so the critic is more likely to flag the generator’s mistake. Tool-grounded critique (running the code, executing the SQL) beats both — there’s no model bias to share with anyone.
Naive reflection runs on every output and roughly doubles cost. Selective reflection runs only when a cheap confidence signal flags risk — a calibrated reranker score for retrieval grounding, a verifier head, a distilled-classifier output. This recovers most of the quality lift at a fraction of the cost.
Cheap signal triggers expensive reasoning. The right reflection architecture is selective, not blanket.
It improves quality on tasks where the model can recognize errors it can't avoid producing — coding, math, multi-step planning, factual grounding against retrieved context. It does not help on tasks where the model is equally wrong about the answer and the critique (subjective writing, common-sense judgments). Empirically: useful where there's an external check or a clear criterion.
Different model often beats same model — error correlations are weaker across model families. The cheapest reflection setup that consistently beats no-reflection is 'big model generates, small specialized model critiques against criteria.' The big-with-itself loop also works but has diminishing returns past 1-2 rounds.
Naive reflection roughly doubles latency and token spend per turn. Selective reflection — only run the critique when a confidence signal flags risk — recovers most of the win at a fraction of the cost. The confidence signal can be a calibrated score from a specialized model rather than the LLM itself.
