Group Chat Patterns: Round-Robin, Selector, and Swarm for LLM Agents

Supervisor patterns keep coordination centralized. Swarm patterns move it to handoffs between peers. Shared scratchpad lets agents work against a common state. All three share a question that none of them settles: when the conversation involves more than two agents, who speaks next?

Group chat patterns formalize the answer. Microsoft AutoGen was the first framework to treat the question as first-class and names four distinct patterns for deciding which agent takes the next turn (Wu et al., 2023). The patterns are orthogonal to the coordination topology covered in the previous three articles; they apply whenever more than two agents participate in the same conversation. This article walks the four patterns, the termination conditions that go with them, and when each is the right choice.

Four ways to pick the next speaker

flowchart LR
subgraph "Round-Robin"
direction TB
A1[Agent A] --> A2[Agent B]
A2 --> A3[Agent C]
A3 --> A1
end

subgraph "Selector"
direction TB
S1[Selector LLM] --> S2[Choose A, B, or C]
end

subgraph "MagenticOne"
direction TB
M1[Orchestrator with dual ledger] --> M2[Pick next based on progress]
end

subgraph "Swarm chat"
direction TB
SW1[Current agent] -->|handoff| SW2[Next agent]
end

Round-robin cycles through a fixed list. Agent A speaks, then agent B, then agent C, then back to agent A. No decision is made at runtime about who is next; the order is set in code. The pattern is the simplest and the most predictable.

Selector uses an LLM to decide who should speak next. The selector reads the conversation so far and emits a name from the list of available agents. The pattern is dynamic but requires the selector to understand the capabilities of each agent, which puts pressure on the selector's prompt.

MagenticOne orchestrator uses a specialized dual-ledger system (task ledger plus progress ledger) to pick the next speaker based on the current progress of the plan. It is effectively a selector with structured state awareness; the ledger makes its decisions more consistent than a plain selector LLM.

Swarm chat uses handoff messages, as in the swarm pattern covered two articles ago. The current agent decides when to transfer; the next agent is whoever the handoff names. Coordination is distributed; no central decider exists.

Each pattern has a sweet spot. Round-robin works for structured review pipelines where every agent needs to contribute on every iteration. Selector works for dynamic collaboration where the right next speaker depends on what was just said. MagenticOne works for open-ended research where plan and progress need explicit tracking. Swarm works for linear escalation flows.

Two versions in code

The excerpt below shows round-robin and selector without a framework. Round-robin is a simple index counter; selector is an LLM call whose output is the name of the next agent.

from openai import OpenAI
from pydantic import BaseModel
from typing import Literal

client = OpenAI()

class NextSpeaker(BaseModel):
name: Literal["writer", "reviewer", "fact_checker"]

def round_robin(agents: list, messages: list, max_turns: int = 6) -> list:
i = 0
for _ in range(max_turns):
agent = agents[i % len(agents)]
reply = agent(messages)
messages.append(reply)
if reply.get("terminate"):
return messages
i += 1
return messages

def selector(agents: dict, messages: list, max_turns: int = 6) -> list:
for _ in range(max_turns):
r = client.responses.parse(
model="gpt-4o-mini",
instructions=("Given the conversation, pick the best next speaker. "
"Available: writer, reviewer, fact_checker."),
input="\n".join(m.get("content", "") for m in messages[-6:]),
text_format=NextSpeaker)
name = r.output[0].content[0].parsed.name
reply = agents[name](messages)
messages.append(reply)
if reply.get("terminate"):
return messages
return messages

The LangGraph version supports all four patterns via different graph topologies. Round-robin is a sequential chain of nodes; selector is a conditional edge that maps the selector's output to the next node; swarm uses Command objects; MagenticOne is typically wired through the magentic-one-group-chat integrations in the wider LangChain ecosystem.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langchain.chat_models import init_chat_model

model = init_chat_model("gpt-4o-mini")

class State(TypedDict):
messages: list
rounds: int
terminate: bool

def round_robin_edge(s: State) -> str:
if s["terminate"] or s["rounds"] >= 6:
return "end"
return ["writer", "reviewer", "fact_checker"][s["rounds"] % 3]

def selector_edge(s: State) -> str:
if s["terminate"] or s["rounds"] >= 6:
return "end"
r = model.with_structured_output(NextSpeaker).invoke(
f"Pick next speaker:\n{s['messages'][-3:]}")
return r.name

Full runnable versions will live at github.com/subodhjena/agentic-patterns under examples/20_group_chat.py as that lesson lands in the repo.

Termination conditions

A group chat needs a way to stop. AutoGen ships eleven composable termination conditions, named below. They are worth knowing because production group chats rarely use a single one in isolation.

MaxMessageTermination. Stop after N total messages.

TextMentionTermination. Stop when a specific phrase appears (for example "DONE").

TokenUsageTermination. Stop when cumulative token usage crosses a threshold.

TimeoutTermination. Stop after wall-clock seconds.

HandoffTermination. Stop when a handoff names a terminal agent.

SourceMatchTermination. Stop when a specific agent speaks.

ExternalTermination. Stop when an external signal is received.

StopMessageTermination. Stop when any agent emits a StopMessage.

TextMessageTermination. Stop when a text message matches a pattern.

FunctionCallTermination. Stop when a specific function call is emitted.

FunctionalTermination. Stop when an arbitrary callable returns True.

The conditions compose with boolean operators: MaxMessageTermination(10) | TextMentionTermination("DONE") stops on whichever fires first. In practice, every production group chat has at least a message cap and a token cap; specialized conditions layer on top.

Where each pattern wins

The four patterns are not substitutes; each covers a different operating regime.

Round-robin. Works when the structure of the collaboration is fixed and known in advance. Writer-reviewer-fact-checker cycles, peer-review pipelines, and orchestrated pair-programming fit. Predictability is high; adaptivity is zero.

Selector. Works when different phases of the work need different speakers but the phases are not pre-scripted. Debugging sessions, collaborative problem solving, and open-ended design reviews benefit. The selector's prompt is the load-bearing component; a poorly tuned selector collapses into a noisy round-robin.

MagenticOne orchestrator. Works when the task is long, open-ended, and benefits from explicit plan tracking. The dual ledger is overhead for short tasks; it pays off when the team works on something for many turns.

Swarm chat. Works when the conversation is linear and ownership genuinely transfers between specialists. Customer service is the textbook case.

Where group chats go wrong

The failure modes below recur across all four patterns.

Redundant contributions. Every agent feels obligated to speak on every turn, producing cycles of near-identical content. Give agents a "nothing to add" response and let them stay silent.

Runaway conversations. Without strict termination, the conversation continues past the point of usefulness. Always combine MaxMessageTermination with at least one content-based condition.

Selector misfires. The selector repeatedly picks the same agent, or cycles through a subset of the team. Tune the selector's prompt; add examples of when each agent should be invoked.

Context bloat. Every agent reads the full conversation at every turn. On long chats, the context window fills. Apply compaction between turns or use sliding windows of recent messages.

Role drift. An agent primed for writing starts reviewing, and vice versa, because the shared conversation is full of reviewer output. Keep each agent's system prompt strict about their mandate.

Silent failures. An agent produces garbage but the group accepts it. Add per-agent quality checks or a supervisor that vetoes clearly wrong contributions.

Trade against single-agent and simpler multi-agent shapes

Group chat is only the right pattern when the collaboration actually needs multiple agents in the same conversation. For many workloads, a supervisor or a chain is simpler and cheaper.

Axis | Single agent | Supervisor | Shared scratchpad | Group chat
Speakers in one turn | 1 | 1 (specialist) | 0 to many (async) | 1 (chosen)
Next-speaker decision | None | Supervisor picks | Any agent writes | Pattern-specific
Best team size | 1 | 3 to 10 | 2 to 4 | 2 to 5
Adaptivity | Low | Medium | High | High (selector), low (round-robin)
Overhead | Minimal | Supervisor turns | Shared state reads | Selector calls per turn

Group chat shines when agents need to respond to each other rather than be dispatched. That is a narrower case than casual multi-agent architecture diagrams suggest.

Neighbors in the series

Supervisor and router, hierarchical teams, handoffs and swarms, and shared scratchpad, the previous four articles, are the coordination topologies group chat patterns compose with. MagenticOne is referenced in the hierarchical teams article; this article is where its next-speaker selection is covered in depth. Human-in-the-loop, in the Safety stage, is often a participant in group chats as a distinguished speaker.

References

Wu, Qingyun, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. 2023.

Fourney, Adam, et al. Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks. Microsoft Research, 2024.

OpenAI. Swarm: lightweight multi-agent orchestration. 2024.

LangChain. Multi-agent patterns and selectors in LangGraph. 2024.