ICE in practice: how many iterations are enough, and when to stop

Iterations can improve an answer. They can also produce a bland average: polished text that takes no risks and teaches you nothing.

ICE (Iterative Consensus Ensemble) is best treated as a process pattern: multiple rounds, structured feedback, progressive tightening. Not as a promise that “more rounds = more truth”. The goal is convergence on quality, not convergence on style.

Here is a practical way to run ICE so each round adds signal, not just another rewrite.

Claims Framework

• What this article claims: ICE iterations are valuable only when they add new checkable signals. Without a quality definition, role separation, and stop conditions, iterations converge toward bland average text. A minority report is essential for preserving important objections.
• What it is based on: Shinn et al. (2023) Reflexion (verbal reinforcement learning), Wu et al. (2025) multi-agent debate, Dhuliawala et al. (2023) Chain-of-Verification, CrossChat internal ICE documentation.
• Where it simplifies: The article offers no empirical data on the number of iterations needed for convergence. Stop conditions are heuristic, not measurable thresholds.

1) Define what “better” means (otherwise convergence is just rhetoric)

Without a quality criterion, iterations naturally drift toward the safest output: vague phrasing, careful conclusions, fewer concrete commitments.

Start by writing 2–3 check questions:

• What must the answer contain to be usable?
• How would we detect a failure? (counterexample, test, source)
• What is the cost of being wrong? (and what must be verified)

This prevents “converging on nice prose”.

2) Separate roles: generator, critic, fact-checker, synthesizer

ICE fails when every model does the same job: generate an answer, then lightly rephrase it.

Roles break that monotony:

• Generator: proposes solutions and variants.
• Critic: hunts weak assumptions and missing constraints.
• Fact-checker: demands sources or testable steps.
• Synthesizer: combines, but must not erase disagreement.

Without roles, “iteration” often becomes paraphrasing.

3) Each round must add a new kind of signal

A useful iteration is not “better wording”. It’s “new information that can be checked or that changes the decision”.

Signals worth paying attention to:

• a concrete counterexample (“this will fail when…”),
• an explicit trade-off (“you gain X, you lose Y”),
• clarified definitions (“what ‘reliable’ means here”),
• a testable step (“verify in logs / docs / data”),
• a falsifier (“what would prove this wrong?”).

If a round adds no new signal, it wasn’t worth running.

4) Require a “minority report” in every round

The biggest loss in iterative synthesis is quiet: the minority objection dissolves into the summary.

Make it explicit:

• each round ends with a short “minority report”,
• that report must be rewritten as a checkable claim or concrete risk.

Example:

• Bad: “This feels risky.”
• Good: “Claim A depends on assumption B. If B fails, the plan fails. Verify B with this test.”

Minority reports are fuel for the next round. Without them, you converge to the average.

5) When to stop: stop conditions beat a magic number of rounds

“How many rounds?” invites a universal number. Better: use stop conditions.

Stop when most of these are true:

• New rounds no longer add new signals (they only rewrite).
• Key claims are stable and defended (by sources, tests, or logic).
• The minority report was resolved by verification, or reduced to a clear trade-off.
• You know what to verify next, but it requires external data.

If rounds keep producing concrete new objections, that doesn’t mean the process is broken. It means the task is genuinely hard and needs verification beyond chat.

Common mistakes

• Chasing agreement instead of quality.
• Letting critique degrade into style comments.
• Erasing minority views in synthesis without turning them into checkable claims.

Quick reference: one ICE session checklist

• Define the quality criterion.
• Assign roles (generator/critic/fact-checker/synthesizer).
• Require a new signal each round (test, source, counterexample).
• Require a minority report.
• Use stop conditions (signal saturation, stable claims).
• For factual stakes, add verification beyond chat.

Conclusion

ICE works when iterations mean “more control”, not “more text”. When checkable signals stop increasing, another round is usually just cosmetic.

Soft CTA: CrossChat becomes useful when roles, iteration, and checkpoints are explicit workflow steps rather than improvisation.

Sources

• CrossChat internal technique overview: docs/WORKFLOW-TECHNIKY.md (ICE section)
• Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366 DOI: 10.48550/arXiv.2303.11366
• Wu et al. (2025). Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning. arXiv:2511.07784 DOI: 10.48550/arXiv.2511.07784
• Dhuliawala et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495 DOI: 10.48550/arXiv.2309.11495

Editorial History

Concept: Codex CLI + GPT-5.2 Version 1: Codex CLI + GPT-5.2

Quality audit (2026-03-23, Claude Code + Claude Opus 4.6): added Claims Framework, verified sources, language polish.