Skip to main content
GroupChat runs a turn-based, self-selecting discussion. Every agent sees the whole conversation, and each turn every agent privately bids on whether to speak. The single highest bidder above a threshold takes the floor, and only its reply is posted. There is no fixed speaking order: who speaks emerges from the bids, and a recency penalty keeps one agent from monologuing. This suits debates, brainstorming, and decision-making where you want natural dialogue rather than a rigid rotation.
The older design (a speaker_function, round-robin/random/priority speakers, @mention routing, interactive REPL sessions, and an asynchronous room where several agents could post at once) has been removed. See the GroupChat API reference for the full parameter list.

How Group Chat Works

  1. Seed: the task is posted to the shared conversation as the first message.
  2. Bidding: each turn, every agent is asked concurrently (through a forced respond(score, message) tool call) how much it wants to speak on a 0..1 scale, along with the reply it would give.
  3. Recency penalty: agents that spoke within the last recency_window turns have recency_penalty subtracted from their score.
  4. One speaker: the highest adjusted bid that carries a non-empty reply and exceeds threshold wins the turn. Only that reply is posted.
  5. Stop condition: the chat ends at the first lull (a turn where no agent clears threshold), or once max_loops total messages have been posted.

Key Characteristics

  • Turn-based: exactly one agent speaks per turn; bids are collected in parallel.
  • Self-selecting: each agent scores how useful a reply would be right now, and low-value replies (filler agreement, repeated points) are told to score low.
  • Shared context: every agent sees the full transcript before bidding.
  • Bounded: max_loops caps total messages, and a lull ends the chat early.
  • Auto-equipped: with auto_equip=True (default), the respond tool is injected into each agent for you.

Key Parameters

idle_timeout is still accepted for compatibility but is unused: the chat now ends on a bidding lull, not a wall-clock timeout.

Basic Example: Tech Debate

A two-sided debate about AI’s societal impact. Each agent uses max_loops=1 and persistent_memory=False so every speaking decision is a clean single-shot call.
By default result is a formatted string (output_type="str-all-except-first"). To iterate over individual messages, set output_type="list":
Each message dict carries role (the agent name, or "User" for the seed task) and content.

Real-World Examples

Business Strategy Discussion

Executives with distinct mandates weigh in only where they have something to add.

Medical Case Conference

Tuning the Conversation

Because there is no fixed turn order, you shape the conversation with threshold, recency_penalty, and max_loops rather than a speaker function.

A livelier room

A more selective room

Bounding total length

max_loops is the primary cost control — it caps the total number of messages posted (the seed task included), not the turns per agent.

Best Practices

1. Give each agent a distinct, specific role

Distinct roles make the respond bid meaningful: agents bid high inside their lane and stay quiet outside it.

2. Use max_loops=1 and persistent_memory=False per agent

Each participating agent should make a clean, single-shot decision per message. Stateful memory across decisions can distort the speaking score.

3. Tune threshold to the room size

  • Few agents (2–3): a lower threshold (~0.4–0.5) keeps the dialogue flowing; a high one ends the chat at the first lull.
  • Many agents (4+): raise it (~0.6–0.75) so only the most relevant speaker takes each turn.

4. Tune recency_penalty for back-and-forth

The default 0.3 makes the last speaker less likely to win the next turn. Raise it to force more rotation, or set 0.0 to let a strongly motivated agent reply twice in a row.

5. Choose the right output_type

  • "str-all-except-first" (default) — a single readable transcript string.
  • "list" / "dict" — structured messages you can iterate (role, content).

When to Use Group Chat

Ideal for:
  • Debates and discussions — exploring opposing viewpoints.
  • Collaborative decision-making — stakeholders converging on consensus.
  • Brainstorming — emergent ideas from whoever has the most to add.
  • Negotiation — parties working toward agreement.
  • Peer review — evaluating work from multiple angles.

When NOT to Use Group Chat

  • Simple tasks — the coordination overhead isn’t justified (use a single Agent).
  • Independent analysis — when agents shouldn’t influence each other (use ConcurrentWorkflow).
  • Strict ordering — when a fixed sequence is required (use SequentialWorkflow).
  • Hierarchical coordination — when a director must delegate (use HierarchicalSwarm).

Comparison with Other Patterns

Learn More