AI · Agent Systems
The single biggest quality and cost improvement I've found isn't better prompting or a bigger model. It's structural: having one agent review another agent's work, in a separate context, with no knowledge of how the first agent reasoned. A builder and a critic. The reviewer is cheap not because it's smart — but because it knows what not to say.
June 2026
Ask an AI agent to write a function, then immediately ask it to review that same function in the same session. You'll mostly get agreement. It won't find the off-by-one error it just introduced. It won't notice the missing null check it glossed over. It already committed to that code. Its context is saturated with the reasoning that produced it.
This is not a prompting problem. You cannot prompt your way around the fact that the model is reviewing its own output through the same lens it used to produce it. The assumptions that led to the implementation carry forward into the review. You don't get a second opinion — you get a politely rephrased version of the first one.
There's a subtler problem too: most models are architecturally inclined to avoid contradicting themselves. Criticizing your own output requires an adversarial stance that the model's training actively discourages. The output sounds critical — “I'll add a null check here” — but it rarely surfaces the class of bug that a genuinely independent reviewer would catch.
In 2023, an MIT CSAIL team published a paper with a remarkably simple idea: have multiple language models discuss and debate questions, then converge on a shared answer. Each agent generated an initial response, then read and critiqued every other agent's response, then revised its own. After several rounds, a majority vote produced the final answer. The result: significantly better accuracy on reasoning tasks, and a measurable reduction in hallucination.
The mechanism is straightforward but powerful. When an agent knows its output will be scrutinized by a peer, it produces better work. When it then reads a critique from a different model — with different training data, different blind spots, different priors — it sees gaps it could not see on its own. The collective output consistently beats any single model working alone.
This has since been replicated across dozens of papers. Google DeepMind built it into their Co-Scientist system, where specialized agents generate, debate, and evolve hypotheses. The Mixture-of-Agents framework showed that chaining multiple models where each layer refines the previous output can achieve state-of-the-art results using only open-weight models. The pattern is robust: independent agents producing judgments that a separate process aggregates produces consistently stronger signals than any one agent produces alone.
The implementation pattern is simpler than the theory suggests. It comes down to three rules:
1. Split the roles. One agent builds. One agent reviews. They are never the same agent, never in the same conversation, and never share context beyond the output being reviewed.
2. Withhold the reasoning. The reviewer sees only the output — the code diff, the trading analysis, the architectural proposal. It does not see the builder's prompts, intermediate thoughts, or chain-of-thought. This forces genuinely independent evaluation.
3. Use different models when you can. Claude and GPT make different kinds of mistakes. A bug one model overlooks is often obvious to the other. The adversarial dynamic between different architectures produces a genuinely wider coverage of edge cases.
In the OpenClaw ecosystem, this maps to a sessions_sendpattern. The builder agent completes its work, packages the output as a structured message, and sends it to a reviewer agent in a completely separate session. The reviewer has no access to the builder's history. It evaluates only the artifact in front of it. The reviewer's feedback comes back as a structured response — issues found, severity ratings, suggested fixes — which the builder can incorporate in a new iteration, or a human can adjudicate.
In practice, I run this pattern daily. Frank (the builder agent) produces infrastructure code, agent configurations, and deployment pipelines. Morpheus (the reviewer) evaluates each output for correctness, edge cases, security, and consistency. The trader agents do the same thing for market analyses — one generates the thesis, another pressure-tests it. The cross-review catches things neither agent would catch alone, and the structured feedback format means the loop can iterate without human attention unless something critical surfaces.
The objection I hear most often is that multi-agent review doubles your compute cost — two runs instead of one, two sets of tokens instead of one. That math is correct on the surface. It is wrong where it actually matters.
The real cost of an LLM call lives in the output tokens, not the input. Processing a prompt is a fixed cost — the model pays it whether you ask it to write a function or to review one. The variable cost is everything it generates after the first token. A builder agent producing two thousand tokens of code is expensive because of those tokens. A reviewer agent producing two hundred tokens of structured critique — “three issues found, two medium severity, suggest fix for the null-pointer path” — is cheap because the output is short. The savings come from generating fewer tokens, not from thinking harder.
This opens a design space that most people miss: you do not need the same model for the reviewer. A 70B builder generating production code can be reviewed by an 8B quantized local model running on a seven-hundred-dollar GPU. The smaller model does not need to produce the output — it only needs to identify problems in it. And identifying problems is a fundamentally cheaper task than producing solutions, both in output length and in the capability required.
The pattern that actually works: use a capable (expensive per token) model for the builder. Use a fast, cheap, possibly local model for the reviewer. The reviewer generates fewer tokens and runs on cheaper hardware. The total cost of the two-run loop can be less than a single run of the builder with self-review, because self-review produces the same output length again with no new signal.
This is the real argument for multi-agent review. Not just that two heads are better than one — but that the second head should be a different kind of head, running on different hardware, optimized for saying very little that matters a lot.
Multi-agent review is not a free lunch. It comes with costs and failure modes that need to be engineered around.
Coordination tax. Every handoff between agents adds latency. A single agent can produce an answer in one pass. A builder + reviewer loop takes at least two full agent runs, plus the overhead of structured communication. For routine tasks — a simple CRUD endpoint, a straightforward data pipeline — this overhead outweighs the benefit.
Sycophancy. If the reviewer agent is configured to be “helpful and agreeable,” it will find nothing wrong. The research literature calls this “stance homogenization” — agents converge toward agreement instead of productive disagreement. The fix is explicit: the reviewer's system prompt must frame its role as adversarial. “You did not write this code. Your job is to find problems.”
The deliberation trap. Some papers have found that multi-agent debate does not always outperform a single well-prompted model, especially when computational budget is controlled. Agents can talk each other into wrong answers. A confident but incorrect reviewer can steer a correct builder off course. The solution is a human adjudicator or an explicit termination rule: iterate at most N times, then escalate.
Multi-agent review shines in specific conditions: high-stakes decisions (deployments, financial trades, security-sensitive code), complex multi-domain problems where different expertise is needed, and situations where the cost of being wrong is high enough to justify the 2x+ latency.
For everything else — a one-shot script, a draft email, a quick data query — a single capable agent with good prompting is faster and cheaper. The mistake is applying multi-agent review universally. The right approach is selective: use it where the signal matters most, skip it where the stakes are low.
Use multi-agent review
Skip it
The frame that's helped me most: think of single-agent output as a first draft. It's good. It's often great. But for the work that matters — the work that goes public, touches money, or changes how a system runs — a first draft is not enough. You need a reviewer who didn't write it, who doesn't know how the writer thought, and whose only job is to find what's wrong.
The best review comes from someone who didn't write the code. That principle has been true in software engineering for decades. It turns out to be true in the agent era too — you just have to build the wall yourself.