The Reflection Pattern | TechByteByByte

What You Will Learn

How self-review and revision work.
Why criteria matter.
How stopping rules prevent endless revision.

How to read the evidence

The $0.02 to$ 0.08 figures are transparent arithmetic: four calls at $0.02 equal$ 0.08. The 60% / 25% / 5% error-catching curve comes from a secondary article and is that source’s heuristic, not a universal law. Choose reflection depth using a task-specific evaluation curve.

Every pattern so far has been about getting to an answer. Reflection is about what happens after — a closed loop where the agent generates something, judges it against concrete criteria, and revises before anything ships.

The architecture

Generate
 ↓
Inspect own result
 ↓
Identify problems
 ↓
Revise
 ↓
Evaluate again

The loop repeats until the output passes, or hits an explicit limit. That limit is worth taking seriously from the very first sentence of this module, because the honest research on this pattern has a genuinely important catch most casual treatments skip entirely.

The catch the tutorials skip

This is worth stating precisely, because it’s the single most important thing to know before building this pattern at all: “an agent grading its own homework usually agrees with itself.” (Taskade, Self-Improving AI Agents)

This isn’t a bug you can prompt your way around. A model asked to critique output it just generated has a genuine, structural bias toward validating that output: “An LLM that generates a text, then is immediately asked to correct it, suffers from a known bias: it tends to validate what it just produced. This is not a malfunction — it is a property of the generation process.” (Labo LLM, Reflection and Self-Critique)

Read this precisely. This isn’t the model being lazy or careless. It’s an inherent property of asking the same reasoning process to both produce something and judge it — the same instincts, the same training, the same blind spots that shaped the original answer are exactly what’s now being asked to find fault with it.

Two different shapes, with a trade-off

Self-reflection — one model handles both drafting and critique, in the same or a fresh call. Cheaper, faster, simpler to wire up — and it shares blind spots across both roles, exactly the bias above.

Producer-Critic — two distinct roles: one agent generates, a genuinely separate agent critiques, ideally running a different underlying model. This separation “eliminates a structural bias in self-revision” (Labo LLM) — at the real cost of an extra call and genuine orchestration overhead.

The deciding question, stated as plainly as the research states it: how costly is a missed error? (Taskade) A low-stakes summary can tolerate self-reflection’s shared blind spots. A production SQL query touching real data, or code that will actually run, genuinely warrants paying for a separate critic.

Applying this to a concrete scenario

It’s worth walking through a genuine decision using this module’s own question, rather than leaving it abstract. Consider two tasks: drafting an internal weekly summary email, and generating a database migration script that will run against production data.

The weekly summary’s worst realistic failure is mild — an awkward sentence, a slightly off tone, something a reader might not even notice. Self-reflection is a genuinely reasonable choice here: even with its shared-blind-spot bias fully intact, the cost of a missed error is low enough that the cheaper, faster option clearly wins.

The migration script is a different case entirely — a missed error here means real data corruption or a failed deployment, the kind of consequence Module 16 of your Multi-Agent Systems coursework already quantified in terms of real production incidents. This is exactly the case that warrants paying for a genuinely separate critic agent, ideally running a different underlying model, specifically because the two roles sharing the same blind spot is a risk this task’s actual stakes can’t absorb.

Concrete example

It’s worth seeing this pay off in a genuinely simple, verifiable case. Real research found that when an LLM was asked to generate SQL queries directly, it got 70% right. Adding a single reflection step — the model reviewing and refining its own query — pushed accuracy noticeably higher, specifically by catching syntax errors the first pass had missed. (StackViv, Agent Reflection: How AI Agents Self-Improve)

Notice why this case is a genuinely good fit for even the cheaper self-reflection shape: syntax errors are objectively checkable. The model doesn’t need to overcome its own bias about whether the query’s logic was sound — it just needs to notice a syntax error that either exists or doesn’t, a task self-critique is genuinely well-suited to even with the bias above still technically present.

Cost of this pattern

This is worth knowing in exact numbers, not a vague sense that “reflection costs more.”

Every reflection iteration multiplies inference cost linearly. A base agent call costing $0.02 becomes at least$ 0.08 for a three-iteration reflection loop — one generate, one evaluate, one revise, one final evaluate. At 10,000 queries a day, that’s the difference between $800 a day and$ 200 a day. (Build MVP Fast, AI Agent Self-Improvement)

That’s a real, four-fold cost increase for the same daily volume — worth having in mind precisely before defaulting to reflection on every request rather than routing it selectively, the same restraint principle Module 3 already argued for routing decisions generally.

The exact shape of diminishing returns

It’s worth knowing this precisely rather than as a vague warning, because the real numbers are genuinely striking: iteration 1 catches roughly 60% of errors, iteration 2 catches another 25%, iteration 3 catches maybe 5%. After that, “you’re burning tokens for nothing.” (Build MVP Fast)

This is corroborated independently: LangGraph’s own production guidance states returns diminish sharply after 2 to 3 iterations for code generation and summarization tasks specifically, though research-heavy or analytical domains sometimes genuinely benefit from a fourth pass. (SitePoint, Agentic Design Patterns 2026) Most real implementations run 2 to 5 cycles in practice. (StackViv)

Combine this with the cost math above and the real engineering conclusion is precise: the third iteration of a reflection loop costs the same as the first, but catches roughly a twelfth as many errors. A hard iteration cap isn’t a compromise — it’s the point where the pattern’s own measured economics say to stop.

Degeneration of thought

This is worth knowing as a distinct, named failure mode, not just “reflection sometimes doesn’t help.” Degeneration of thought happens when an agent keeps reinforcing the same flawed reasoning during self-critique rather than finding a genuinely new approach — the model gets stuck in a fixed pattern and rationalizes its original mistake instead of correcting it. (StackViv)

This is directly the self-validation bias from earlier in this module, now shown compounding across iterations rather than appearing just once. One real, concrete mitigation: multi-agent reflection with diverse critic personas — a skeptic, a logician, a creative thinker — each bringing a genuinely different lens rather than the same model re-examining its own work from the same angle repeatedly. (StackViv)

Stopping criteria

It’s worth knowing the concrete options rather than leaving “when to stop” vague: a maximum iteration count, a quality threshold score, or a no-progress check that halts the loop if consecutive rounds show no measurable improvement. (StackViv) Without an explicit ceiling, reflection loops can genuinely cycle indefinitely, burning tokens without improving output at all. (SitePoint)

How to evaluate whether a reflection loop is working

This is worth knowing precisely, because “does reflection help” is an empirical question this module’s own sources answer with a concrete measurement methodology, not just intuition.

Score every input twice against the same rubric — once on the pre-reflection draft, once on the post-reflection output — and report three real numbers: the pre-vs-post delta per case (lift on cases that started wrong, drift on cases that started right), the over-correction rate (the percentage of already-correct answers the loop made worse), and the cost-per-improvement (extra tokens and seconds spent per point of quality gained). (FutureAGI, Evaluating LLM Self-Reflection Loops)

That over-correction rate is worth taking seriously as its own honest warning — this module’s self-validation bias doesn’t only mean the model sometimes fails to fix a real error. It can also mean the model “fixes” something that was never actually broken, hedging away real specificity in an answer that was already correct.

The research frontier worth knowing about

It’s worth briefly naming where reflection’s grounding problem is actively being worked on, even though this is genuinely research territory rather than settled production practice. Process reward models (PRMs) are trained specifically to score each individual step of a reasoning trace, not just the final answer — giving a critique step a genuinely dense, learned signal to work from, rather than the model’s own unaided judgment about whether its work is correct.

This doesn’t eliminate the self-validation bias described above — a PRM is still a model making a judgment, not a deterministic test — but it’s a real, current direction for making that judgment more grounded than pure self-critique alone.

The rule that sets up the next module

It’s worth closing on this, because it directly frames Module 8: “if you can run a test, run the test. Save intrinsic critique for the soft, subjective polish that no test can capture, and even then, hold it on a short leash.” (Taskade)

This is worth stating precisely as the real boundary between this module and the next. Reflection, as covered here, is fundamentally about a model judging its own or another model’s output using its own reasoning. When the judgment can instead come from something objective — a passing test, a schema validator, a compiler — that’s genuinely a different, more reliable pattern, covered next: Evaluator-Optimizer.

What this looks like in code

Before reading the syntax, follow the execution flow: identify the incoming state, the component making the decision, the function doing the work, and the condition that returns a result or stops the loop. The code is a small teaching model of the pattern, not hidden framework magic.

def reflect_and_revise(task: str, max_iterations: int = 3, quality_threshold: float = 0.85) -> str:
    output = generate(task)

    for i in range(max_iterations):
        critique = self_critique(output, task)

        if critique.quality_score >= quality_threshold:
            break

        revised = revise(output, critique.issues)

        if similarity(revised, output) > 0.98:
            break  # no-progress check — stop wasting tokens on a stuck loop

        output = revised

    return output

The similarity check is the concrete, code-level answer to degeneration of thought — if a revision barely differs from what it’s replacing, the loop is very likely rationalizing rather than genuinely correcting, and continuing further iterations would just be paying the linear cost this module already quantified for no real benefit.

Interview-relevant framing

Q: Why can’t a model reliably catch its own mistakes through self-reflection alone?

Ans: Because of a genuine, structural bias, not a fixable prompting issue — a model asked to critique output it just produced tends to validate that output, since the same reasoning patterns that generated the answer are what’s now being asked to find fault with it. This is why the Producer-Critic shape, using a genuinely separate agent for critique, breaks that shared blind spot — at the real cost of an extra call. The right choice depends on how costly a missed error actually is for the specific task.

Q: How would you decide how many reflection iterations to allow in production?

Ans: By the pattern’s own measured economics, not a fixed default. Real data shows iteration one catching roughly 60% of errors, iteration two another 25%, iteration three maybe 5% — while each iteration costs the same, linearly. A three-iteration loop can cost four times a single call, so capping around two to three iterations for most tasks is where the actual return on that cost drops off a cliff, not an arbitrary limit.

Q: What’s the real difference between reflection and evaluator-optimizer?

Ans: Reflection uses the model’s own reasoning to judge quality — inherently subjective, and inherently biased toward validating its own prior output. Evaluator-optimizer replaces that judgment with something objective wherever possible — a test, a validator, a compiler. The honest engineering rule: if you can run a test, run the test, and reserve reflection for genuinely subjective polish no test could capture in the first place.

Common Misconception

Incorrect idea: Self-critique creates an independent reviewer.

Why it is incorrect: The same model can repeat its original blind spots. External tests or a separate evaluator provide stronger independence.

Key takeaways

Reflection is a closed generate-critique-revise loop, but it carries a genuine, structural bias — a model tends to validate output it just produced, which is a property of the generation process, not a fixable prompting mistake.
Self-reflection (one model, both roles) is cheap but shares blind spots; Producer-Critic (a genuinely separate critic agent) breaks that bias at real, added cost — the right choice depends on how expensive a missed error would actually be.
A real SQL generation study found reflection improving accuracy noticeably above a 70% baseline, specifically by catching objectively-checkable syntax errors — the kind of case self-reflection genuinely suits.
The real, precise cost is linear and significant: a three-iteration reflection loop can cost roughly four times a single call, turning $200 a day into$ 800 a day at real production volume.
Returns diminish in a measured, specific shape — roughly 60% of errors caught in iteration one, 25% in iteration two, 5% in iteration three — after which further iterations cost the same but catch almost nothing.
Degeneration of thought is a named failure mode where self-critique reinforces rather than corrects a flawed answer; diverse critic personas are a real, concrete mitigation.
A genuine evaluation methodology exists for reflection loops specifically: measure the pre-vs-post quality delta, the over-correction rate (already-correct answers made worse), and cost-per-improvement — not just whether output looks better after the loop.

Module 8 covers what happens when that judgment stops being the model’s own subjective critique and becomes something genuinely objective instead: Evaluator-Optimizer.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026