Reflection: the agent grades its own work
Lesson 3 of 4 in Single-Agent Patterns: ReAct, Plan-Then-Execute, Reflection.
The third pattern adds a stage after generation: critique the output, then revise it. In its simplest form the same model reviews its own draft (“check this answer for errors, then improve it”). Stronger variants use a separate critic prompt or a different model as judge, and the most agentic variant — Reflexion-style — has the agent write down lessons from a failed attempt into memory and retry the whole episode with those lessons in context.
Reflection is seductive because it feels like rigor for one prompt’s worth of effort. Sometimes it is. The honest version of this lesson is a ledger with two columns — and the variable that decides which column you land in is whether the critique has access to information the generator didn’t already use.
Where reflection measurably helps: when an external verifier exists. Test suites, compilers, schema validators for structured outputs, a retrieved document the claim can be checked against, a rule the output demonstrably violates. The critique step then translates a hard signal into a targeted revision — this reliably beats regenerating from scratch on coding and constraint-satisfaction tasks.
Where the evidence is mixed at best: intrinsic self-correction — asking the model to re-examine its own reasoning with no new information. Huang et al. (arXiv:2310.01798, ICLR 2024) tested exactly this on reasoning benchmarks and found models often failed to fix wrong answers and sometimes talked themselves out of right ones. Results vary by task and model, and the literature is genuinely unsettled — but as of 2026 you should treat “just add a reflection pass” as a hypothesis to test, not a best practice to assume. Each pass roughly doubles token cost and latency; it has to buy measurable quality on your task, which is what evals are for.
Code generation with a test suite — will reflection pay?
Almost certainly. Failing tests are the gold-standard external signal: unambiguous, cheap to run, impossible for the model to rationalize away. This is the Reflexion setting, and it is where the pattern earned its reputation.
Math or logic reasoning with no checker — will reflection pay?
The evidence says: don’t assume so. This is the intrinsic self-correction setting Huang et al. tested — no new information enters, and models fixed wrong answers about as often as they broke right ones. If the task matters, build a checker (even a partial one, like verifying arithmetic with code) instead of adding a second opinion from the same weights.
Output must satisfy a schema or style guide — will reflection pay?
Usually, because the rubric is checkable. A validator or even a checklist prompt (“does the JSON parse? are all required fields present?”) gives the critique something concrete to push against. The closer the critique is to mechanical verification, the better it works — and the more you should ask whether plain code could do the check instead of a model.
A generic “double-check your answer before responding” instruction — will it pay?
Mostly it burns tokens. No verifier, no new information, no targeted signal — just the same model, warmer. You may see small gains on some tasks and small losses on others; you will definitely see roughly double the cost. If you ship it anyway, ship it behind an eval that proves it earns its latency.
A different model as critic (LLM-as-judge) — will it pay?
Sometimes — measure it. A second model breaks some correlated blind spots and is genuinely useful for rubric-based review at scale. But judges carry documented biases and agree with each other more than independence would predict. Treat judge verdicts as a noisy signal to calibrate against a golden dataset, not as ground truth — the evals domain covers exactly how.
Key terms: reflection, self-critique, external feedback, LLM-as-judge, eval
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.