Pattern Matrix/White Paper/F1

F1 · Generator-Critic

What problem it solves

Tasks dense with subjective judgment have no single correct answer, only a quality spectrum—writing, design, code style, product copy, and academic abstracts all fall into this category. A cheap model often misses on the first attempt, but a human writer rereads a finished piece three times, revising on each pass, and stops when the marginal return drops. This ability to "look back and improve" is what determines output quality, and a single generation cannot deliver it.

Generator-Critic encodes this process into an agent: the generator writes a draft, the critic looks back and finds problems, the generator revises with that feedback, and the loop continues until the critic is satisfied or the iteration cap is hit. It is the simplest engineering implementation in the reflection module, established by the 2023 Reflexion paper and still the industrial baseline for reflection patterns in 2026—Self-Refine achieves about a 20% absolute improvement on average across 7 tasks, with no training data required.

Why the coordinate is "Reflection × Chain"

• Vertical axis · Reflection: The critic is the agent examining its own output, letting the agent criticize itself, which is the most classic form of reflection. It introduces no new agent and retrieves no external knowledge; the entire act of looking back happens inside the same reasoning process.
• Horizontal axis · Chain: Its skeleton is a three-step linear pipeline of generate → critique → revise, one role per step, each with its own prompt, feeding the previous step's output into the next. This chain can be replayed and run for several rounds when needed, but iteration is not its mandatory structure—forced looping is the domain of the Self-Heal Loop (F4). The essential boundary between F1 and F4 lies exactly here: F1 starts from chained refinement where "the output is usable, but could be better," while F4 starts from a forced loop where "the output is already broken and must be fixed."

Core mechanism

A Generator-Critic loop consists of three segments:

1. Generate: The generator produces a draft. The model used in this step determines how much the critic has to make up for.
2. Critique: The critic evaluates the current output and produces a structured verdict (an issues list / severity / an explicit no_changes_needed field). The key innovation of the Reflexion paper is that the critic produces natural-language reflection text rather than a bare score, telling the generator what is wrong, why it is wrong, and how to fix it next time.
3. Revise: The generator rewrites with the critique in hand. It then returns to step 2, until the critic passes the output or iteration bottoms out.

The reliability of the critic is the linchpin of the whole loop. Its sources fall into three classes in order of increasing reliability, and which one to choose depends on whether the task has a deterministic signal:

Production scenarios it fits

• Content-generation tasks: Writing, translation, summarization, copywriting, polishing academic abstracts—no objective right or wrong, but a clear quality difference, where the critic can reliably spot "where it falls short."
• Code style and readability optimization: Naming, comments, structural adjustments, and similar improvements that do not affect correctness but do affect quality.
• High-frequency tasks backed by a cheap model: Use a cheap model as the generator, let the critic lift quality to an acceptable line, and keep overall cost far below going straight to an expensive model.

Where it tends to go wrong

• Forcing it in the Reflection-Light domain: For tasks where a human can tell right from wrong at a glance and an objective criterion exists (math problems, SQL, unit-test results), using the test or schema directly as the critic is far more accurate than letting the LLM evaluate itself, and wrapping it in Generator-Critic is the long way around.
• A critic weaker than the generator: When the critic model lacks capability, it cannot spot real problems and instead introduces noise, and the loop degrades the more it runs. The critic must be at least the same tier as the generator, or stronger.
• A critic that forces problems into existence: If the critic prompt does not state that "no changes needed is a valid option," it will invent problems to fill the quota. On MBPP, Reflexion measured a 16.3% probability of the critic flagging errors in already-correct code; adding a line like "if it already qualifies, output no changes needed" cuts this rate substantially.
• No guard against same-source bias: When the critic and generator are the same LLM, a self-enhancement bias exists, and it tends to score its own output highly. High-stake tasks should switch vendors or add external grounding.
• No circuit breaker on iteration: Not setting max_iterations triggers over-thinking—the critic keeps inventing on top of the previous round's fabrications, and after a few rounds the agent convinces itself that the output is severely flawed.

Key metrics

• Critic convergence rate (healthy zone: converges within 2-3 rounds): Failing to pass after more than 3 rounds indicates that the critic's standard is miscalibrated or the generator lacks capability.
• Phantom-issue rate (healthy zone: <10%): The proportion of already-qualified outputs the critic flags as having errors. Above 15% indicates the critic prompt lacks a "no changes needed" exit.
• Critic-vs-expert agreement rate (healthy zone: >70%): Sample 50-100 critic outputs each week and compare them against expert judgment. Below 70% calls for rewriting the critic prompt or switching models.
• Quality increment (healthy zone: 5-15% higher than a single generation): Below 3% means reflection had no effect; above 25% means the generator's single-call configuration itself is the problem, so fix the generator first.

Minimal implementation skeleton

output = generator(task)
            for i in range(MAX_ITERATIONS):       # MAX=3, same-source circuit breaker à la Aider
                if external_critic:               # prefer a deterministic signal when present
                    critique = external_critic(task, output)
                elif multi_critic:                # multiple roles in parallel + arbitration
                    critique = merge(critic(task, output, role=r) for r in roles)
                else:
                    critique = critic(task, output)
                if critique.no_changes_needed:    # valid exit, guards against phantom issues
                    return output, "converged"
                output = generator(task, previous=output, feedback=critique)
            return output, "max_iterations_reached"   # hand off to HITL when bottomed out
            

Four engineering essentials: the critic prompt must explicitly state that no_changes_needed is a valid option; when a deterministic signal such as a test, schema, or citation database is present, prefer the external critic; do not casually raise max_iterations, as 3 is the empirical optimum; and keep the full history on file as the source data for critic calibration.

Enterprise deployment example

An academic publisher's paper-abstract polishing agent completed its first version with a single prompt ("please optimize this abstract"), and offline evaluation gave it an average editorial score of 8.2/10. The second version added a Generator-Critic loop ("after writing, review it yourself, find 3 improvement points, then optimize"), and the average score instead dropped to 7.4—a trace review found that the critic was over-revising, rewriting concise abstracts into verbose ones, and all three issues were fabricated. The third version changed three things: adding "if it is already well written, output no changes needed" to the critic prompt cut the phantom-issue rate from 16.3% to 7%; introducing a 3-role multi-critic (academic rigor / conciseness / terminology accuracy) that evaluated in parallel and then arbitrated, where the terminology critic was external-grounded and queried a citation database to verify that the cites in the abstract actually existed; and sampling 50 critic outputs each week against expert judgment to calibrate the prompt. After the fixes, the average score rose to 8.9, 0.7 above the first-version baseline, at the cost of a 2.8× increase in per-call token cost. Abstracts are high-stake content, so the trade-off is worth it.

Relationship to other patterns

• Self-Heal Loop (F4): A sibling pattern, and the boundary must be nailed down. Generator-Critic is "improve after generating," starting from a usable output, with the loop serving quality improvement and replay being optional; Self-Heal Loop is "repair after failure," starting from a broken output, with the loop being a mandatory structure. The former is for subjective tasks, the latter for tasks with a deterministic failure signal.
• Adversarial Review (collaboration module): An upgraded form. Generator-Critic is "the same model with a different prompt," while Adversarial Review is "an independent agent with adversarial incentives." The former addresses "how an agent revises itself," needing only one LLM process and two prompts; the latter addresses "how a decision passes audit-grade independent review," requiring model routing, an independent trace, and cross-agent orchestration, at about 9× the token cost. Use the former when the cost of error is low, and upgrade to the latter for scenarios that demand regulatory independence, such as financial approval or medical diagnosis.
• Skill Package (F2): A connecting relationship. Generator-Critic revises this one current output, while Skill Package distills the successful process across tasks.

What this pattern teaches

The essence of Generator-Critic is not "adding a reviewer," but making explicit an asymmetry that software engineering has relied on for decades—that evaluation is simpler than generation—letting the same model use the "easy" (evaluation) to constrain the "hard" (generation) in reverse.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.