Code review agent orchestration

Code review agent orchestration starts after you choose a review loop. The loop decides when to run one reviewer or a fleet; AI agent orchestration decides how that fleet is routed, how findings reach a coding agent, and how independent fixes land without ten agents editing one checkout.

This is the sequel to How to structure an AI PR review loop. The useful shape is smaller than it sounds: one router, roughly eight review perspectives, one findings channel, and temporary worktrees for patches that can proceed independently.

Code review agent orchestration: the nine-agent shape

“Nine agents” does not mean nine generalists rereading the same diff. It means one router dispatching a defined roster: a Core generalist plus seven specialist lanes — security, performance, architecture, tests, data, API, and frontend.

The router reads the change and chooses relevant lanes. A database migration might get Core, data, tests, and architecture. A CSS-only patch probably needs Core and frontend. This is routing, not a vote: specialists may return no findings, and duplicate observations should be synthesized rather than published eight times.

Orchestration is not “more agents.” It is less duplicated work, clear ownership, and a controlled route from finding to patch.

Fine-tune the roster, not every prompt

Start with stable lanes and adjust routing from evidence. If security repeatedly finds nothing on copy changes, stop sending it copy changes. If API compatibility defects recur, pin the API lane for that repository. Prompt tuning matters, but roster and trigger tuning usually remove more noise.

Mergestorm’s Vortex router exposes four useful operating modes: off for Core only, standard for normal routing, max for broader coverage, and manual for pinned lanes. From the CLI:

• mg review --router max asks for broad local review.
• mg review --router manual --specialists security,frontend pins two domains.
• Plain mg review uses the account’s router setting. mg is an alias of mergestorm.

Close the loop: MCP findings become patches

A review fleet is only half a system. The next step is a machine-readable handoff: submit a review, wait for completion, retrieve structured findings, let the coding agent verify each one against the checkout, and apply the smallest correct patches.

An MCP server is a practical boundary here. Mergestorm’s mergestorm-mcp exposes whoami, credits, review_list, review_get, review_submit, and review_wait. It can authenticate with MERGESTORM_API_KEY or the config created by mg login. Context files supplied to review are sandboxed to the repository.

For Claude, installation can be as short as claude mcp add mergestorm -- npx -y mergestorm-mcp. Cursor can run the same npx -y mergestorm-mcp command from its MCP configuration. The point is not the client: it is that the coding agent can pull findings without copying comments between tools.

Keep those roles precise. Vortex comments. Cyclone makes mechanical PR patches. Tempest is the deep reviewer. Maelstrom is a plan name, not an agent. For the broader division of labor, read What is AI PR code review?

Parallel worktrees on one machine

Once findings are independent, temporary git worktrees let several coding agents patch in parallel without sharing an index, working tree, or uncommitted files. Create one short-lived branch and worktree per patch group: security fixes in one, tests in another, frontend in a third.

Group by files and dependency boundaries, not simply one finding per agent. Two findings that modify the same function belong together. After each agent tests its branch, integrate in dependency order, resolve the few remaining conflicts centrally, and run the complete suite once on the assembled result.

Worktrees are a general git pattern, not a Mergestorm feature. One useful interaction is that linked worktrees share Mergestorm CLI stack state; independent clones do not. If the changes naturally form a stack, mg stack create, submit, and land can manage that sequence. Do not confuse parallel editing with parallel merging.

Design for failure, not just fan-out

Parallel patching needs an exit rule. Give each agent a narrow finding set, the relevant tests, and permission to return “no safe patch.” A failed test or ambiguous requirement should produce a report, not a speculative rewrite. Time-box branches that stop making progress and remove their worktrees after preserving any useful commit.

Also record which review finding produced each patch. That small trace makes integration review much easier: a human can compare the evidence, proposed correction, and resulting behavior without reconstructing the conversation. If two branches solve the same root cause differently, stop and choose one before merging either. Git can combine text; it cannot decide which invariant the product intended.

Finally, cap concurrency. Ten reviewers can inspect in parallel because they mostly read. Ten patchers may compete for CPU, package caches, test databases, ports, and memory. Start with two or three independent patch worktrees, measure the machine’s bottleneck, and increase only when test reliability stays stable.

CLI and skills are glue, not governance

A small agent skill can encode the safe loop: review the local branch over MCP, verify findings, patch, test, then resubmit on the same branch so the review thread chains. Mergestorm’s mergestorm-review skill follows that shape. Its sensible defaults are to omit the router, use off for tiny diffs, pin manual lanes for one domain, and reserve max for an explicit request.

The skill should not push, merge, or land. Nor should local review request Governance: that feature belongs to long GitHub follow-up sequences, not local review. mg review reviews a local git diff without opening a PR, uses the same engine as PR review, and consumes a credit.

What still needs a human

Agents can divide inspection and mechanical repair. They do not own product intent, acceptable risk, rollout timing, or whether the PR is the right change. A reviewer still has to decide whether a finding is true, whether a “fix” changes behavior, and whether independently clean patches compose safely.

Use the PR review checklist at the final integration boundary. That is where orchestration stops being a set of successful subtasks and becomes one shippable change.

A setup you can steal

1. Route the first pass to Core plus only the specialist lanes implied by the diff.
2. Retrieve findings through MCP and have the coding agent reproduce or verify each one before editing.
3. Cluster accepted fixes by overlapping files and dependencies.
4. Create a temporary branch and worktree for each independent cluster; assign one coding agent to each.
5. Test each patch locally, integrate in dependency order, then run the repository-wide checks.
6. Resubmit review on the assembled branch. Keep the human approval gate.

Preflight checklist

• Router mode and specialist roster match the diff’s risk.
• Every accepted finding has evidence in the current checkout.
• Parallel agents do not own overlapping files or functions.
• Per-worktree tests and final integrated checks both pass.
• A human reviews behavior, rollout, and final approval.

That is the practical promise of orchestration: not autonomous approval, but a review-and-patch system with explicit routes, isolated edits, and a final accountable owner. For a simpler starting point before building the system, see AI PR review in practice.