An LLM review council uses several independent AI reviewers, including one adversarial red-team voice, to check a plan and its diff separately before code ships.
Ask a language model to review the plan it just wrote, and it will usually approve it. Ask the same model to review the diff it just produced, and it will usually approve that too. This is not a quirk specific to any one model or provider. It is structural: a model reviewing its own output shares the exact assumptions, the same reading of the spec, and the same blind spots that produced the output in the first place. A second look from the same mind rarely catches what the first look missed, no matter how the prompt is worded. Telling a model to 'be more careful' or 'check again' does not change what it is fundamentally capable of seeing about its own work.
An LLM review council, sometimes called an AI council, fixes this by design rather than by hoping a model tries harder on a second pass. Instead of one model checking its own work, several independent agents or models review the same plan and the same diff separately, without seeing each other's notes, and then converge on a shared verdict. At least one seat on the council is assigned an explicitly adversarial, red-team role: its job is to find reasons to reject the change, not to confirm it. This post covers what a review council actually is, why perspective diversity beats a single pass, how voting and escalation work in practice, and where the pattern fits inside an agentic coding workflow.
What a Review Council Actually Is
A review council is a small panel of reviewers, typically two to four, each running as an independent pass rather than a shared conversation. Independence matters more than headcount: if a second reviewer can see the first reviewer's notes before forming an opinion, it tends to anchor on that framing, and the diversity you were paying for disappears. A properly built council runs each reviewer against the same artifact, whether that is a plan document, a diff, or both, in isolation, collects the separate verdicts, and only then merges them into one decision. Seats are usually assigned distinct lenses instead of asking every reviewer to check everything: an architecture reviewer checks whether the design fits existing patterns and is not over-engineered, a correctness reviewer asks what happens under edge cases and concurrent access, a security reviewer asks what the design assumes that an attacker could violate, and an adversarial red-team reviewer starts from the assumption that the change is wrong and argues for why it should be blocked. None of this requires exotic infrastructure; it requires discipline about keeping each pass blind to the others until every verdict is in.
Why Perspective Diversity Beats a Single Pass
A single model checking its own plan or diff carries a structural problem before it even starts: whatever assumption led it to write the code that way will also lead it to approve the code that way. Running the same model a second time, or prompting it to review more carefully, mostly reproduces the same blind spot with more words attached. The value of a council is not more eyes, it is uncorrelated eyes. Three runs of the same model with different phrasing tend to produce variations on one blind spot, not real coverage. A council that mixes reviewer roles, architecture, correctness, security, and mixes underlying models where practical, produces disagreement in exactly the failure modes that matter: what one lens treats as fine, another flags as a race condition or a missing auth check.
The point of a review council is not consensus for its own sake. It is disagreement that surfaces what a single reviewer would have missed, followed by a forced reconciliation before anything ships.
How a Council Votes and Escalates
Each reviewer submits an independent verdict with findings tagged by severity, usually critical, major, and minor. A council does not vote in the sense of averaging opinions. Findings are compared across reviewers, and any critical finding from a single reviewer, including the adversarial seat, is enough to block the change regardless of what the others concluded; majority agreement can lower priority, but it never overrides a credible critical finding. Escalation is the other half of the mechanism. When reviewers split, one approves and the adversarial reviewer flags a critical issue, the correct response is not to split the difference. Averaging a critical security finding against two approvals is how vulnerabilities ship. A working council routes hard disagreement to a human decision instead of resolving it algorithmically, which is what a convergence gate enforces mechanically: it will not let a change through while any critical count is nonzero. That single rule, a critical finding always wins over a majority, is the difference between a council that catches problems and one that just produces a longer, more confident-sounding rubber stamp.
Where the Council Fits in an Agentic Workflow
A council review shows up at two points in an agentic coding loop, not one. The first is before implementation: independent reviewers check the spec or plan against the actual requirements, catching a wrong direction while it is still a document and cheap to redirect, an approach covered in more detail in how it works. The second is after implementation: the same independent structure runs against the finished diff, catching what only exists once real code is written, edge cases, resource leaks, and interactions the plan did not anticipate, with the adversarial seat playing a role close to red-teaming your AI code. Context handoffs are the quiet weak point across both stages. A council that forgets its own prior verdicts, or a coding agent that starts every session with no memory of past review decisions, ends up re-litigating arguments it already settled. Tools built around a private, persistent memory layer, like MemX, exist to keep that history available across sessions instead of starting from zero each time. TLM Forge builds the council pattern into the terminal workflow itself: every feature starts with a spec audit, moves through independent multi-agent review of both the plan and the diff, and finishes at an adversarial gate that will not ship while critical findings remain open. That sequence, spec audit, plan review, implementation, diff review, adversarial gate, is what turns the pattern from an occasional habit into something every change goes through the same way, whether the engineer remembers to ask for a second opinion or not.
If you are piloting a council manually before adopting tooling, start with two seats only: one reviewer checking the change against the plan, and one dedicated adversarial reviewer. Add a third seat, security or operations, once those two run reliably; more reviewers without a working merge process mostly adds noise.
No Council vs. Review Council
The differences are easiest to see side by side, comparing a single-model pass against a review council across the failure modes that actually cause incidents in production.
| Dimension | No council (single pass) | Review council |
|---|---|---|
| Blind spots | Same model checks its own output and shares the assumptions that produced it | Independent reviewers with different lenses catch different bug classes |
| Adversarial pressure | No reviewer is incentivized to argue against the change | At least one seat is dedicated to finding reasons to reject it |
| Disagreement handling | No formal mechanism; issues surface later in production | Structured escalation; critical findings block merge regardless of majority |
| Consistency | Quality varies pass to pass with no gate enforcing a floor | A convergence gate holds every change to the same bar |
| Context across sessions | Prior review decisions are rarely tracked or reused | Findings persist as structured output the next pass can read |
| Where issues are caught | Mostly after the change ships, in production or a later review | Before merge, at plan time and again at diff time |
Frequently asked questions
01How many reviewers does an LLM review council need?
Most effective councils run two to four independent reviewers. Two is the minimum for a real second opinion, one correctness-focused and one adversarial. Beyond four, the overhead of reconciling disagreement usually outweighs the value of another perspective.
02Does a review council need different models, or can it use one model with different prompts?
Different prompts on the same model help by assigning a distinct lens, architecture, security, or adversarial, but they still share that model's underlying blind spots. Mixing model providers, where practical, adds a second, independent source of disagreement on top of role diversity.
03What happens when council members disagree?
A well-built council does not average disagreement away. Any critical finding from a single reviewer, including the adversarial seat, blocks the change until it is resolved or a human explicitly overrides it. Escalation to a human is the intended outcome of a split vote, not a failure of the process.