Accepted to NeurIPS 2026 · Main Track

Precise but Uncoupled: Reviewer Precision Does Not Guarantee Critique Uptake in Multi-Agent Math Reasoning

A protocol can be good at spotting errors and still not act on them.

On 4,181 verifier-grounded Omni-MATH problems with matched gpt-oss-120b actors, the planner–executor–reviewer pipeline has the more precise reviewer (0.861 vs. 0.644), yet evaluator-verified useful critique changes the candidate it carries forward only 33.6% of the time versus 93.5% under broadcast deliberation — so reviewer detection quality and critique uptake are empirically separable.

Chih-Hsuan Yang1,*, Jingyan Jiang1, Vikram Vasudevan2, Cheng-Hau Yang1, Huihuo Zheng1, Le Chen1, Eliu A. Huerta1,3, Venkatram Vishwanath1, Ian T. Foster1,3, Rajeev Thakur1

1Argonne National Laboratory 2Oregon State University 3University of Chicago *Corresponding author

Accepted to NeurIPS 2026 (Main Track). arXiv:2607.15388 [cs.AI], v1, 16 July 2026.

The GitHub repository and the Hugging Face dataset are made public at the moment of release; if a link returns 404 or 401, publication has not completed yet. No trained model is part of this project — there is no model card, because no model was trained.

00What we found

A reviewer that is good at spotting wrong answers does not, by itself, make a multi-agent system solve more problems. Detection and repair come apart.

  • The better detector is the worse fixer. On 4,181 Omni-MATH problems the planner–executor–reviewer pipeline (PER) has the more precise reviewer — 0.861 against broadcast's 0.644 — yet reaches lower final accuracy, 85.2% against 89.2%.
  • The gap is in uptake, not in detection. Evaluator-verified useful critique changes the candidate PER carries forward only 33.6% of the time, against 93.5% under broadcast. Realized repair is 5.6× lower: 0.051 against 0.286.
  • Detection and repair are separable, and it generalises. Across five benchmarks and two actor families, PER's reviewer precision beats broadcast's in 10/10 cells, while inside PER precision exceeds verified repair in 9/10 (the exception has only two evaluable follow-ups) and inside broadcast in 10/10.
  • Why it matters. Reviewer-centric evaluation can overstate system quality. A protocol may spot errors well and still fail to solve more problems, so a review stage must be judged on what the system does next, not only on whether the critique was right.

The three numbers

0.861 PER reviewer precision vs. 0.644 for broadcast. PER's reviewer is the better detector.
0.336 PER CouplingRate vs. 0.935 for broadcast. Verified useful critique changes PER's next candidate about a third of the time.
0.051 PER reviewer-guided repair vs. 0.286 for broadcast — 5.6× lower realized repair.

Paper Table 11, review-conditioned decomposition. N = 4,181; 10,804 PER and 11,587 broadcast review instances.

01The result in two figures

The first figure is the mechanism. The second is the outcome it produces.

Two panels. Left, a stacked bar chart of inner-loop failure modes over wrong-initial-candidate cases: PER splits 11% repair, 49% neglect, 40% try-but-fail, while broadcast splits 26% repair, 26% neglect, 48% try-but-fail — 2.3 times more neglect under PER. Right, a grouped bar chart of five metrics for PER and broadcast: precision 0.86 versus 0.64, recall 0.75 versus 0.87, CouplingRate 0.34 versus 0.93, guided repair 0.05 versus 0.29, misleading resistance 0.92 versus 0.71. A shaded box marks CouplingRate and guided repair as the coupling gap.
Figure 3. What observable process difference tracks the PER–broadcast gap? Not reviewer precision alone, but whether evaluator-verified useful critique changes the next candidate the protocol carries forward. Left: NeglectRate is the dominant inner-loop failure mode for PER (48.8% of wrong-initial-candidate cases neglect available critique), while TryButFailRate is much closer across protocols. Right: the aggregate metrics show the core paradox — PER has higher reviewer precision (0.861 vs. 0.644), yet verified useful critique changes the next candidate only 33.6% of the time under PER versus 93.5% under broadcast, and reviewer-guided repair is correspondingly 5.6× lower (5.1% vs. 28.6%).
Two line charts of gain in percentage points over the single-agent iterative anchor, by difficulty tier 1 to 10, for PER (orange) and broadcast (green). Panel a, FinalPassRate gain: both near zero on tiers 1 and 2, rising from tier 4 to roughly 14 to 20 points on tiers 6 to 9, with broadcast reaching about 40 points on tier 10. Panel b, Pass@1 gain: a similar rising pattern reaching roughly 27 to 35 points on tiers 7 to 10. Grey vertical bands mark the small-sample tiers 3 and 10.
Figure 2. Tier-level collaboration gain over single-agent iterative, the matched non-collaborative anchor. Gains are near zero on tiers 1–2 and open sharply from tier 4 onward. The same pattern holds for Pass@1, before any verifier-guided retry. Grey bands mark the benchmark's small-N tiers (tier 3: n = 20; tier 10: n = 15) — do not read those two points as trends.

Both figures regenerate from the released data. Method, the full tables and the post-rebuttal robustness matrix follow below.

02Abstract

Many math- and science-oriented agent systems use hierarchical designs with specialized reviewer roles, assuming that a dedicated review stage should help turn wrong candidates into correct ones. We test this assumption on 4,181 verifier-grounded Omni-MATH problems using matched gpt-oss-120b actors. Collaboration adds little on the easiest tiers, but from tier 4 onward the gains open sharply; in this harder regime, broadcast-style peer discussion reaches higher final accuracy than a planner-executor-reviewer pipeline (PER). We ask whether this gap is explained by reviewer quality or by whether critique changes the next answer the protocol carries forward. It is not explained by reviewer precision alone: PER's reviewer is more precise than broadcast's (0.861 vs. 0.644), yet evaluator-verified useful critique is much less likely to change the next candidate and produces lower reviewer-guided repair. These results show that reviewer detection quality and critique uptake are empirically separable. Within matched PER interventions, forcing explicit acknowledgment lowers final accuracy, while embedding reviewer guidance directly in the solver's working context partially improves follow-through without closing the gap. Overall, reviewer-centric evaluation can overstate system quality: a protocol may spot errors well yet still fail to solve more problems if it does not act on those critiques.

Abstract as published in the arXiv v1 metadata record. The PDF's own abstract is slightly longer; where they differ, the downloadable artifact is arXiv v1.

03Why precise review need not produce repair

Many math- and science-oriented agent systems add a dedicated reviewer role, on the assumption that routing critique through a review stage turns wrong candidates into correct ones. That assumption bundles two separate things together.

A reviewer role has to do two jobs, and they can be measured apart:

  1. Detection — does a reviewer warning actually point at a real error? That is reviewer precision.
  2. Uptake and repair — once critique is verified useful, does the protocol change the next candidate it carries forward, and does that change fix the answer?

Reviewer-centric evaluation measures the first and treats the second as implied. This paper measures both and finds they come apart: the protocol with the better reviewer is the one that acts on critique less. The reason is structural rather than a property of the critique text — it is about where the critique lands and who has to agree before an answer is submitted.

The structural contrast

Two protocols differ in how critique reaches the answer. The rows below are the paper's Figure 1, re-rendered here as text.

PER: critique is routed, but can remain non-binding
Broadcast: critique is shared, and approval is collective
PERPlanner → Executor → Reviewer
BroadcastPeer discussion ↔ shared candidate
PERReviewer signal enters a separable advice field
BroadcastCritique enters the shared deliberation state
PERSolver can acknowledge the signal yet preserve the candidate
BroadcastEvery peer sees the same candidate before submission
PERSubmission decision is role-local after routed review
BroadcastSubmission requires collective re-approval

Re-rendering of Figure 1, Why reviewer quality and realized repair can diverge. In PER, information flow and decision flow can separate: a reviewer can send a correct warning without changing the next candidate. In broadcast, critique is embedded in shared candidate state and group approval, making bypass harder by design.

What this contrast is not. PER and broadcast are complete protocol designs that differ in several ways at once — routing, shared state, feedback delivery, prompts, and round structure. This is a configuration-level difference, not an isolated manipulation of any single mechanism. In particular, the approval gate cannot be isolated with the available toggle, so no causal claim is made about it. See Limitations.

04Method: four protocols, and a three-step decomposition

Every protocol solves the same 4,181 problems with the same model, the same evaluator contract, the same outer-loop budget, and the same memory reset policy. What varies is the collaboration structure.

The protocol ladder

Matched protocol knobs (paper Table 12).
ProtocolOuter budgetPre-submission structureFeedback surfaceSubmission gate
Baseline LLM1 attemptNoneEvaluator pass/fail onlyDirect one-shot submission
Single-Agent IterativeUp to 3No reviewer; question-scoped repair ledgers reused across retriesHinted evaluator feedback plus prior answerSame solver resubmits after each failure
PERUp to 32 inner rounds per attempt: Planner→Executor→ReviewerCritique routed through separable advice fieldsReviewer routes back or approves; decision is role-local
BroadcastUp to 34 discussion rounds plus up to 2 approval roundsShared candidate state, shared peer history, hinted evaluator feedbackUnanimous re-approval before submission

Detection → uptake → repair

Rather than compare only final accuracy, each review episode is decomposed into three measurable steps. Every step is grounded in the evaluator's verdict on the answers involved, not in a judgement about the wording of the critique.

Three-step decomposition of a review episode A review episode flows through three gates. Step 1, detection: does the reviewer warning point at a real error, measured as reviewer precision. Step 2, uptake: does the next candidate the protocol carries forward actually change, measured as CouplingRate. Step 3, repair: is the changed answer now correct, measured as ReviewerGuidedRepairRate. Each gate can drop the episode, so a protocol can pass step one and still fail overall. Review episode reviewer asks for a revision STEP 1 · DETECTION Is the warning real? the flagged candidate is in fact wrong Precision STEP 2 · UPTAKE Did the answer move? the next candidate the protocol carries differs CouplingRate STEP 3 · REPAIR Is it now correct? the changed answer passes the evaluator ReviewerGuidedRepairRate Each gate can drop an episode. A protocol can pass step 1 more often than another and still reach step 3 far less often. That gap is what this paper measures.

Every measurement is an operational answer-transition statistic: whether the answer string the protocol carries forward changed, and whether the evaluator judges the new one correct. None of it is a judgement about whether the solver understood, ignored, or deprioritised the critique — that would require semantic labelling this work does not have.

Setting

Benchmark
Omni-MATH 2 (filtered), N = 4,181 competition-level problems in ten benchmark-provided difficulty tiers. Tiers 3 (n = 20) and 10 (n = 15) are small and are marked wherever they appear.
Actors
openai/gpt-oss-120b for every acting role — planner, executor/solver, reviewer, peers.
Evaluator
openai/gpt-oss-120b, the same checkpoint, held fixed across all cells.
Decoding
Temperature 0 throughout. No seed is available — the hosted endpoint runtime is not frozen and exposes none, so live re-runs are independent executions.
Serving
OpenAI-compatible server on public GPU-backed HPC infrastructure (ALCF).

05Main findings

Scope of this section. Everything under Primary result is the paper's own setting: Omni-MATH 2 filtered, N = 4,181, actor and evaluator both openai/gpt-oss-120b, temperature 0. The Post-rebuttal robustness block that follows is separate supplementary evidence over five benchmarks and two actor families; it is not the paper's main claim and is labelled as such throughout.

Primary result: precision and uptake come apart

Paper Table 11, review-conditioned decomposition. N = 4,181; 10,804 PER and 11,587 broadcast review instances.

Review-conditioned decomposition (paper Table 11), N = 4,181.
Protocol Precision Recall Coupling­Rate Reviewer-guided repair Misleading resistance
PER (role-based)0.8610.7540.3360.0510.921
Broadcast deliberation0.6440.8720.9350.2860.708
Radar chart with five axes on a 0 to 1 scale, comparing PER (dashed orange) and broadcast (solid green). PER extends further on precision, 0.861 versus 0.644, and misleading resistance, 0.921 versus 0.708. Broadcast extends further on recall, 0.872 versus 0.754, CouplingRate, 0.935 versus 0.336, and reviewer-guided repair, 0.286 versus 0.051. The two shapes cross: PER is larger on the detection axes and much smaller on the coupling and repair axes.
Figure 20. Five-dimensional detection–coupling–repair profile. The shape difference makes the separation concrete: the protocols diverge most sharply on the coupling and repair dimensions, not on the detection dimensions alone.

Where the accuracy difference lives

Collaboration is worth little on the easiest problems and a great deal on the hardest ones. Over N = 4,181 the four rungs reach FinalPassRate 56.8% (baseline), 78.8% (single-agent iterative), 85.2% (PER) and 89.2% (broadcast); Pass@1 is 56.8 / 57.4 / 72.8 / 78.6%.

Within-PER interventions: directional, not causal

Two probes change only how critique reaches the solver, holding model family, reviewer setup and outer-loop budget fixed. Forcing the solver to acknowledge critique explicitly (ACK-required) lowers final accuracy, from 85.2% to 82.5%, and roughly doubles NeglectRate (0.488 → 0.792). Embedding reviewer guidance directly in the solver's working context (EMB) partially recovers, to 86.3%, without closing the gap to broadcast's 89.2%.

Bar chart of final outcomes for four conditions, each showing FinalPassRate in a solid bar and Pass@1 in a lighter bar. PER base 85.2% and 72.8%; PER plus ACK 82.5% and 71.0%; PER plus EMB 86.3% and 74.5%; broadcast 89.2% and 78.6%.
Figure 4(a). Within-PER intervention outcomes over the full benchmark (N = 4,181). ACK-required lowers FinalPassRate and Pass@1; EMB partially recovers both. Only panel (a) of the paper's Figure 4 is shown here. Panel (b) of the published figure plots CouplingRate values that could not be reconstructed from the released aggregates, so it is omitted here. The verified values are Table 14's 0.200 (ACK) and 0.247 (EMB), given in the table below.
Within-PER intervention suite (paper Table 14), N = 4,181. Token columns from the published table are omitted — see Limitations.
ConditionFinalPassRatePass@1NeglectRateReviewer-guided repairUseful coupling
PER85.2%72.8%0.4880.0510.336
PER + ACK-required82.5%71.0%0.7920.0320.200
PER + Embedded (EMB)86.3%74.5%0.6980.0440.247
Broadcast89.2%78.6%0.2620.2860.935

Read these two probes as directional, not as a clean ablation. They are a within-PER comparison, not a causal identification: the tested ACK instruction does not distinguish compliance from distraction, format effects, or reasoning perturbation, and the EMB recovery does not reproduce on the smaller frozen replication subset (N = 195, where EMB is −1.03 pp against base PER). Nothing here establishes a mechanism, and nothing here is a claim about whether the solver understood the critique.

Robustness inside the paper's own setting

  • The coupling metric is definition-stable. Legacy and strict-deterministic CouplingRate are numerically identical for both protocols (PER 0.336 = 1,766/5,253; broadcast 0.935 = 4,876/5,214), with strict-vs-legacy disagreement of 0/5,253 and 0/5,214. An equivalence-aware variant moves PER only to 0.340. (Paper Table 3.)
  • The result is not a single-evaluator artifact. Replaying 16,724 saved submissions under three evaluators — gpt-oss-120b, Meta-Llama-3.1-70B-Instruct, gemma-3-27b-it — gives instance-level disagreement of 3.38–5.76% and Cohen's κ 0.850–0.915. Re-tabulating those labels preserves the broadcast−PER ordering: +2.88 pp [1.82, 3.91] under GPT-OSS, +3.21 [2.13, 4.26] under Llama, +3.33 [2.22, 4.45] under Gemma-3.
  • But evaluator sensitivity is real where it matters most. On the hard collaborative slice (PER and broadcast, tiers 7–10, N = 1,694) disagreement roughly doubles, to 9.68% / 9.39% / 5.25% with κ 0.755 / 0.761 / 0.875.
  • Run-to-run variation is smaller than the effect. On a frozen N = 195 subset, independent re-executions move PER FinalPass by about 0.5 pp and broadcast by about 2 pp, against a paired broadcast−PER gap of +4.10 to +6.67 pp. Direction reproduced on both tested backends; one of four intervals crosses zero.
Panel a, grouped bar chart of pairwise evaluator disagreement rate. For each of three evaluator pairs a light bar shows the full benchmark of 16,724 instances and a dark bar the hard collaborative slice of 1,694 instances. gpt-oss versus Llama 5.8% then 9.7%; gpt-oss versus Gemma 4.3% then 9.4%; Llama versus Gemma 3.4% then 5.2%. Cohen's kappa is annotated above each bar, from 0.755 to 0.915. Panel b, heatmap of gpt-oss versus Llama disagreement by tier and protocol on the hard slice: tier 7 9.2% and 9.5%, tier 8 10.1% and 10.1%, tier 9 12.3% and 8.2%, tier 10 hatched as tiny with only 15 instances.
Figure 5. Cross-evaluator disagreement. Overall agreement is high, but disagreement roughly doubles on the hard collaborative slice, concentrating at tiers 8–9. Tier 10 has only 15 instances per protocol (hatched) and its lower rate should not be over-interpreted.

Post-rebuttal robustness: five benchmarks, two actor families

Supplementary evidence, not the paper's claim. The matrix below is post-rebuttal work over five benchmarks (Omni-MATH, JEEBench, SciBench, LAB-Bench, MaScQA) and two actor families (gpt-oss-120b, gemma-4-31b). The paper itself reports Omni-MATH only. These cells use a different labelling pipeline from the main tables, so their absolute rates are not comparable to the 0.861 / 0.336 / 0.051 figures above; what travels is the ordering.

Across the ten dataset × actor cells:

  • PER reviewer decision precision exceeds broadcast precision in 10/10 cells.
  • Within PER, precision exceeds verified strict next-answer repair in 9/10 cells. The exception is JEEBench × Gemma-4, where only two follow-ups are evaluable — no stable conclusion is possible from that cell.
  • Within broadcast, precision exceeds verified repair in 10/10 cells.

So the separation between detecting an error and repairing it is broad across models and domains. That is the claim, and it is the only claim this matrix supports.

The protocol ranking is not universal, and this page never asserts one. With Gemma-3-27b-it actors on a tier-sampled N = 835 subset the outcome ranking reverses — PER 65.6% vs. broadcast 58.7% FinalPassRate — while the precision–uptake separation persists (precision 0.881 vs. 0.722; uptake 0.092 vs. 0.742; repair 0.009 vs. 0.174). Which protocol wins is setting-dependent. What survives across settings is the separability.

Per-cell numbers for the ten dataset × actor cells
Strict symmetric transition audit. Precision, strict uptake and verified strict repair by cell. Recomputed for this page from the released matrix_2x5_precise_uncoupled_strict.csv.
BenchmarkActor PER precisionBC precision PER uptakeBC uptake PER repairBC repair PER repair n
Omni-MATHGPT-OSS-120B0.7480.5370.3830.2950.0360.036362
Omni-MATHGemma-4-31B0.6840.3460.2540.0960.0570.012316
LAB-BenchGPT-OSS-120B0.7070.4130.2860.2570.0770.07526
LAB-BenchGemma-4-31B0.7940.5760.4000.2280.4000.0495
SciBenchGPT-OSS-120B0.9110.5830.6360.1690.0000.03211
SciBenchGemma-4-31B0.9760.6110.6500.1620.1000.03120
MaScQAGPT-OSS-120B0.7500.3400.2220.1820.1110.0349
MaScQAGemma-4-31B1.0000.4380.5000.1820.0000.0912
JEEBenchGPT-OSS-120B0.6470.2370.3330.1430.1670.0836
JEEBenchGemma-4-31B1.0000.3021.0000.2781.0000.1762

Read the last column first. Eight of the ten cells rest on fewer than 30 evaluable PER follow-ups, and five rest on fewer than ten. The JEEBench × Gemma-4 row has n = 2: its 1.000 entries are two out of two events, not a measured rate, and that cell is the one exception to the 9/10 ordering. Treat every sparse cell as exploratory. Only the two Omni-MATH rows carry enough events to stand on their own.

Uptake columns are shown for completeness and are the reason a broader ordering claim is not made: PER strict uptake is lower than broadcast's in 0/10 cells, and PER repair is lower in 3/10. Any statement that PER has lower uptake or repair across all settings would be false here.

06What an uncoupled episode looks like

The three-step decomposition is not an abstraction over the data — it is read off individual answer transitions. Below are real transitions from the released table, all drawn from Omni-MATH (Apache-2.0) so that nothing here is encumbered by the NonCommercial or ShareAlike terms above.

Each row is one review episode where the reviewer asked for a revision and the candidate in hand was in fact wrong — a true-positive detection. All six are drawn from the strict pre-gate population defined below, so every "after" answer is the actor's own immediate response to the critique rather than a system-selected candidate. What varies is what happened next.

Answer transitions on verified-useful review episodes, Omni-MATH × gpt-oss-120b. Answers are shown as stored, in LaTeX.
ProtocolAnswer before reviewAnswer after reviewOutcome
PER\frac{7}{16}\frac{7}{16}Neglectedflagged answer was in fact wrong; the candidate did not move
PER7272Neglectedsame answer carried forward
PER728+16\sqrt{2}Changed, still wronguptake happened; repair did not
PER96192Repairedchanged and now correct
Broadcast8 + 4\sqrt{2}8 + 4\sqrt{2}Neglectedhappens under broadcast too, just less often
Broadcast132252Repaired

Counting these transitions requires care, because the two protocols are not eligible on the same terms. Over the whole benchmark there are 1,992 such useful-review episodes under PER and 1,742 under broadcast. Only a subset of each has an answer pair that parses on both sides and records the actor's own immediate response rather than a system-selected candidate: the strict pre-gate population, n = 379 for PER and n = 533 for broadcast. On that population, and on that population for both protocols:

Strict pre-gate transitions on useful-review episodes, Omni-MATH × gpt-oss-120b. Both columns use the same population definition.
 PERBroadcast
Useful-review episodes1,9921,742
Strict pre-gate population n379533
Answer unchanged234376
Changed, still wrong11553
Repaired1316

The remaining changed rows in each column are transitions the evaluator did not label on both sides, so they support no repair verdict either way.

Why the strict population, and not simply everything that parses. Under broadcast, a further 445 parseable episodes are excluded because a system-selected candidate update intervened before the actor responded — the answer moved, but not as an immediate reply to the critique. Counting those would attribute the approval gate's own bookkeeping to critique uptake, which is precisely the confound the strict definition exists to remove; it would raise broadcast's apparent repair count from 16 to 67 without a single additional actor response. PER has no such rows — the strict filter removes nothing from it — so including them would compare the two protocols over different populations. This is also why no causal claim about the approval gate appears on this page: the gate changes what is even measurable, as noted in Limitations.

What these rows are and are not. They are answer-string transitions with an evaluator verdict attached. The label "Neglected" means the answer did not change, not that the solver read the critique and disregarded it, and not that the critique was well written. This release contains no semantic labelling of critique text, so no claim of that kind is made anywhere. Note also that most episodes never reach the strict population at all — usually because one side of the answer pair could not be parsed — so the counts above are over that restricted remainder, not over all 1,992 and 1,742 episodes. The released table carries an explicit exclusion reason for every row, which is what makes the two populations auditable.

07What is released, and how to reproduce it

The target reader is someone with no access to the authors' machines, storage, endpoints or credentials. Everything below is designed to work from the public repository and the public dataset alone.

Artifact 1

Traces & labels

Per-episode symmetric review transitions, per-cell derived tables and the evaluator-replay labels, on Hugging Face. The pinned intermediate table ships inside the release so Track A does not depend on any private upstream.

AgentsSci/NeurIPS26_Precise-but-Uncoupled

Artifact 2

Analysis & protocol code

The analysis pipeline that turns traces into the published tables, the protocol runtime, the exact matched configs, and the regression tests for the resource-accounting fix.

ChihHsuan-Yang/NeurIPS26_Precise-but-Uncoupled

Artifact 3

Figures & tables

The figure-regeneration script and the aggregate CSVs it reads, so every published figure can be rebuilt from the released tables without re-running inference.

Shipped in the repository under figures/ and report/.

Two tracks, and which one answers your question

What each reproduction track requires and guarantees.
 Track A — offline artifact reproductionTrack B — live protocol re-execution
Needs a model endpoint? No. Zero model calls. Yes — your own OpenAI-compatible endpoint, supplied as base_url + api_key from the environment.
Entry point make reproduce-analysis make smoke-live for a few problems; full-scale instructions in the repository.
What it regenerates The central result tables, the process metrics, the evaluator-replay summaries, the uncertainty estimates, the post-rebuttal robustness matrix, and the publication and website figures. Fresh trajectories under any of the four protocols, from which the same analysis can then be run.
Determinism Deterministic and checksum-verifiable. Outputs match exactly, or within documented numerical tolerances. Expected to vary. There is no seed: the hosted endpoint runtime is not frozen and exposes none, so every run is an independent execution.
Cost and time About a minute on a normal laptop for the core pipeline. No GPU, no HPC allocation. Depends on your endpoint. The smoke target is deliberately tiny. ALCF and PBS are not required — nothing in the release hardcodes a private endpoint.
If your numbers differ That is a bug — please open an issue. The released checksums pin the inputs. Expect PER FinalPass to move about ±0.5 pp and broadcast about ±2 pp between independent executions (measured on a frozen N = 195 subset). The broadcast > PER direction reproduced on both tested backends, but one of four intervals crossed zero.

Get started

# 1. get the code
git clone https://github.com/ChihHsuan-Yang/NeurIPS26_Precise-but-Uncoupled.git
cd NeurIPS26_Precise-but-Uncoupled

# 2. get the data (no credentials needed once the dataset is public)
make fetch-data

# 3. Track A — verify checksums, then rebuild every table and figure.
#    No model calls. No endpoint. No GPU.
make verify-checksums
make reproduce-analysis
# Track B — re-run a protocol against YOUR OWN model service.
# Any OpenAI-compatible endpoint works; nothing private is baked in.
export OPENAI_BASE_URL="https://your-endpoint.example/v1"
export OPENAI_API_KEY="your-key"

make smoke-live          # a handful of problems, minutes not hours

The public model identifiers used in the paper are openai/gpt-oss-120b (all acting roles and the evaluator) and, for the appendix cross-family replication, gemma-3-27b-it with the evaluator still fixed to gpt-oss-120b. Decoding was temperature 0 throughout. The repository's README carries the authoritative, versioned form of these commands; if this page and the README disagree, the README is correct.

An honest note about cross-linking. arXiv v1's comments field currently advertises a different page — the authors' AgentsSci resource site — and contains no link to this page or to the repository. Until an arXiv v2 is submitted, the paper of record does not link here. The v1 text says only that "code and data will be released after institutional approval"; this release is what fulfils that statement.

Licensing and data use — read before you download

The released dataset spans five benchmarks and inherits their terms. Two of them restrict what you may do.

  • MaScQA is CC BY-NC-SA 4.0 — NonCommercial. Commercial use is not allowed.
  • LAB-Bench is CC BY-SA 4.0 — ShareAlike, and carries an upstream do-not-train request. The LAB-Bench contamination canary is preserved verbatim in the release; do not strip it, and please honour the upstream request not to train on that material.

Because the release combines these sources, the combined artifact inherits both the NonCommercial and the ShareAlike conditions. It is published under a composite licence rather than a single permissive one, with a machine-readable per-source table so you can filter to the subset whose terms suit your use.

Per-source terms carried through the release.
Source benchmarkLicencePractical effect
Omni-MATH 2Apache-2.0Permissive; commercial use allowed under upstream terms.
JEEBenchMITPermissive; commercial use allowed under upstream terms.
SciBenchMITPermissive; commercial use allowed under upstream terms.
LAB-BenchCC BY-SA 4.0ShareAlike: derivatives must carry the same licence. Upstream asks that it not be trained on. Canary preserved.
MaScQACC BY-NC-SA 4.0NonCommercial — commercial use not allowed. ShareAlike also applies.

The models used are third-party public checkpoints under their own terms — openai/gpt-oss-120b is Apache-2.0. The paper itself is on arXiv under the arXiv.org perpetual non-exclusive license 1.0, which is not a Creative Commons licence.

08Limitations

Four limits shape what can and cannot be concluded. The first three bound the science; the fourth is a defect in the published artifact that this release corrects.

1. Benchmark and model scope

The paper's result is measured on one benchmark — Omni-MATH 2 filtered, N = 4,181 — with one actor family, gpt-oss-120b, serving every role including the evaluator. The appendix adds a Gemma-3 cross-family replication on a tier-sampled N = 835, and the post-rebuttal matrix adds four further benchmarks with Gemma-4 actors. That is two model generations and five benchmarks in total. Nothing here generalises to model families that were not tested. Two tiers of the main benchmark, tier 3 (n = 20) and tier 10 (n = 15), are too small to support tier-level conclusions, and several post-rebuttal cells have fewer than ten evaluable follow-ups.

Relatedly: which protocol wins is setting-dependent. Gemma-3 actors reverse the accuracy ranking. This page makes no universal claim that one protocol beats the other.

2. No causal isolation of the approval gate

The natural mechanistic story — "collective re-approval forces uptake" — is not established here, and cannot be with the available controls. Turning the approval gate off changes six of seven required invariants at once, so the toggle cannot isolate the gate's effect. PER and broadcast are complete protocol designs differing jointly in routing, shared state, feedback delivery, prompts and round structure; the comparison is configuration-level and descriptive. The ACK and EMB probes are directional within-PER evidence, not a clean ablation. The isolated causal effect of any single mechanism remains an open question.

3. Operational metrics, not semantic ones

CouplingRate and the repair rates are answer-transition statistics grounded in the evaluator's verdict. They say nothing about whether critique text was correct in its reasoning, whether the solver understood it, or whether a neglect was reasonable. A blinded taxonomy of why critique was neglected would require per-problem intervention traces that were not retained, so it is not possible from this release. Separately, the evaluator is an LLM: on the hardest collaborative slice, independent evaluators disagree on about 5–10% of instances, which is exactly where answer equivalence is most ambiguous.

4. The legacy cost accounting in arXiv v1 is invalid — and is withdrawn here

Do not use the token, model-call, or cost numbers printed in arXiv v1. The harness reused one solver object per worker and the token counters were never reset between problems, so the recorded per-problem token and model-call figures are cumulative within a worker rather than per problem. The defect was confirmed independently at both the code and the data level: the exported counters show a sawtooth reset pattern, and averaging the cumulative snapshots reproduces the published means exactly.

Exact recovery is not possible — no worker-boundary metadata survived the export and no lower-level request logs were retained. Everything downstream of those fields is therefore withdrawn: the token columns of the main and intervention tables, the cost-per-solve figures, the cost-performance frontier, the verifier-cost break-even thresholds, and the per-tier deployment guidance. Those figures and tables are deliberately not shown on this page.

What survives, and is used here:

  • Every accuracy result. FinalPassRate, Pass@1, the tier structure, the three-evaluator replay and all the review-transition labels are unaffected — they never depended on the token counters.
  • Wall-clock time, retained per trajectory in the released data. Useful as a realized-latency measure, but it is not a compute-matched comparison.

Evaluator call accounting is under review and is not published here. Those counts come from a different counter than the token fields, but an unresolved discrepancy in how they were recorded means they are withheld pending re-derivation rather than presented as cleared. No per-problem evaluator or model call figure appears anywhere on this page.

A compute-matched PER–broadcast comparison is infeasible in this harness: there is no aggregate generation-token ceiling to match on. In particular, the deeper-reflection PER variant is an accuracy stress test only and must not be described as token-matched. The released code carries the counter-reset fix and three regression tests, so runs made with the current harness do not have this defect — but the published legacy values cannot be repaired retroactively.

09Citation

Please cite the arXiv preprint.

@misc{yang2026preciseuncoupled,
  title         = {Precise but Uncoupled: Reviewer Precision Does Not Guarantee
                   Critique Uptake in Multi-Agent Math Reasoning},
  author        = {Yang, Chih-Hsuan and Jiang, Jingyan and Vasudevan, Vikram and
                   Yang, Cheng-Hau and Zheng, Huihuo and Chen, Le and
                   Huerta, Eliu A. and Vishwanath, Venkatram and
                   Foster, Ian T. and Thakur, Rajeev},
  year          = {2026},
  eprint        = {2607.15388},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  doi           = {10.48550/arXiv.2607.15388},
  url           = {https://arxiv.org/abs/2607.15388}
}
arXiv
arXiv:2607.15388 [cs.AI], v1, submitted 16 July 2026
DOI
10.48550/arXiv.2607.15388
Status
Accepted to NeurIPS 2026, Main Track. The arXiv record is still v1; an updated version is pending.
Contact
bellayang@anl.gov (corresponding author)

10Team and acknowledgments

Authors

Author list in publication order.
#AuthorAffiliation
1Chih-Hsuan YangArgonne National Laboratory — corresponding author
2Jingyan JiangArgonne National Laboratory
3Vikram VasudevanOregon State University
4Cheng-Hau YangArgonne National Laboratory
5Huihuo ZhengArgonne National Laboratory
6Le ChenArgonne National Laboratory
7Eliu A. HuertaArgonne National Laboratory; University of Chicago
8Venkatram VishwanathArgonne National Laboratory
9Ian T. FosterArgonne National Laboratory; University of Chicago
10Rajeev ThakurArgonne National Laboratory

Acknowledgments

This research used resources of the Argonne Leadership Computing Facility, a U.S. Department of Energy (DOE) Office of Science user facility at Argonne National Laboratory (ANL) operated under Contract No. DE-AC02-06CH11357. The work was also supported under the same contract by the DOE Office of Science's Advanced Scientific Computing Research Program and by Laboratory Directed Research and Development (LDRD) funding from ANL, provided by the Director, DOE Office of Science.

Related work from this group

This paper is one of several studies built on the same matched multi-protocol design. The group's resource site, AgentsSci — Measuring Multi-Agent Scientific Reasoning, collects the protocol definitions and the broader trace resources they share.