A critic that thinks like the worker is barely a critic.
Adding a reviewer doesn't magically create independent evidence. Useful criticism needs a different job, a different frame or a different way of looking at the result.
The standard fix for flaky agent output is to add a critic. One model makes the thing, another judges it, the first one revises. It's simple, easy to explain and often useful. It's also very easy to fake without meaning to.
If the critic gets the producer's framing, thinks with the same model, checks against a vague rubric and can't actually reject anything, the second call might just restate the first one in a judgier tone. You've doubled your inference bill and kept the original blind spot.
In Restless, producer and critic are responsibilities you can use, not stages you have to go through. A critic has to earn its place by producing evidence or judgement the producer couldn't cheaply get on its own.
Review isn't the same as independence
A worker can review its own output and catch the obvious stuff. Asking it to reread a function after a test fails is cheap and sensible. Self-review gets weaker when the mistake is baked into how the worker framed the problem in the first place: it solved the wrong problem really neatly, picked a flattering source, or treated a visual preference as a product fact.
A second agent can inherit the same framing before it even sees the work. The producer's explanation tells the critic what to look at and why each choice was reasonable. Shared system prompts and model habits make them even more alike. Two answers aren't independent just because they came in separate messages.
Independence comes from the evidence and the framing. A page actually rendering in a browser can contradict confident-looking code. A primary source can contradict a polished summary. A separate test company can reveal wording that leaked across, which the design team stopped noticing ages ago. A critic is worth having when it brings one of those genuinely different views.
Start from the goal, not the explanation
The critic should first get the intended outcome, the agreed constraints, the exact thing to review and what convincing evidence looks like. That way it meets the work the way the reviewer or user will. The producer's reasoning can stay available for later, but it shouldn't get to shape the critic's first impression.
This matters a lot for design and writing. Explanations are persuasive. A weak visual can sound inevitable once its creator explains the concept behind it. Dense copy can sound clever when every sentence gets defended one at a time. Reviewing the real thing asks whether it works before asking why it was made that way.
For code, the equivalent is reproducing it. Run the test. Use the actual interface. Look at what happens when it fails. A summary of checks isn't the check. The critic should be able to disprove the producer's claims with evidence that exists outside the producer's story.
A rubric can make everyone blind in the same way
Rubrics make reviews comparable. They also decide what can't be seen. If every critic scores the same seven things, problems outside those seven become invisible by design. A high total can hide one fatal flaw, and precise-looking numbers can hide uncertainty about what the work was even meant to do.
Restless uses success criteria and evidence rules to make standards explicit, but they're still contextual. One serious rule can fail the work no matter how good the overall score is. Open-ended review can name a new problem and explain why the rubric missed it. The evaluation should learn from things it keeps missing, rather than treating the rubric as finished.
So the strongest critic combines a known standard with permission to question that standard. It checks what the company expected, and also asks what a smart sceptic would notice that the company didn't.
A critic needs teeth
Review that can't change the outcome is just commentary. If a critic spots unsupported claims but the producer can mark the work done without changing anything, the role only exists for show. The review has to feed a real decision: accept, reject with specific evidence, ask for a revision, or escalate a disagreement that needs your judgement.
That power should be narrow, though. A critic doesn't quietly rewrite the work and then approve its own version. It names the problem, attaches evidence and hands responsibility back to the producer or the accountable lead. That keeps track of who did what and lets the next attempt fix the actual problem.
A good rejection changes the work. One of our early acceptance rules put it bluntly: a producer and critic pass had to cause at least one meaningful revision, not just two model calls where the second one nodded along.
One live run showed both the value and the mess
In one of our company-identity test runs, a control group cheaply produced a multi-channel asset package without bringing in an independent critic. The first treatment group did bring in a critic, which rejected two revisions for made-up product proof, overclaiming how independent the review was, and unsupported voice or authorship claims. Those were real problems.
But the treatment's company computer was out of date and had only loaded the company's Truth, leaving out Voice, Visual Language and Culture. So the comparison couldn't honestly say the critic improved quality. We kept the pair as evidence of a failure instead of reporting an improvement.
After fixing the computer and starting from a clean slate, the treatment loaded all four identity pillars. Three review rounds removed a made-up timeline, a founder placeholder, and "we" language in interface copy. The worn-out path was replaced with a narrowly scoped provenance editor and a fresh critic, which accepted the final package. Counting the failed branches and repairs, the treatment cost several times what the control did.
Different critics catch different things
There's no universal critic. An automated test is great for a rule you can write down and useless for tone. A reviewer looking at the real page sees layout and interaction but might miss a false fact underneath. A domain expert can judge consequences while missing the implementation drifting. A different model might bring useful variety, or just a different taste.
Match the critic to the risk. Reproduce capability claims. Check factual claims against primary sources. Attack security boundaries on purpose. Look at the real thing for experience quality. Ask the owner for taste and strategy. Only combine critics when their evidence is genuinely different.
That stops you building a committee around every piece of work. Independence costs briefing, catching up, waiting and sorting out disagreements. The problem you expect to catch has to be worth it.
- Ask what blind spot this critic is supposed to cover.
- Give it direct access to the thing under review and the relevant sources.
- Don't make the producer's reasoning the first thing it reads by default.
- Make sure review can change an acceptance decision, the work itself, or a claim about evidence.
Agreement can be a warning sign
Quick agreement feels efficient. It might mean the work is obviously good. It might also mean the roles aren't independent enough, the rubric is too shallow, or the critic didn't have the time and tools to actually look. A system that rewards agreement will learn to produce agreement.
Disagreement isn't automatically useful either. Critics can invent objections, over-index on taste or drag work on past the point where it's worth it. The accountable lead has to decide whether the new evidence changes the outcome. The critic owns the scrutiny. It doesn't own the project forever.
Useful review shows its working, whether it agrees or not. It points to the work, the standard and what actually happened. That lets the company tell a real quality signal apart from a style squabble.
The real question is what the second mind can see
Adding a critic is an organisation design decision. It creates another responsibility boundary and uses another context window. That can be worth it for independent evidence, when accepting something wrong would be costly, for specialist expertise, or when the producer has an incentive to stop early.
It's not worth it just because a diagram says every producer needs a reviewer. Sometimes the best critic is a compiler, a customer, a screenshot or a receipt from the provider. Sometimes self-review plus an automatic check is enough. Sometimes the owner needs to see the exact result.
The point isn't to make the worker feel watched. It's to make it harder to fool the acceptance step. A critic earns its place when it can see a problem the producer was structurally unlikely to see, and when the company is actually willing to let that evidence change the work.