An agent that executes a task and delivers the result without reviewing it has the same reliability as a developer pushing straight to production with no tests. The reflection pattern is, in essence, that verification step applied to agents.
Reflection (or self-critique) is an architectural pattern where, after an agent generates a result or completes an action, a separate step -- either the same model in another call, a different model, or a dedicated sub-agent -- evaluates that result against explicit criteria before treating it as final. If the evaluation finds a problem, the agent revises and retries; if not, the result gets delivered.
The key difference from "asking the model to review its own work in the same response" is that reflection happens in a separate context, with a different goal (critique, not generate) and often with a different model or effort level dedicated exclusively to that evaluation.
When you ask the same model, in the same generation pass, to "review its work before answering," the model tends to confirm its own reasoning -- the same bias that makes it hard for a human to find their own typos. Separating the critique into a distinct call, with a prompt focused solely on finding flaws (not on producing the result), breaks that confirmation bias.
The most common mistake when implementing reflection: asking the evaluator to "check if this is good" with no explicit criteria. This produces inconsistent evaluations that sometimes approve bad results and sometimes reject good ones. The evaluation needs a rubric -- concrete criteria, each independently verifiable.
Vague criteria ("is it well written?") produce noisy evaluations. Specific, verifiable criteria produce evaluations you can trust to automatically gate whether something gets retried or delivered.
In agents that execute actions (API calls, database writes, system changes), reflection must verify the action's effect, not just the generated text. An effective pattern: after an action with side effects, the agent runs a verification step that reads the resulting state and confirms it matches what was expected -- before reporting success to the user.
This extra step, on an agent that deletes records, sends emails, or modifies configurations, is the difference between "the agent said it did it" and "the agent confirmed it actually happened."
Reflection at least doubles the cost and latency of every task -- it isn't free, and not everything justifies the spend. Apply the same "is the agent worth it?" criteria you'd use for any architecture decision:
- **Cost of the error:** if an error is easily caught and fixed afterward (a typo in a draft), reflection adds little value. If an error is expensive or hard to reverse (a transaction, a message sent to a customer), reflection pays for itself. - **Task complexity:** for simple classification or deterministic extraction, the reflection step rarely finds anything worth the extra cost. - **Volume:** in high-volume pipelines, consider reflecting on only a sample percentage of outputs (for quality monitoring) instead of 100%, if reflecting on everything is prohibitively expensive.
Without an explicit limit, a generate-critique-revise cycle can spin indefinitely on a genuinely ambiguous or impossible-to-satisfy task. Define an explicit `max_iterations`, and have a clear exit path when it's exhausted -- never a silent, bottomless loop.
The reflection pattern works best combined with the other techniques in this series -- not as a substitute for them. Well-structured context (precise RAG) reduces the need for reflection by minimizing errors at the source; explicit calibration instructions (having the model admit uncertainty) reduce false "approvals" at the critique stage; and a versioned regression set (from the versioned-prompts article) tells you whether the reflection step itself is degrading over time.
Well implemented, the reflection pattern isn't generically "making the agent think twice" -- it's building a second pair of eyes with explicit criteria, separate from the first generation step, exactly where the cost of the error justifies it.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel