Divergent-Convergent Reasoning (DCR): how to give the model the role of a strict reviewer instead of majority voting

DCR is a two-step method: first the model generates many independent solutions to the same problem, then in a separate request it's asked to act as a strict reviewer — to find what most of the solutions agree on, where they diverge, and to assemble a final answer while specifically checking whether a minority solution contains a correct fix that the majority missed.

Ordinary majority voting (generate several answers, take the most common one) fails exactly where the correct answer landed in a small fraction of attempts and the wrong one landed in the majority. On hard problems this happens a lot: a model can get the same wrong answer 20 times and solve it correctly only 5 times, and at that point voting will pick the wrong answer, because it's just counting votes instead of checking the logic.

DCR fixes this through argument analysis instead of vote counting: the reviewer model looks for consensus steps, points of disagreement, and explicitly checks whether the "odd one out" among the variants is actually right. The recursive version repeats this analysis round after round until the reviewers reach full agreement — this yields higher accuracy with fewer requests overall, because easy problems converge fast while hard ones get more attention.

Method Blueprint

STEP 1 (Divergent Exploration, separate request):
Generate N independent solutions to the problem → pool of candidates

STEP 2 (Convergent Reconciliation, separate request):
Reviewer model analyzes the pool:
  1. Finds consensus steps (agreed on by the majority)
  2. Finds points of disagreement (where solutions diverge)
  3. Synthesizes a final answer, explicitly checking
     whether a minority variant might be right
→ one final answer

STEP 3 (optional, Recursive DCR):
Repeat STEP 2, feeding the previous reconciled output
back in as the new pool → until reviewers reach unanimous agreement
or a retry limit is hit

Example Use Case

Task: You're prepping for a banking analyst interview (JPMorgan, Goldman, Citi — pick your favorite) and working through a combinatorics number puzzle — the kind of thing that shows up in technical interviews. It's easy to slip up in an intermediate calculation, and different attempts at the same problem can land on different numbers.

Prompt (step 1):

Solve the following problem 5 independent ways.
For each way, start from scratch, don't look back at previous
attempts, use different reasoning approaches where possible.
Show the full solution for each variant.

Problem: [problem text]

Prompt (step 2, after getting the 5 solutions):

You are acting as a strict reviewer. Below are 5 independent
solutions to the same problem. Your job:

1. FIND CONSENSUS: which steps repeat across most solutions —
they're likely correct, do a quick sanity check.
2. FIND DISAGREEMENTS: pinpoint exactly where the solutions
diverge — these are the most contested spots, dig into them deeply.
3. SYNTHESIZE THE FINAL ANSWER: assemble a new solution from the
verified steps + your analysis of the contested spots. Important:
check whether the MINORITY solution contains a correct fix that
the majority missed. Don't dismiss it just because it's a minority.

Solutions:
[insert all 5 solutions]

Give the final, well-reasoned answer.

Result: The model will first flag the matching steps as reliable, then break down the specific points of disagreement — showing exactly where the approaches diverge and why. In the end it gives one answer with an explanation of why it was chosen, including a check on whether the lone dissenting solution was actually right.

Why This Works

An LLM can slip up on an intermediate step of a complex multi-step problem, and because generation is stochastic, different attempts at the same problem produce different answers. If you just take the most common answer — and the correct one happens to be in the minority — you get the wrong result.

In Plain Words: it's easier for a model to recognize a correct argument among ready-made options than to invent one from scratch — it's better at comparing and spotting contradictions than at solving blind.

DCR gives the model the role of reviewer with an explicit instruction to not vote but to analyze the logic of each variant. This lets it surface the correct answer even if only one attempt out of five got it right.

Control levers: - Number of variants (N) → 3-5 is enough for simple problems, more for hard ones, but that costs more - Number of recursion rounds → 1 round for routine tasks, for genuinely hard ones keep repeating the analysis until the model gives the same answer twice in a row - Stopping condition → in the original setup it's "unanimous reviewer agreement"; you can relax it to "confident consensus" for less critical tasks - The minority instruction → this is the key lever. Without an explicit "check whether the minority solution might be right," the model will just find consensus and there will be no amplification effect

Key Result

Prompt Template

STEP 1 — generate variants:
Solve the following problem {N} independent ways. For each one
start from scratch, don't peek at previous attempts, use different
approaches where possible. Show the full reasoning.

Problem: {problem}

---

STEP 2 — reconciliation (after getting the solutions):
You are a strict reviewer. Below are {N} independent solutions
to the same problem.

1. FIND CONSENSUS: steps that repeat across most solutions —
do a quick check on them.
2. FIND DISAGREEMENTS: points where the solutions diverge —
dig into them deeply.
3. SYNTHESIZE AN ANSWER: assemble a solution from the verified
steps + your analysis of the contested spots. Explicitly check
whether the MINORITY solution might be right — don't dismiss it
just because it's alone.

Solutions:
{insert all N solutions}

Give the final, well-reasoned answer.

Fill in {N} — the number of independent attempts (3-7 for most tasks), {problem} — the actual problem with a clear correct answer (calculation, logic, analytics).

🚀 Quick start — paste into the chat:

Here's a Divergent-Convergent Reasoning template. Adapt it to my task:
[your task]. Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask how many candidate solutions to generate and how critical accuracy is — that determines how many reconciliation rounds are worth running.

Limitations

⚠️ Mixing weak and strong sources: if you combine solutions from a weak model (or your own failed attempts) with high-quality ones, the weak variants can "contaminate" the analysis and drag the strong solution toward an error. The method works best when it lifts weak solutions up to the consensus level — not the other way around.

⚠️ Real diversity is required: if all the attempted solutions look alike, reconciliation won't add anything — the effect is stronger the more the original variants diverge from each other.

⚠️ Not for creative tasks: the method has been validated on problems with a single precise correct answer — math, logic, multiple-choice tests. For writing, ideas, or creative work, where many answers can be "right," the consensus/disagreement logic doesn't apply as cleanly.

⚠️ More expensive than a single request: the method requires several separate calls (generation + review, sometimes multiple rounds) — it makes sense to use where mistakes are costly, not for routine questions.

How It Was Studied

The researchers took four demanding benchmarks — olympiad-level math problems (AIME 2024/2025, MATH500) and multiple-choice tests (MMLU-PRO) — and ran them through four models of varying strength, from weak to top-tier. For each problem the model generated 25 independent attempts at a solution, which were then reconciled through a review request. This was compared against plain majority voting and against a "debate" method between peer agents (ReConcile).

It turned out that DCR beats voting almost across the board — especially in cases where the correct answer landed with only a small fraction of the attempts. That's exactly the zone where voting fails and reconciliation saves the day. The recursive version — with repeated rounds of analysis until unanimous agreement — achieved even higher accuracy while using roughly 27% fewer calls: easy problems converged in a single round, while hard ones got extra rounds of scrutiny.

The most interesting detail: the "debate" method between peer agents scored almost 40 percentage points worse than DCR. The difference is that DCR explicitly separates the role of author from that of strict reviewer, instead of just asking models to "work it out" among themselves as equals — a strict role hierarchy turned out to be critically important.

Resources

"Test-Time Scaling of Divergent-Convergent Reasoning" — Bo Wen, Yuhao Chen, et al. Enkira.ai, Queen's University, IBM T.J. Watson Research Center, University of Chicago, Tensormesh Inc. Related work for comparison: ReConcile (Chen et al., 2024a).