The Iterative Refinement Pattern

What You Will Learn

How feedback improves an artifact.
How related refinement patterns connect.
How to detect diminishing returns.

How to read the evidence

The 80% to 91% HumanEval and more than 30 percentage-point claims are repeated through a secondary article rather than linked here to the original experiment. Keep them as reported results, but do not transfer them automatically to another model, language, validator, or production repository.

This module owes you an honest clarification before anything else, because pretending this is a third, unrelated pattern from Reflection and Evaluator-Optimizer would be a disservice to what you’ve already learned.

The relationship

Iterative Refinement is the umbrella concept. Reflection and Evaluator-Optimizer are both specific instances of it, not three separate patterns.

The real, academic lineage is worth knowing precisely, because it makes this relationship concrete rather than asserted. Self-Refine (Madaan et al., 2023) is the actual research paper behind what Module 7 called Reflection: “A single agent generates, critiques, and refines using the same model in alternating turns.” The two-agent Evaluator-Optimizer is described directly as “the multi-agent generalisation of self-refine” — the critic role handed to a genuinely separate agent instead of the same one alternating roles. (AgenticOrgChart.com, Evaluator-Optimiser Agent Pattern)

This is worth taking seriously as this module’s actual thesis, not a footnote: you don’t need to learn a third mechanism here. You need to understand the family — what varies between its members, and how to choose the right member for a given task.

This is worth connecting directly to your Multi-Agent Systems coursework’s own restraint principle, applied at this smaller scale: adding formal structure — a separate evaluator agent, episodic memory across attempts — is a real, deliberate trade, not something to reach for automatically just because a more sophisticated-sounding pattern exists. The simplest family member below is often the genuinely correct choice, not a placeholder to graduate away from.

The simplest possible shape

Draft
 ↓
Improve
 ↓
Improve
 ↓
Improve
 ↓
Final

This is the family’s most stripped-down member — no formal generator/evaluator role split, no explicit rubric, sometimes not even a distinct critique step at all, just continuous polishing until a stopping condition is met. This is worth knowing as a genuine, legitimate choice for tasks where the overhead of Module 8’s explicit PASS/FAIL rubric isn’t warranted, but a single pass still isn’t quite good enough.

Third, distinct family member

It’s worth knowing one more real, named variant beyond what Modules 7 and 8 already covered, because it adds something genuinely new rather than just relabeling the same idea. Reflexion (Shinn et al., 2023) is a single-agent variant that adds episodic verbal-feedback memory across attempts — framed by the original researchers as “verbal reinforcement learning.” (AgenticOrgChart.com)

The genuine difference from Self-Refine, worth being precise about: Self-Refine’s critique-and-revise happens within one attempt at one task. Reflexion carries lessons across separate attempts — if a first attempt at a task fails, the verbal reflection on why it failed gets stored and fed into a genuinely new attempt, not just a revision of the same draft. This matters specifically for tasks where an agent might retry an entire episode from scratch, not just polish one continuous piece of work.

Measured evidence for the whole family

It’s worth grounding this family’s value in real, precise numbers, because the underlying research is consistent across sources on the actual magnitude of the effect.

Research cited by Redis.io found self-critique alone — the Module 7 shape — lifting HumanEval coding benchmark accuracy from 80% to 91%. Combined with external validators — actual test runners, not just the model’s own judgment, exactly Module 8’s territory — the same research found gains exceeding 30 percentage points. (Towards AI, The 7 Design Patterns Every AI Agent Developer Should Know in 2026)

This is worth reading as direct, quantified confirmation of the exact distinction Module 8 already argued: self-critique alone genuinely helps, and pairing the same underlying loop with an objective, external check helps substantially more — the same family, with meaningfully different real-world payoffs depending on which member you choose.

Choosing the right family member

This is worth a genuine, practical decision framework rather than treating every variant as interchangeable:

Situation	Right family member
Quick polish, low stakes, cost-sensitive	Simplest shape — draft, improve, improve, final, no formal roles
Self-contained task, quality is the bottleneck, moderate stakes	Self-Refine / Reflection (Module 7) — one model, alternating roles
High stakes, objective criteria exist (tests, schemas, rubrics)	Evaluator-Optimizer (Module 8) — genuinely separate evaluator
Task involves distinct, retriable attempts, not just continuous polish	Reflexion — episodic memory carried across separate attempts

The real, honest engineering question underneath all four rows is the same one Module 7 and 8 both already asked: how costly is a missed error, and can the judgment be made genuinely objective? This module’s real contribution is showing that question applies consistently across the entire family, not differently to each member.

Why this honesty matters practically, not just academically

It’s worth being direct about why this module opened with a clarification rather than a fourth mechanism, because there’s a real, practical cost to treating these as unrelated. A team that learns “Reflection,” “Evaluator-Optimizer,” and “Iterative Refinement” as three independent patterns risks implementing the same underlying idea three separate times across a codebase — a self-critique loop here, a generator-evaluator pair there, a polish loop somewhere else — each with its own retry logic, its own iteration cap, its own cost tracking, none of them sharing infrastructure because nobody recognized they were building the same family member repeatedly.

The practical payoff of understanding the real relationship: a single, well-built iteration-loop abstraction — with a configurable role split (zero, one, or two agents), a configurable episodic memory option, and the shared diminishing-returns and cost-tracking logic this module already covered — can serve every row of the table above. That’s a genuinely different engineering outcome than building four separate, redundant loops because the names suggested four separate problems.

Diminishing returns, as a property of the whole family

It’s worth restating Module 7’s exact numbers here, because they’re not specific to self-critique alone — they describe this entire family’s shared economics. Iteration one catches roughly 60% of errors, iteration two another 25%, iteration three maybe 5%. Cost, meanwhile, scales linearly (Module 7) or as roughly 2N× a single generation for the two-agent Evaluator-Optimizer variant specifically, since each round pays for both a generator and an evaluator call. (AgentPatterns.ai, Evaluator-Optimizer Pattern)

A genuinely useful, honest engineering signal worth knowing: a generator that makes only marginal improvements per iteration should trigger a redesign of the feedback format, not an increase in the round limit. (AgentPatterns.ai) If more iterations aren’t producing meaningfully better output, the fix is rarely “iterate more” — it’s that the critique itself isn’t specific or actionable enough to actually drive improvement, regardless of which family member you’re running.

What this looks like in code

This is worth showing specifically for Reflexion, since it’s the one genuinely new mechanism this module introduces beyond Modules 7 and 8:

def reflexion_attempt(task: str, max_attempts: int = 3) -> str:
    episodic_memory = []

    for attempt in range(max_attempts):
        context = task + "\n\nLessons from prior attempts:\n" + "\n".join(episodic_memory)
        result = generate(context)

        if verify(result, task):
            return result

        # Verbal reflection on *why* this attempt failed, stored for next attempt
        lesson = reflect_on_failure(result, task)
        episodic_memory.append(lesson)

    return escalate_for_review(result, episodic_memory)

Notice episodic_memory accumulates across genuinely separate attempts, not within one continuous revision — this is the concrete, code-level difference from both Module 7’s single-pass critique loop and Module 8’s generator-evaluator loop, neither of which carries a verbal lesson forward into a fresh attempt the way this does.

Applying this to a concrete scenario

It’s worth running the decision table above against a genuinely realistic case, since the four rows can feel abstract without one. A team is building an agent that writes and submits pull requests against a real codebase, with CI tests as the actual pass/fail signal.

The first PR attempt fails CI. This is worth recognizing precisely: it’s not a case for the simplest polish loop — a failing test isn’t a stylistic rough edge to smooth over, it’s an objective failure with an objective cause. It’s also not quite a Self-Refine case either, since the agent’s own subjective read of “does this look right” was never the actual bottleneck — the CI run already told it definitively that something was wrong. This is squarely Evaluator-Optimizer territory: the CI system is a genuinely separate, objective evaluator, and the agent’s revision should be driven by the specific test failure output, not a self-generated critique.

Now extend the scenario: the agent’s second attempt at the same underlying feature also fails, but for a genuinely different reason than the first attempt did. This is where Reflexion’s real value shows up, distinct from a single Evaluator-Optimizer loop — carrying forward a verbal lesson like “the first attempt failed because it didn’t handle the null case; watch for that pattern in related code” into the next full attempt is genuinely different from simply re-running the same generate-evaluate loop with no memory of what specifically went wrong before.

A team building this system well would combine both: Evaluator-Optimizer within each attempt, Reflexion-style memory carried across attempts that fail for structurally different reasons.

Interview-relevant framing

Q: Is Iterative Refinement a different pattern from Reflection and Evaluator-Optimizer, or the same thing?

Ans: It’s the family they both belong to, not a separate third pattern. The actual research literature describes Evaluator-Optimizer directly as ‘the multi-agent generalisation of self-refine’ — self-refine being the academic name for what’s commonly called Reflection. Understanding this relationship matters more than memorizing three separate names, because the real engineering decision is which specific configuration — no formal roles, single-agent self-critique, a separate evaluator, or episodic memory across attempts — actually fits a given task’s stakes and cost tolerance.

Q: What does Reflexion add that Self-Refine and Evaluator-Optimizer don’t have?

Ans: Memory that persists across genuinely separate attempts, not just revisions within one continuous draft. If an agent’s first full attempt at a task fails, Reflexion stores a verbal reflection on why it failed and feeds that into a fresh attempt — framed by the original researchers as verbal reinforcement learning. This matters specifically for tasks structured as discrete, retriable episodes, where the value isn’t polishing one draft, it’s genuinely learning from a failed attempt before trying again from scratch.

Q: If more reflection iterations aren’t improving output, what’s usually actually wrong?

Ans: Usually the feedback format, not the iteration count. A generator making only marginal improvements per round is a real, honest signal that the critique isn’t specific or actionable enough to drive genuine change — the fix is redesigning what the evaluator actually returns, not raising the round limit and paying more for the same weak signal.

Common Misconception

Incorrect idea: More refinement rounds always improve an answer.

Why it is incorrect: Later rounds may repeat wording, introduce errors, or spend cost without measurable improvement.

Key takeaways

Iterative Refinement isn’t a third, separate pattern — it’s the umbrella family that Reflection (Module 7) and Evaluator-Optimizer (Module 8) both belong to, confirmed directly by the research literature describing the latter as “the multi-agent generalisation” of the former.
The simplest family member has no formal roles at all — draft, improve repeatedly, stop — a legitimate, lower-overhead choice when Module 8’s explicit rubric-and-threshold structure isn’t warranted.
Reflexion adds something genuinely new: episodic verbal-feedback memory carried across separate, discrete attempts, not just revisions within one continuous piece of work.
Real, measured research shows the family’s value precisely — self-critique alone lifting HumanEval accuracy from 80% to 91%, and pairing the same loop with external, objective validators pushing gains past 30 percentage points.
Choosing the right family member depends on the same question Modules 7 and 8 already established: how costly is a missed error, and can the judgment be made genuinely objective for this specific task.
Diminishing returns and linear-to-quadratic cost scaling apply across the whole family, not uniquely to any one member — a generator producing only marginal gains per round signals a feedback-format problem, not a reason to raise the iteration cap.

Module 10 shifts from perfecting one piece of output to coordinating genuinely different pieces of work across specialized agents — the other pattern Anthropic’s own research names as top-tier, alongside Evaluator-Optimizer: Orchestrator-Workers.

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