Designing Multi-Agent Group Chat Systems: Routing, Conflict, and Coordination

Most multi-agent demos look great until two agents start arguing in a loop and your token bill hits four figures by lunch. The Researcher pings the Critic. The Critic asks the Researcher for clarification. The Researcher restates. The Critic critiques again. By turn 47 you've burned $63 of Claude Sonnet 4 tokens and produced a 12,000-token transcript that says nothing your single-agent baseline didn't already cover.

Group chat is the most seductive and most dangerous pattern in multi-agent design. It looks like a team. It behaves like a Slack channel where everyone replies to every message at 3am. The fix is not "better prompts" — it's actual systems design: routing rules, role contracts, claim locks, and termination guards. This post walks through how to build group chat systems that converge in under 8 turns instead of spinning until your budget alarm fires.

Why Naive Group Chat Collapses Into Chaos

The default AutoGen GroupChat pattern picks the next speaker via an LLM call against a manager prompt that sees the full transcript. In a 4-agent chat with a 60-turn conversation, that manager prompt balloons to 30K+ tokens by turn 30, and the manager itself starts hallucinating who should speak next. We measured this on a real customer build: a 5-agent research crew averaged 41 turns to converge, with the manager re-selecting the same agent 3 turns in a row 22% of the time.

The four failure modes that show up in production:

• Argument loops: Agent A proposes, Agent B critiques, A defends, B re-critiques. No external stopping condition, no synthesis, infinite ping-pong.
• Echo chambers: Three agents agree with each other in rotating order, each adding 200 tokens of restatement. The transcript grows; the answer does not.
• Silent claim conflicts: Two agents both start working on the same subtask without knowing it. You pay for the work twice and then pay a third time for an arbitrator agent to pick a winner.
• Manager drift: The speaker-selection LLM forgets its own selection policy after enough tokens and starts picking based on conversational politeness instead of who has the right tool.

Each of these is a routing failure, not a reasoning failure. The agents themselves are fine. The protocol between them is broken.

Routing Patterns That Actually Work

Pick the routing topology before you write a single agent prompt. The topology determines whether your system converges or thrashes. Three patterns dominate production systems in 2026:

The Broadcaster Pattern

One controller sends the same prompt to N workers in parallel. Each returns a candidate answer. A synthesis step (either another LLM call or deterministic merge logic) picks or combines. No agent ever talks to another agent. This is the cheapest, fastest pattern and the one most teams should use when they think they want group chat.

Use it when: you want diversity of opinion, parallel research, voting/jury patterns, or hypothesis generation. Don't use it when subtasks depend on each other.

The Supervisor Pattern

One supervisor agent owns the conversation. Workers respond only when addressed by the supervisor. Worker-to-worker communication is forbidden — if Worker A needs something from Worker B, A asks the supervisor, who decides whether to route to B. This is the LangGraph default for a reason: it cuts the speaker-selection problem from O(N) to O(1) and gives you one clear place to insert guardrails.

Critical detail most teams miss: the supervisor prompt should never see the full transcript. Give it a structured state object — current task, completed subtasks, pending claims, last worker output summary — and update that state deterministically between turns. We've covered this pattern in more depth in our multi-agent system patterns piece.

The Contract Net Protocol

Inherited from 1980s distributed AI research and still the cleanest pattern for dynamic task allocation. The supervisor announces a task. Workers bid (with a cost estimate and capability claim). The supervisor awards the contract to one worker. That worker reports back. Done.

The advantage over a fixed supervisor: you don't need to hardcode which agent handles which subtask. New agents register their capabilities and start receiving relevant work automatically. The disadvantage: bid gaming, where agents over-promise to win contracts they can't deliver. Mitigate with a reputation score updated from contract outcomes.

Conflict Prevention: Roles, Turn-Taking, Claim Locks

Routing tells agents when they can speak. Roles tell them what they're allowed to do. Most conflict in multi-agent systems comes from overlapping responsibilities, not from disagreement.

Role Contracts

Every agent gets a one-page contract that specifies four things:

1. Scope: What problems this agent is allowed to touch. Be specific. "Research agent" is not a scope. "Fetches and summarizes web sources for the current research task; never writes final output; never critiques other agents" is a scope.
2. Inputs: What schema the agent expects. If the supervisor sends something off-schema, the agent refuses instead of guessing.
3. Outputs: Strict JSON shape. No prose, no thinking-out-loud, no "here's what I did." Pure data.
4. Termination: Conditions under which the agent reports DONE and stops. Without this, agents continue working past usefulness.

A role contract is not a system prompt. It's a contract enforced by the orchestrator. If the agent returns something out of schema, the orchestrator rejects it and either retries or escalates — the downstream agents never see malformed output. This shifts you from prompt-engineering to interface design, and it's the single biggest reliability lever we've seen.

Turn-Taking Discipline

Three turn-taking strategies, in order of how much we trust them:

• Deterministic routing: Hand-coded rules in the supervisor. "If task type is research, route to ResearchAgent. If output contains a claim, route to FactChecker." Predictable, debuggable, no LLM call for routing. Use this whenever you can.
• Tool-routed: The supervisor calls a routing tool (a function with typed parameters) instead of free-text picking a name. Tool-call schema constrains the choice. Still cheap, more flexible.
• LLM-routed: A free-text manager call picks the next speaker. Last resort. Always combine with a hard turn limit and a fallback rule.

Claim Locks

Before an agent starts a subtask, it claims a lock on a named resource. If the lock is taken, the agent either waits or asks the supervisor to reassign. This is the same pattern as database row locks, applied to agent work. It prevents the "two agents researched the same source and wrote contradictory summaries" failure mode.

Implementation is dead simple: a key-value store (Redis, or an in-memory dict in a single-process system) mapping resource ID to agent ID with a TTL. The orchestrator gates work behind a lock acquisition. We use TTLs of 2x the expected task duration so crashed agents don't leave permanent locks. For more on this, our tool use best practices piece covers the related pattern of making tool calls idempotent.

Termination Conditions and Loop Guards

Every multi-agent system must answer one question before it runs: when does this stop?Demos rarely answer this. Production systems must. Three termination layers, all of which you need:

Layer 1: Task Completion

A semantic stopping condition. The supervisor checks: did we produce the expected output? Is the user's question answered? In supervisor patterns, this is a structured check (does the state object have a non-null final_answer field?). In broadcaster patterns, this is "all workers returned." Never trust an LLM to self-declare "I think we're done" as the only stopping condition.

Layer 2: Turn and Token Budgets

Hard caps. Max 20 turns per conversation. Max 50K tokens total. If either is hit, the orchestrator halts and either returns partial output or fails loudly. We've found that 90% of well-designed multi-agent tasks converge in under 10 turns; if you're at turn 15 you're in a loop. The cap saves you from the runaway $200 invoice.

Layer 3: Loop Detection

Cheap algorithmic check between turns. Hash the last N agent outputs. If the same hash appears 2+ times, or if a near-duplicate (cosine similarity >0.92 on embeddings) appears, you're in a loop. Break it by either forcing a different speaker, injecting a synthesis-and-decide instruction, or halting.

We've seen teams skip loop detection because "our prompts won't loop." They loop. Add the check — it's 20 lines of code and it pays for itself the first time it fires.

Observability: Tracing Message Graphs

Debugging a multi-agent system without traces is like debugging a microservice architecture by reading printf logs from each service in a single terminal. You will not find the bug. You need a real trace.

Minimum observability for production multi-agent systems:

• Per-turn structured log: turn number, speaker, recipient(s), token count in/out, tool calls made, claim locks acquired/released, latency.
• Message graph: a DAG view of who sent what to whom. Loops show up visually within seconds — a circle in the graph is a loop in your system.
• State snapshots: the supervisor's state object at each turn. When the system fails, you replay state forward and find the turn where logic broke.
• Cost per conversation: dollars spent rolled up by conversation, by agent, by turn. Without this you can't set budgets or tune for efficiency.

LangSmith, Langfuse, and Helicone all support this natively now. If you're rolling your own, OpenTelemetry spans with custom attributes work fine. The key is that traces are searchable and graphable, not just log-tailable.

A Production-Grade Reference Architecture

Here's the skeleton we ship for customer multi-agent builds when there's no good reason to do something more exotic:

1. Supervisor agent with a structured state object (not transcript-based). State holds: task spec, pending subtasks, completed subtasks, active claims, accumulated artifacts.
2. 3-7 worker agents, each with a strict role contract enforced by a JSON schema validator on output.
3. Deterministic routing via a Python/TS function that reads state and returns the next speaker. The supervisor LLM is only invoked when routing requires reasoning the function can't encode.
4. Claim-lock store in Redis with 5-minute TTLs.
5. Termination triple: task-complete check, 20-turn cap, 50K-token cap, plus loop detection on output embeddings.
6. Tracing via Langfuse, with per-turn spans and a graph view dashboard pinned in the team channel.

Token cost on this architecture for a typical research-and-synthesize task with 5 workers: 12K-22K input, 4K-8K output, ~$0.30-0.60 per conversation on Sonnet 4. Same task naive group chat: 80K+ input, 15K+ output, ~$2.50+ per conversation, with a 15% loop rate that doubles the average. The architecture pays for itself in your first 50 conversations.

Framework choice matters less than people think. AutoGen, LangGraph, CrewAI, and even hand-rolled orchestrators all support this pattern with roughly the same effort. We compared the major options in our AI agent frameworks comparison — the framework that wins is the one whose state model matches your team's mental model. If your team thinks in graphs, LangGraph reads cleanly. If your team thinks in role-based crews, CrewAI does. The routing principles above apply to all of them.

What To Do Monday Morning

If you have a multi-agent system in production right now, run this audit in the next 60 minutes:

• Pull the last 100 conversations. Histogram of turn counts. If the long tail extends past 15 turns, you have a loop problem.
• Compute average tokens per conversation. Divide by what a single-agent baseline would cost on the same task. If the ratio is over 4x, your routing is wasting money.
• Check whether your manager/supervisor prompt receives the full transcript. If yes, replace with a structured state object before next sprint.
• Verify every agent has a JSON output schema enforced by a validator. If not, you have silent malformed outputs corrupting downstream agents.
• Confirm you have hard turn and token caps. If not, add them today. This is the single highest-ROI fix for runaway costs.

Multi-agent group chat is not a prompt-engineering problem. It's a distributed systems problem with an LLM at each node. Treat it that way and your agents converge fast, stay on-budget, and stop arguing with each other in production. For the broader picture of taking these systems from prototype to production, our production-ready agents writeup covers the deployment side.