The Critic

In one line: the component that made something is the worst possible judge of it, and a separate one is the cheapest structural improvement available.

Why separation works

The single-agent chapter established that a model asked whether its own step was good will say yes, because it generated the step and its justification in the same breath. Self-assessment is the component under evaluation grading itself.

A separate critic breaks that. It did not produce the work, so it has no commitment to it, and it evaluates the output rather than defending the process.

That makes verification the strongest of the four decomposition conditions. Unlike the others, which trade coordination cost for a capability gain, this one buys something structurally unavailable to a single agent — and it is why the published failure taxonomy putting verification failures at around a fifth of all multi-agent failures is worth reading twice: even in systems that have critics, the checking is frequently the thing that broke.

The critic needs an edge

The condition that makes it real rather than decorative: the critic must have something the producer did not.

A critic with the same context, the same prompt and the same model is an expensive re-roll. It will mostly agree, its agreement will be read as confirmation, and the system will be more confident and no more correct — the independence illusion from the previous lesson, wearing a job title.

Four things that constitute a genuine edge:

The acceptance criteria, and not the reasoning. The critic sees what good looks like and the output, but not the chain that produced it. It cannot be persuaded by a justification it never read.

Tools the producer lacked. A critic that can run the code, resolve the citation, or query the source is checking against reality rather than against plausibility. This is the strongest edge available.

The original request. A critic holding the user's actual words can catch the framing failure that a sub-task-level check cannot — the case where every worker succeeded and the decomposition was wrong.

A different objective. The producer was asked to complete; the critic is asked to find fault. That asymmetry alone changes behaviour, and it is the cheapest of the four.

What to check

Ordered from most to least reliable, and a critic should work down this list rather than starting at the bottom.

Mechanical checks. Does the schema validate, does the citation resolve, does the code run, is the number in range. Deterministic, cheap, and they catch a surprising share. These should not be a model call at all.

Consistency checks. Does the output contradict its own inputs, or another worker's result. Also largely mechanical.

Criteria checks. Does it satisfy the stated acceptance criteria. A model call, and a well-defined one.

Judgement. Is it any good. The weakest and most expensive, and the one people build first.

The design point: most of what a critic should do is not a model call. A critic that begins with "is this good?" has skipped the checks that actually work.

Rejection, and what follows

A critic that only rejects is half a component. What it returns determines whether the system can recover.

What failed, specifically. Not "insufficient quality" but the criterion that was not met.

Whether it is fixable. A missing citation is fixable by the producer; a wrong decomposition is not, and telling the producer to try again wastes a cycle.

A bounded retry. Retry once with the critique attached, then escalate. Unbounded critic-producer loops are one of the most reliable ways to burn a budget, because the critic can always find something.

That last point is worth dwelling on. A critic asked to find fault will find fault, indefinitely. Without a hard limit, a producer-critic pair is a loop with no termination condition — the same failure as any other loop, in a shape that looks like diligence.

Where to put it

Three placements, and they catch different things.

Per worker output. Catches a bad result before it becomes a downstream premise. This is where containment happens, and it is the most valuable position.

On the assembled result. Catches framing failures — everything correct, assembled wrongly — which is the only place that failure is visible.

On the decomposition, before any work. Cheapest of all, and rarely done: check that the sub-tasks actually add up to the goal before spending on execution. Given that specification is the largest failure category, checking the specification first is an obvious move that almost nobody makes.

The full configuration is all three, and the marginal value ordering is per-worker first, assembled second, decomposition third — although the third is by far the cheapest, so a system on a budget might reasonably start there.

The honest limit

Two things a critic cannot do, worth stating so the design does not over-rely on it.

It cannot verify what it cannot check. A claim with no source, no tool to test it and no criterion to measure it against is not verifiable by another model — it can only be found plausible, which is what the producer already did.

It shares the producer's blind spots where they share a model. Systematic errors a model makes are errors the same model does not notice. A genuinely different model, or a mechanical check, is the only escape.

Which brings it back to the edge: a critic is worth its cost exactly to the extent that it knows or can do something the producer could not.

Next: who decides the whole thing is finished.