Multi-agent content review: how generator and critic agents work

A model that writes a blog post and then reviews its own draft is checking its work against the same assumptions that produced it. If it misread a source or miscounted a stat while drafting, that error rides along into the review, because nothing about the setup gives the model a reason to see it differently the second time. This is the structural problem underneath the fact-checking and governance work we have already covered on this blog: the mechanics of catching a bad claim and the audit trail that proves a human signed off both assume something else is doing the checking. This post is about what that something else actually is: a generator, critic, and judge running as separate agents, and where that pattern itself can fail if you build it carelessly.

Why a single model reviewing its own output doesn't catch its own mistakes

A model reviewing its own draft isn't running an independent check, it's re-reading its own reasoning and calling that verification. Two separate bodies of research explain why that fails in different ways: one on how the model judges quality, the other on how it tries to fix errors.

Self-preference bias: a model's own judge favors familiar text, not correct text

When an LLM is used to judge or score text, it tends to rate outputs that resemble its own style or its own family's outputs more favorably, regardless of whether the content is actually better. A 2026 study testing this across 20 mainstream LLMs used as judges found self-preference bias is common, and that more capable models are not necessarily less biased: the researchers state that advanced capability is "often uncorrelated, or even negatively correlated," with lower bias. Their proposed mitigation, a structured evaluation strategy that decomposes the judging task instead of asking for one holistic score, cut the bias by 31.5% on average, which is itself the tell: fixing this took a deliberate change to how the review is structured, not a better model (arxiv.org/abs/2604.22891).

Put plainly: if the same model that wrote a paragraph also grades it, that grade is partly a measure of "does this sound like something I'd write," not "is this true." Swapping in a differently-prompted persona inside the same context doesn't fix it either, because the underlying pull toward familiar phrasing and reasoning patterns is still there.

Self-correction research: models rarely improve their own reasoning without outside feedback

A separate line of research asks a narrower question: even setting aside bias, can a model catch and fix its own reasoning errors if you just ask it to try again? A 2023 study from Google DeepMind and UIUC, published at ICLR 2024 under the title "Large Language Models Cannot Self-Correct Reasoning Yet," found that current LLMs struggle to self-correct their responses without external feedback, and performance can even degrade after a self-correction attempt (arxiv.org/abs/2310.01798). The paper also compares multi-agent debate, where models critique each other's answers, against simply sampling several independent solutions and picking the best one: the gains from debate tracked how different the sampled answers were from each other, not any distinct critiquing ability, and those gains disappeared once there was no external label telling the system which answer was actually right.

That last point matters more than it looks. It means a review step only earns its keep when it's actually independent, pulling in outside signal, whether that's a different model, a different context, or a real source to check against, not when it's the same reasoning wearing a different hat.

The generator, critic, and judge pattern

The fix implied by both findings is architectural: don't ask one context to write and grade its own work. Split the roles, and make the split real, not cosmetic. Andrew Ng, describing this as the reflection design pattern in DeepLearning.AI's The Batch, put it simply: "I've found it convenient to create two different agents, one prompted to generate good outputs and the other prompted to give constructive criticism of the first agent's output." A third role, a judge, decides what to do when the critic flags something.

This isn't a theoretical pattern. Anthropic's own multi-agent research system runs a version of it in production: a Claude Opus 4 lead agent orchestrating Claude Sonnet 4 subagents outperformed a single-agent Claude Opus 4 setup by 90.2% on Anthropic's internal research eval (anthropic.com/engineering/multi-agent-research-system). That gain came from giving the subagents what Anthropic describes as "separation of concerns, distinct tools, prompts, and exploration trajectories, which reduces path dependency and enables thorough, independent investigations." The same logic applies to reviewing a draft: a critic that can't inherit the generator's blind spots has to start from a genuinely different vantage point, not just a different system prompt in the same conversation.

Generator: drafts grounded in retrieved sources, not memory

The generator's job is to draft, and it should draft from sources it actually fetched during that session, not from what it recalls having read somewhere. We've already covered why grounding narrows the hallucination rate without closing it entirely in our piece on the editorial review workflow, so this post won't re-run that ground. The relevant point here is narrower: whatever the generator gets wrong is exactly what the next two roles exist to catch, so the generator's job is to draft well, not to also be its own safety net.

Critic: an independent pass, no shared context, scored against a rubric

The critic's defining property is that it starts cold. It reads the finished draft and the original sources with no memory of how the draft was produced, which is what makes it able to catch a misread source the generator was structurally blind to in its own review. Anthropic's system scores critic output against a fixed rubric, factual accuracy, citation accuracy, completeness, source quality, and tool efficiency, and found that a single LLM call outputting one score from 0.0 to 1.0 plus a pass or fail grade was the most consistent method with human judgment, more consistent than more elaborate scoring schemes. Simpler grading, run independently, beat complicated grading run by the same context that wrote the draft. The critic's actual checklist, pulling every claim and link out of the draft and confirming each one, is the same mechanical work we detail in our AI content fact-checking piece; the point of this section is who runs it, not what it checks.

Judge: the tie-breaker that decides whether a claim ships

A critic that flags an issue still needs someone, or something, to decide whether the flag is a real blocker or a false alarm. That's the judge role: sometimes a distinct model call, sometimes the same rubric-scoring step Anthropic describes above, but conceptually separate from "did the critic notice something" versus "does that something actually stop the post from shipping." This is also where the pattern gets more fragile than it looks. A 2026 preprint studying a two-agent debate setup, a Constructor that generates and an Auditor that critiques, plus an LLM judge, found the Auditor's own confidence in its critique was a much less reliable predictor of real reasoning failures than the Constructor's confidence in its original answer (arxiv.org/abs/2606.10296). In plain terms: the generator being unsure of itself is a good signal that something's actually wrong. The critic being confident is a weaker signal that it's actually right. A judge that just defers to whichever agent sounds more certain will defer to the wrong one more often than intuition suggests.

Where hallucination propagates if the roles aren't actually independent

Every failure mode above has the same shape: an error surviving because two roles that were supposed to check each other ended up agreeing instead of disagreeing. That happens whenever the split is cosmetic, a critic prompt bolted onto the same conversation as the generator, a judge that's really just the critic asking itself "am I sure," or a critic pulled from the same model family and prone to the same self-preference pull the bias research above describes. The result is an echo chamber that looks like a review process: two calls happened, a score got produced, and the wrong fact shipped anyway because nothing in the setup actually introduced an outside perspective. A generator/critic/judge pipeline earns the name only when each role runs on a genuinely separate context, ideally checked against real, fetched sources rather than another model's opinion of the draft.

What a checkpoint-based review loop looks like when a human only steps in at the end

Three independent agent roles still produce a stream of findings somebody has to act on. The way to make that manageable isn't one giant review at the end, it's checkpoints along the way that a human can skim instead of re-deriving.

Checkpoints, not one big review: line comments as the interface between agents and a human

The critic's findings should land as comments tied to specific lines in the draft, not a wall of prose in a chat window that's gone in thirty days. That's a deliberate structural choice, and it does double duty: it's also how the same comments become a permanent, named audit trail once the post ships. Each comment is a discrete checkpoint the generator agent can act on and resolve, which is what turns "review the whole post" into a queue of small, addressable items.

Iterate and re-check, don't just fix and ship

A fix to one flagged claim can silently break something two sections away, a rephrased stat, a swapped source, a link that pointed somewhere else before the edit. The loop has to re-run the critic and judge passes after every revision, not just once before the first draft goes out. We've covered the specific triple-check shape this takes, fact-check, link-check, re-check, in the editorial review workflow post; the point for this architecture is that iteration is part of the pipeline, not a manual step someone remembers to redo.

The gate a human actually approves is the merge, not the correctness check

Once the checkpoints clear, the actual decision a person makes isn't "is every fact correct," it's "does this ship." Those are different questions, and separating them is what makes the pattern scale. The correctness check already happened, repeatedly, across generator, critic, and judge. What's left for a human is the same review you'd give any pull request: read the diff, read the resolved comments, decide whether to merge. That's a meaningfully different job from re-verifying every claim yourself, and it's the structural reason a PR-approval pipeline can keep a human in the loop without making that human the bottleneck. Git-based publishing makes this concrete instead of abstract: the same review muscle you already use for reviewing a code pull request is the one you use here, because it's the same artifact type.

How Lyra runs the generator/critic/judge pattern

Lyra runs this pattern on every post before you ever see a pull request. A writer agent drafts grounded in sources it fetches during that session. A separate reviewer agent, with no memory of the drafting session, checks the finished draft against the original sources: editorial quality, every factual claim, every link, and pricing where a tenant has a pricing page to check against. Findings come back as resolvable line comments on the PR, not a chat summary, so you can see exactly what was checked and where. When the writer agent pushes a fix, the reviewer runs again, not once, until the post clears our score threshold or a human has to step in.

Gartner predicts 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from under 5% in 2025, which is the broader trend this pattern sits inside (gartner.com). Splitting generator and critic roles costs more than a single pass, Anthropic's own data on the roughly 15x token overhead makes that explicit, which is why the pattern belongs on content you're actually going to publish under your name, not on every throwaway draft. A blog post with your company's name on it is exactly that case. The gate exists so the only decision left for you is the merge. Want to see the generator, critic, and judge roles running against your own repo? Talk to the founder and we'll walk you through it.

Lyra runs the generator, critic, and judge as separate agents on every post so the mistakes get caught before your name is on them.

Talk to the founder → · Join the waitlist