Multi-Agent Code Review Workflow: Two Reviewers, One Final Writer
I keep running into the same limitation when I use several AI coding sessions. In my experience, parallel sessions find different code paths, but their disagreements stay trapped in separate threads. I become the message bus, copying one review into another session and deciding which model understood the file.
The better design is a multi-agent code review workflow with three distinct roles. Two AI sessions inspect the same file revision independently. They exchange findings and challenge each other's evidence. A third session receives the decision record, writes one patch, and runs the checks.
Treat the file as shared, immutable input during review. Grant write access to one session when the review converges.
This differs from my current hybrid AI code review loop→, where one model writes and a second model reviews each fix. That loop already gives the reviewer useful independence. The next experiment delays the write: both first sessions review, and a third session starts coding only after their disagreement has produced a decision record.
This pattern is already close to what current agent tools support. OpenAI's Codex subagent documentation recommends parallel agents for read-heavy exploration, tests, triage, and review, while warning that parallel write-heavy workflows create conflicts and coordination overhead. The missing piece is a first-class discussion and synthesis layer between the reviewers and the writer.
Why does a multi-agent code review workflow need one writer?
Parallel analysis gives you different failure hypotheses without creating multiple competing patches.
One reviewer can trace behavior and invariants. The other can look for security issues, race conditions, missing tests, or API-contract breaks. They start from the same commit SHA and task, but they receive different review briefs. That separation reduces the chance that both sessions follow the same first idea.
Anthropic describes a related production pattern in Building effective agents: several model calls can review code from different perspectives, while an orchestrator-worker workflow delegates work and synthesizes the results. Anthropic also advises teams to add agentic complexity only when it improves measured outcomes. Three sessions cost more tokens and time than one, so the workflow needs a reason to exist.
Concurrent mutation is rarely that reason. If two agents edit the same working copy, the system has to resolve stale context, overlapping hunks, and partially applied assumptions. Git already offers a safer primitive: linked worktrees let separate sessions use isolated `HEAD` and index state while sharing the same repository history.
The reviewers may use worktrees for experiments, but only the integrator should own the candidate patch.
What does each AI session own?
| Session | Access | Required output | Must not do |
|---|---|---|---|
| --- | --- | --- | --- |
| Reviewer A | Read-only snapshot | Behavior risks, broken invariants, line references, proposed tests | Edit the final branch |
| Reviewer B | Read-only snapshot | Security, concurrency, edge cases, counterexamples | Copy Reviewer A's conclusion without evidence |
| Integrator | Exclusive write access | Accepted patch, rejected findings with reasons, test results, final diff | Rewrite beyond the agreed scope |
The third agent is not automatically smarter. Its advantage comes from ownership. It receives bounded evidence, makes the conflict resolution explicit, and produces one auditable diff.
I would also keep the reviewers blind to each other's first pass. A controlled study of multi-agent debate found that majority pressure can suppress independent correction. Early cross-talk can turn two reviewers into one repeated opinion. Independent findings should come first; discussion should begin after both have committed their initial evidence.
How should the reviewers discuss one file?
Free-form chat is useful for humans, but a coding workflow needs a compact finding ledger. Each claim should carry enough evidence for the integrator to verify it without replaying a private chain of thought.
{
"id": "F-03",
"revision": "8a31f2c",
"file": "src/auth/session.ts",
"lines": "84-103",
"claim": "A refresh failure can leave the previous session active",
"evidence": "The error branch returns before clearSession()",
"risk": "stale authorization state",
"proposed_test": "refresh 401 clears the active session",
"confidence": "high",
"status": "disputed"
}The second reviewer can accept the finding, refute it with a reachable-code argument, or narrow its scope. The ledger preserves both positions. Agreement alone does not prove correctness, and a confident paragraph should not outweigh a reproducible test.
Agent protocols are moving in this direction. Google's Agent2Agent protocol models collaboration through tasks, messages, state, and artifacts. A local coding system does not need the full protocol to borrow the contract: use typed messages, stable IDs, explicit status, and durable artifacts instead of an unstructured transcript.
My AI peer review bridge→ already packages a diff, focus questions, and a structured verdict for a second model. A three-session workflow needs the next layer: two review packets that can reference, dispute, and resolve the same finding IDs before the writer receives them.
What must the writer receive before editing?
The integrator should not receive two long chat histories. It needs a small handoff package:
The writer then re-reads the current file and compares its revision with the handoff. A mismatch stops the write. That one check prevents a valid review of yesterday's file from becoming a broken patch against today's code.
This is also where permissions should become deterministic. I have argued for deterministic AI agent permissions→ because a prompt such as “only edit this file” is weaker than a tool policy that makes every other path read-only. In this workflow, the permission model should enforce the role split: reviewers cannot write, and the integrator cannot expand scope without a new decision.
Does debate improve software patches?
The evidence supports the direction, but it does not prove that every team should use exactly two reviewers and one writer.
Improving Factuality and Reasoning in Language Models through Multiagent Debate shows that several model instances can propose, critique, and refine answers over multiple rounds, improving results on the paper's reasoning and factuality tasks. Those experiments did not test Git conflicts or production pull requests.
A closer coding example appeared in the 2025 preprint SWE-Debate. Its agents debate competing fault-localization traces, consolidate a fix plan, and pass that plan to a separate patch-generation agent. The paper reports 207 solved tasks out of 500 on SWE-bench Verified, or 41.4%, compared with 38.8% for its strongest listed baselines. The benchmark and architecture differ from the workflow I am proposing, but the separation is telling: diverse analysis first, one modification stage after.
The honest next step is a small controlled evaluation on real pull requests. Compare a single coding agent with the three-session workflow across 10 to 20 bugs. Measure valid findings, false positives, merge conflicts, time to an acceptable patch, and regressions caught after the first draft. More agent messages are not a success metric.
How does the writer produce one auditable patch?
The integrator should follow a narrow loop:
That last review should inspect the patch, not restart the design debate. Each reviewer answers two questions: did the writer implement the accepted decision, and did the patch introduce a new risk?
OpenAI's current Codex app already uses separate threads and worktrees so agents can run in parallel without touching the same local Git state, and it lets developers inspect and comment on each diff. The Codex app announcement shows that the isolation layer exists. A shared finding ledger and explicit integrator role would turn parallel tasks into a coordinated review room.
Which failures remain?
One writer removes edit races, not model error.
Two reviewers can share the same blind spot, especially when they use the same model, prompt, and context. The integrator can choose the more persuasive argument instead of the correct one. Repository comments can contain untrusted instructions. A passing test suite can miss the behavior users depend on.
The workflow needs guards:
My earlier conclusion after 21.54 billion code-agent activity tokens→ still applies: the system around the model decides whether more intelligence becomes useful work or faster cleanup.
When is a three-session workflow worth it?
Use it when a wrong patch is expensive or the code has more than one plausible interpretation: authentication, permissions, payments, migrations, concurrency, public APIs, and incident fixes. It can also help when a senior engineer would normally ask two specialists to review different risk areas.
Skip it for formatting, generated files, simple renames, and changes with an obvious test oracle. Anthropic's multi-agent team found that coordination complexity grows quickly, and its production research system depends on clear delegation and a lead agent that synthesizes specialized results. Coding needs the same discipline, with less tolerance for ambiguous writes.
I want coding agents to debate evidence before one of them earns the cursor. Two sessions should inspect the same file, disagree in public, and leave one decision record. A third should write the candidate patch and prove it against the repository.
That candidate still needs tests, diff review, and a human release decision. Three AI sessions can improve the path to the patch; they do not turn the patch into truth.
FAQ
Can two AI agents edit the same file at the same time?
They can, but shared writes create stale context and conflicting edits. Let both agents analyze the same revision in read-only mode, or isolate experiments in separate worktrees, then give one integrator exclusive write access to the final branch.
Should both reviewers use the same model?
They may, but different prompts, roles, or model families can reduce correlated blind spots. Diversity does not guarantee correctness, so the workflow still requires evidence and tests.
What happens when the reviewers disagree?
Record both positions in the finding ledger. The integrator should reproduce the claim, run the proposed test, or mark the issue unresolved for a human. Majority voting is a weak substitute for verifiable evidence.
Does the third AI session replace human code review?
No. The third session owns synthesis and the candidate write. A human still decides whether the patch fits the wider system, product intent, and release risk.
Can this workflow handle changes across several files?
Yes. Pin every reviewed file to the same repository revision, assign clear ownership, and keep one integration branch. Reviewers can work across isolated worktrees, while the integrator remains the only session that assembles the final patch.
