GPT-5.6 Multi-Agent: A Safer Parallel PR Review Playbook

#ai #programming #agents #testing

A pull request can be too wide for one coding agent to inspect well, but adding a swarm is not automatically safer. Parallel agents can reduce wall-clock time and keep unrelated context apart. They can also multiply token spend, tool permissions, duplicate findings, and write conflicts.

OpenAI's new GPT-5.6 Multi-agent beta is a useful forcing function: it lets a root agent coordinate subagents in the Responses API, but the production decision is still yours. The real question is not “can it spawn agents?” It is “does this task split into independent, bounded evidence-gathering jobs?”

The good first use case: read-only PR review

Start with a pull request where agents do not modify the repository. Give three reviewers distinct evidence contracts:

Reviewer	Input	Must return	Must not do
Correctness	Diff and relevant call paths	Repro steps, file/line references, severity	Suggest a fix without evidence
Security	Diff, auth/data boundaries	Threat, affected boundary, exploit precondition	Run unapproved destructive tests
Test gaps	Diff and existing test suite	Missing behavior plus a test outline	Change shared test fixtures

That split is valuable because the workstreams are independent and each specialist can keep a focused context. It is a poor fit for a migration that depends on a strict sequence, a small patch, or a workflow where several agents would write the same branch. OpenAI's Multi-agent guide makes the same distinction: use it for bounded, independent work, and prefer one agent for ordered reasoning or shared mutable resources.

Keep one owner for the final answer

The root agent should synthesize, deduplicate, and rank findings. Subagents are evidence collectors, not autonomous approvers.

response = client.beta.responses.create(
    model="gpt-5.6-sol",
    input=(
        "Review this PR with three read-only specialists: correctness, "
        "security, and test gaps. Each finding needs file/line evidence. "
        "The root agent must deduplicate conflicts and return only a "
        "prioritized review; it may not merge or edit files.\n\n" + diff
    ),
    multi_agent={"enabled": True, "max_concurrent_subagents": 3},
    betas=["responses_multi_agent=v1"],
)

This follows the documented API shape. The default and recommended concurrency is three, and the limit covers descendants in the agent tree but not the root. The beta also gives every agent in the tree access to the tools configured for the request. That is why permission scope belongs in the request design, not in a hopeful prompt.

Put a budget around parallelism

GPT-5.6's launch adds a tempting headline: its ultra mode coordinates four agents in parallel by default. But parallelism is a latency trade, not free capability. OpenAI explicitly notes that subagents can increase token usage and may not help when work shares mutable state or is dominated by one slow external operation.

Use a small budget envelope before turning it on:

eligible task?       independent + read-only + evidence-oriented
concurrency          3 reviewers, 1 root
tool policy          repository read, test runner; no deploy/write tools
stop condition       one high-confidence blocker or budget exhausted
acceptance rule      every retained finding has evidence and a human owner

Track cost per accepted finding and time to a review a developer actually uses, rather than token cost alone. GPT-5.6 Sol is listed at $5 per million input tokens and $30 per million output tokens; cached input is $0.50 per million. Long-context prompts above 272K input tokens have higher pricing, so blindly handing every agent the whole repository can erase the expected efficiency gain. See the GPT-5.6 Sol model page for the current limits and pricing.

The limits that change your harness design

This is a beta feature, and there are sharp edges worth testing before a broad rollout:

max_tool_calls and reasoning.summary are not supported with Multi-agent enabled.
Server-side compaction is implicitly enabled and applied separately to root and subagent contexts.
HTTP can work for simpler runs, but OpenAI recommends WebSocket for tool-heavy or long-running work because function results can be injected as they arrive.
The API does not impose a fixed total subagent or depth limit, which is a reason to set a deliberate concurrency cap and capture the agent tree in your trace.

The model launch also introduces Programmatic Tool Calling, which can process intermediate tool data before it returns to the model. That can reduce unnecessary context, but it is not a substitute for a least-privilege tool policy or reviewable audit trail.

What to do now

Pick one read-only PR-review workflow, not an autonomous coding workflow.
Define three non-overlapping reviewer contracts and a single root-owner contract.
Start at max_concurrent_subagents: 3; log inputs, tool calls, agent paths, token use, elapsed time, and accepted findings.
Compare against your single-agent baseline for five to ten representative PRs.
Promote it only if it improves accepted findings or turnaround time within a capped cost envelope.

If you need a way to turn failures from that pilot into durable coverage, use this trace-to-regression testing playbook. The same principle applies to team design: our earlier guide on when shared context beats more subagents is a useful counterweight to adding workers by default. And, before enabling more tool access, review the operational lessons in Claude Code's July production-agent checklist.