Catalog / Orchestration
Group chat and debate
Several agents with different roles share one conversation thread. They argue the case in rounds until a chat manager decides they are done.
Reference task used across all patterns: "My order arrived damaged. Can I get a refund?"
Topology
Run
08 steps
Ready to run
Play runs the whole scenario. Step advances one event at a time so you can read what happens.
Metrics
| Wall-clock time | 0.0 s |
|---|---|
| Tokens processed | 0 |
| Estimated cost | $0.000 |
| Debate rounds | 0 |
All steps
Normal run
- Request arrives. The chat manager owns the thread. It decides who speaks next and when the discussion is over.
- Open the thread. All three participants join one shared conversation. Unlike workers, each will see everything the others say.
- Opening positions. Each role reads the case through its own lens. The value of the pattern is that these lenses disagree.
- Positions posted. Two are in favour. The risk analyst objects, since a damage claim with no photo attached is a known fraud pattern.
- Round two. Everyone rereads the whole thread. The policy expert answers the objection with evidence, because the carrier itself confirmed the damage.
- Consensus. New evidence changed a position, which is the only kind of round worth paying for.
- Close the thread. The manager's stop rule is met, as all three agree, and it writes the decision.
- Respond. Refund approved, after an objection was raised and answered. That scrutiny cost more tokens than the orchestrator run with its three workers.
Outcome: correct answer, stress-tested. The debate earned its cost because one participant disagreed and another had evidence. Every round makes all participants reread the thread, so cost grows faster than the number of rounds.
Failure mode
- Request arrives. Identical start to the normal run.
- Open the thread. Three participants, one shared thread.
- Opening positions. Nothing has gone wrong yet.
- A split. Two approve and the risk analyst rejects. In this run nobody brings the carrier's confirmation into the thread.
- Round two. With no new evidence, everybody restates their view at greater length. Each reads the full thread first, so this round costs twice the first.
- Still split. The positions have hardened rather than moved.
- Rounds three and four. The thread is now longer than anyone reads carefully, and the facts of order 4417 are buried under restatements of opinion.
- Budget exhausted. The manager's only stop rule was “until consensus”. The budget ends the debate instead, and there is no decision.
Failure: a debate with no way to end. Agents do not tire of arguing, and consensus is not guaranteed. Mitigation: cap the rounds, require new evidence to open another one, and give the manager a rule for a split, such as majority or escalation.
Execution trace
Reference
- Problem
- A decision benefits from several perspectives that should challenge each other, not merely be collected.
- Analogy
- A review board. Members with different remits argue a case in one room, and the chair calls the vote.
- Use when
- The decision is high-stakes and contestable, the perspectives really differ, and you can afford several times the cost of a single agent.
- Avoid when
- The answer is a fact that can be looked up, or the participants are the same model behind different names. Then agreement is cheap and meaningless.
- Typical failure
- No termination: the debate repeats positions without new evidence until the budget runs out.
- Also known as
- Group chat orchestration (Microsoft)GroupChat (AutoGen)Multiagent debate (Du et al.)
- Related patterns
- Orchestrator–workers (alternative)
- Magentic manager (alternative)
Space play or pause → next step ← previous step R reset F failure mode