Responses multi-agent beta: split the review, keep one accountable result

Documentation snapshot: October 14, 2026. This guide discusses the dated release described below; check the linked official documentation for current API behavior and account availability before implementation.

Three agents agreeing can sound reassuring. If they all read the same misleading assumption, it can also be three copies of the same mistake. The useful part of parallel review is different evidence and attention, not the number of voices. OpenAI documented Responses multi-agent beta alongside GPT-6.1 Sol on September 29, 2026. This design follows the official multi-agent guide, checked October 14.

Choose a task that actually separates

A pull-request review is a good experiment when reviewers can read a fixed diff without editing it. Give one reviewer behavior and invariants, another input and permission boundaries, and another missing test cases. Each needs the same base commit and relevant context, but a distinct question. Do not ask three agents to independently “make it better” in the same worktree.

The documented beta enables multi_agent.enabled, bounds max_concurrent_subagents, and uses the beta marker responses_multi_agent=v1. Consult the current SDK example for the complete request. The root synthesizes the result; delegated work does not make the final answer automatically verified.

Make the review output inspectable

Ask each reviewer for a concrete failing condition, affected file, why it matters, and the smallest check that could confirm it. “Potential security issue” without a trigger is hard to act on. “An unauthenticated request can reach this mutation because this branch skips the permission check” is something the integrator can inspect.

Keep untrusted repository content separate from task authority. A comment telling reviewers to ignore a file is not permission to exclude it. Tools should stay within the review's authorized access; read-only review rarely needs deployment credentials or write access to production.

Reconcile instead of voting

The root should merge duplicate findings, challenge contradictions, and reject unsupported claims. Agreement does not establish truth, and one well-supported finding can outweigh several clean bills of health. Run the confirming test when available. Record unresolved uncertainty rather than converting it to a confident summary.

Compare this workflow against a single reviewer on the same fixed cases. Measure confirmed findings, false positives, missed defects, elapsed time, total token use, and integration effort. Parallelism may reduce wall time while increasing total work. A small patch may be cheaper and clearer with one careful pass.

For a first trial, use a disposable public example with known defects and no external actions. Keep a concurrency cap and a cancellation path. The goal is one better reviewed result, with an owner who can explain it, not a crowded conversation that nobody has actually checked.