Critic Agent Patterns: Useful Review Without Endless Rewrites

A critic is a second model pass over work a first pass produced, returning feedback rather than a verdict. It is one of the few multi-agent patterns that reliably earns its cost, and it is also one of the easiest to build in a way that quietly makes things worse.

The difference is almost entirely in what the critic is asked and what happens to its output. A critic given a vague mandate and an automatic revision loop will grind indefinitely on work that was already fine.

Critic and verifier are different components

A verifier answers a closed question against fixed criteria and blocks completion on failure. A critic answers an open one and produces suggestions.

Keeping them separate matters because only one of them can safely gate the loop. A critic can always find something to say, so a loop that continues until the critic is satisfied does not terminate for a good reason — it terminates when a limit fires. Verifier agents covers the gating half.

The practical arrangement is a verifier that blocks and a critic that advises, with an explicit rule about which critic feedback is acted on. Without that rule, the critic effectively becomes the gate by accident.

Narrow mandates beat broad ones

Asking a critic to review a diff produces a list of generic observations: consider adding error handling, consider a comment here, this could be extracted. The list is plausible, applies to almost any code, and is largely worthless.

Narrow the mandate to a single dimension per critic and the output changes character. A critic asked only whether the diff introduces a behaviour change not requested by the task finds real regressions. A critic asked only whether error paths leave state consistent finds real bugs.

Several narrow critics run in parallel produce better feedback than one broad critic and cost roughly the same, because each one is reading the same diff with a different question. Choose the dimensions from the defects you actually see in review. Code review automation covers picking them.

Give the critic what a reviewer would need

A critic seeing only the diff is reviewing with less context than any human reviewer, and its output shows it.

Supply the original task, so it can check that the change addresses the request rather than something adjacent. Supply the surrounding code for the functions touched, so it can tell a convention from a mistake. Supply the test results, so it stops reporting problems that the suite already covers.

Do not supply the author's reasoning. Inheriting the justification for a decision makes the critic much more likely to accept it, which removes the independence that made the second pass worth running. Agent self-correction covers why that independence matters.

Severity is what makes the output usable

Unranked feedback forces a downstream decision about what to act on, and an agent handed a flat list will attempt all of it.

Require a severity on every item and define the levels concretely. Blocking means the change is incorrect and must not ship. Worth fixing means a real defect that is not urgent. Optional means preference. Then act only on blocking items automatically and pass the rest to a human.

Require evidence too: the file and line, what is wrong, and what would be correct. An item that cannot cite a location is usually a generic observation dressed as a finding, and requiring the citation filters most of them out without any additional logic.

Approving is a valid result

A critic that never approves is not being rigorous, it is responding to a prompt that implies problems exist.

Say directly that most changes under review are acceptable and that returning no findings is a normal outcome. Ask for an overall verdict before the itemised feedback, so the model commits to a position rather than assembling one from whatever it happened to list.

Then measure it. If your critic returns blocking findings on nearly everything, it is miscalibrated and the loop is paying for rewrites of correct work. A critic that blocks a small minority of changes is behaving like a reviewer. Evaluating agent reliability covers checking the rate.

Where a different model helps

Running the critic on the same model that produced the work is the cheapest arrangement and the weakest, because the two share failure modes. A mistake the generator was prone to making is a mistake the critic is prone to overlooking.

A different model family diversifies the blind spots, and the effect is noticeable on subtle defects. It does not need to be a stronger model — reviewing against explicit criteria is a narrower task than generating a correct implementation. Best model for code review covers the selection.

The cost is real: a critic pass roughly doubles the spend on the reviewed step. That is easy to justify before a pull request and hard to justify on every intermediate edit, which is the right place to draw the line.

Where critics do not belong

Do not add a critic to a workflow with a good deterministic check available. Tests, type checkers and schema validation are cheaper, faster and not subject to persuasion.

Do not add one to a task where correctness is not the constraint. If the failure mode is that the agent is slow or expensive rather than wrong, a review pass makes both worse.

And do not use a critic to compensate for an underspecified task. Vague instructions produce work that is hard to evaluate, and the critic will generate volume rather than signal. Fixing the task specification is cheaper than reviewing its consequences. Multi-agent systems and when they help covers the broader question.