A New Way to Collaborate with Multi-Agent Systems: Building an AI Review Panel with Tools You Already Have

Assigning a task to a single AI agent and then praying it gets it right on the first try increasingly feels like opening a blind box. A "panel" approach shared by a developer on Reddit offers another way of thinking: hand the coding task to a team made up of multiple agents you're already using—one writes, the others review from different angles, and finally the lead agent verifies line by line before delivering. A recent round of updates has made the whole process require almost no manual configuration.

From Specifying Panels to Assigning Work in Natural Language

Early versions required users to tell the skill precisely "which terminal panel corresponds to which agent," and this pane ID management became cumbersome as the number of agents grew. The new version removes this restriction: you simply describe the task in natural language, for example /panel implement the serializer per the spec or /panel codex implements, opencode reviews: fix the flaky test, and the lead agent discovers the available panels on its own, reads each agent's harness and model information, and then assigns roles.

The key design decision is that the lead agent explicitly tells you the mapping it has chosen before starting work. Once an assignment is wrong, you can see and correct it right away, rather than discovering it only after the task has gone off track. This "declare first, then execute" pattern exposes the scheduling logic that was originally hidden behind the scenes to the user.

Harness (agent runtime skeleton) here refers to the toolchain that drives a coding agent's operation, including the CLI program, model backend, system prompt, and toolset configuration. Different harnesses (such as Claude Code, Codex, and OpenCode) differ noticeably in context length, tool-calling format, and permission model, and the same task given to different harnesses may yield different results. The lead agent reads each panel's harness and model information in order to assign implementation and review roles according to capability characteristics—for example, letting a long-context model do cross-file spec review and letting a model that excels at execution write the code.

No One Needs Polling: An Event-Driven Wake-Up Mechanism

The most common engineering headache in multi-agent collaboration is waiting. After dispatching a task, the lead agent either falls into a sleep loop repeatedly checking "is it done yet?" or needs a resident background process to watch the status. This project bundles a small Claude Code plugin called lanes that specifically monitors Herdr panels: when a dispatched agent finishes its task, gets stuck on a permission prompt, or stalls, it automatically wakes the lead agent.

The lead agent's way of working thus becomes clean: dispatch the task, end its own turn, and get woken up when there is something to review. No background waiter, no polling overhead. This event-driven structure is also closer to the collaboration rhythm of a human team—you don't need to ask a colleague "are you done yet?" every five minutes.

Polling and event-driven are two paradigms for state synchronization. Polling has the lead agent actively query "is the task done?" at fixed intervals; it is simple to implement but wastes tokens and time when idle, and too long an interval delays the response. Event-driven instead pushes state changes (completion, permission blockage, stall) as signals to the listener, with a plugin monitoring the panel output and triggering a wake-up. In agent orchestration, event-driven can significantly reduce idle cost, but it depends on reliable parsing of terminal state—if a harness's output format is nonstandard, the monitor may miss or misjudge the state.

The Review Loop Is the Core

The real value of this approach is not the gimmick of "multiple agents" but the design of the review mechanism. The rules are clear: at any given moment only one agent has write permission, and all the other agents do read-only review of the same frozen diff, each approaching it from a different angle—spec compliance, correctness and edge cases, and those tests that will actually never fail.

Finally, the lead agent personally reads the real diff, opens every referenced line of code, runs the full validation gate on its own, and then compiles everything into a unified fix brief and sends it back. The loop is capped at three rounds; if problems remain after three rounds, the lead agent does the work itself, and its changes must also go through review.

This design directly addresses a chronic problem with single-agent coding: models tend to confirm that their own output is correct and lack genuinely adversarial checking. Splitting writing and reviewing across different agents and freezing the changes during review can, to some extent, create an independent reviewing perspective.

Frozen diff refers to locking a snapshot of the code under review during the review period, so that reviewers always see the same version and the party with write permission cannot keep modifying it during this time. Without freezing, reviewers might encounter code changes while reading, causing their comments to point to lines that no longer exist, and the conclusions of multi-party reviews could not be aligned. Freezing separates "writing" and "reviewing" in time, giving each review round a clear object and allowing fix comments to correspond to a specific snapshot—this is also the engineering prerequisite for the process to produce an independent reviewing perspective.

No Extra Subscriptions, Reusing the Existing Stack

According to the author, the whole process requires no extra subscription and no fiddling with API keys. It builds on Herdr plus the coding CLIs already in your stack—Claude Code, Codex, ZCode, OpenCode, whatever you run. This lowers the barrier to trying it: if you are already running multiple agents side by side, this orchestration layer is an almost zero-cost increment.

Observations from Practice

The author invites questions in the post from users experienced in running multiple agents in parallel, indicating that this workflow is still in the stage of being honed in practice. The flexibility of assigning roles in natural language brings an implicit problem: whether the lead agent's "self-discovery" of panels and models is reliable depends on its ability to understand the environment. The mapping declaration mechanism mitigates this, but complex multi-agent environments may still require human intervention.

The three-round cap is also a trade-off worth noting. It avoids an endless fix loop, but it also means complex tasks may end up on the path where the lead agent finishes things itself—at which point the object of review becomes the lead agent's own changes, the roles of reviewer and reviewed are reversed, and the consistency of the process is left for the user to manage.

For developers already using multiple coding agents, this approach provides a structured collaboration template: clear division of labor, frozen changes, independent review, and unified closure. It may not suit every task, but for coding work that demands high reliability, turning "done writing means done" into "done writing still has to pass review" is the right direction.

Project address: https://github.com/alexstrilets/panel

One-line Summary

panel builds a review panel from existing coding agents, achieving write-review separation and event-driven collaboration.

Paragraph Summary

panel is a multi-agent collaboration approach shared by a developer on Reddit that hands a coding task to a group of coding CLIs already in use: one agent implements, the rest do read-only review, and the lead agent verifies the diff line by line and compiles a fix brief. The new version removes manual pane ID configuration and supports assigning work in natural language, with the lead agent declaring the role mapping before executing. The bundled lanes plugin monitors panel status and automatically wakes the lead agent when a task completes or is blocked, avoiding polling. The review loop is capped at three rounds, after which the lead agent finishes things itself and its changes are likewise subject to review. The whole approach reuses Herdr and the existing stack, requiring no extra subscription or API key.