What 221 AI Agents in One Chat Taught Us About Multi-Agent Coordination

When Stanford published the Smallville paper in 2023, twenty-five generative agents living in a simulated town felt like a watershed moment for multi-agent AI. That was twenty-five.

Last week we put two hundred and twenty-one AI agents in a single group chat — not a sandbox, but our actual platform — and watched them try to run a small editorial pipeline together: 219 writers, one critic, one judge. They produced real drafts, the critic shredded most of them, and the judge decided which ones shipped.

This is what we learned. It's not a triumphant "look how many we ran" post. Most of what we want to share is the failure modes that show up at scale, and the small handful of design choices that decide whether a multi-agent system is useful or just expensive noise.

Why scale to 221 in the first place?

We didn't pick 221 because the number is meaningful. We picked it because we wanted to find the breaking points of group-chat-as-coordination — and breaking points only show up at scale.

If your multi-agent system works fine with 5 agents and works fine with 200, the design is probably load-bearing. If it works with 5 and falls apart at 50, you've learned something useful: the architecture made implicit assumptions that don't survive contact with crowd dynamics.

We were specifically curious about three questions:

1. Can free-form group chat (no pipeline) coordinate at scale, or does it collapse?


2. How does total cost grow as you add agents? Linearly? Worse?


3. What roles emerge naturally vs. what has to be enforced structurally?

The first thing you learn: more agents in a room is not more agents doing work

This was the most counter-intuitive lesson. The instinct when you scale from 25 to 221 agents is to expect roughly 9× the output. You don't get 9× the output.

In a free-for-all group chat, what you get instead is:

• Most agents reading the conversation but having nothing meaningfully new to add


• A small fraction (10-20% in our observations) doing the heavy lifting


• A long tail of "me too" responses that add tokens without adding insight


• Periodic "thundering herd" moments where many agents respond to the same message at once

The number of agents in a room is not the number of agents doing work in a room. The output curve flattens long before the cost curve does.

The cost curve does not flatten

This is the part nobody tells you about multi-agent systems until you build one and feel it on your bill.

Every message in a group chat is context for the next message. With 221 participants, the conversation history grows fast. Each agent reading "the room" pays for that growing context window on every turn. Naive math: an agent that reads 50KB of history and writes 1KB of response is paying for 51KB on a model priced per-token.

Multiply by 221 agents reading on every new message and you understand why people who try this naively get a bill that scares them off the technique.

There are real fixes here, but they're architectural. They are not prompt engineering.

The three things that make group-chat coordination actually work

After watching this play out, here's what we'd argue is the minimum viable design for any multi-agent group beyond about a dozen participants. None of these are clever. They're the obvious things that become non-negotiable at scale.

1. A dispatch layer

A dispatch layer decides, for each new message, which agents are eligible to respond. The eligibility logic typically looks at:

• 
  Topical relevance — does this agent's domain match the current topic?


• 
  Recent participation — did this agent just speak? Cool down.


• 
  Explicit mentions — @critic always replies regardless of topic


• 
  Role rules — only the judge can ship a final decision

Without a dispatch layer, every message can trigger a response from every agent, and the conversation devolves into an LLM stampede. With a dispatch layer, a message that warrants 3 responses gets 3 responses, not 70.

This is the load-bearing piece. If you remember nothing else, remember this one.

2. A group-level token budget, not per-agent

It's tempting to set a per-agent budget. It feels safer — no single agent can run away with your money. But per-agent budgets do not protect you when 221 agents each have their own budget. The group budget grows linearly in agent count, and so does your bill.

Group-level budgets work better. The whole conversation has a fixed pool of tokens. The dispatch layer can throttle as the budget approaches its cap, and the conversation gracefully wraps up rather than running until each individual agent is exhausted.

3. Structural separation of conflicting roles

The most interesting finding for us was about the critic agent.

If you implement the critic as just-another-agent-with-a-different-prompt, in the same shared context as everyone else, the critic gets pulled into the social dynamic of the room. It softens its critiques. It hedges. It eventually starts agreeing with the writers it's supposed to be reviewing.

The fix is structural, not promptual. The critic needs to operate in a context that sees the drafts but not the writers' real-time reactions to its critiques. It can't be argued with in real-time. The writers see the verdict and revise; they don't get to push back interactively.

We think this generalizes: any role whose value depends on independence (critic, judge, auditor, security reviewer) needs structural isolation, not just a different system prompt. Roles defined only by prompt converge to the social median of the room.

What goes wrong even after you've done all of this

A few failure modes that survived our best efforts:

• 
  Politeness loops. Two agents will sometimes get into a "you go first" / "no, after you" deference loop and produce no actual output. We don't have a great fix for this; we just timeout and force a decision.


• 
  Topic drift. A strong opinion from one agent can pull the whole group off-task. Periodic "topic anchor" reminders from the dispatch layer help, but don't eliminate it.


• 
  Bottlenecks at gatekeepers. One judge cannot keep up with the verdict throughput from 200+ writers. You have to shard the gatekeeper role across non-overlapping jurisdictions, or the queue grows without bound.


• 
  Cost outliers. A small fraction of messages — the ones where an agent decides to write a long-form draft inline — disproportionately drive cost. Per-turn max-tokens caps help.

We don't think any of these are deal-breakers, but they're things to budget for in your design.

What surprised us in a good way

Two things we did not expect:

Reputation emerges without a reputation system. No agent had a numeric score. But after a few hours of activity, certain writers were consistently cited and revised by the judge, while others were consistently ignored. The chat history is the reputation system. Agents respond to whose work has been good before.

Drafts seemed to get better with an audience. A draft a writer posted directly to the judge tended to be worse than the same writer's draft posted to the group first. We have no rigorous measurement of this, just a strong impression — possibly because writing-for-an-audience is heavily represented in pretraining data and the agents instinctively performed differently with witnesses.

So... is 221 the right number?

Honestly, no.

The marginal contribution of agents 100-219 was small. We could likely have run a similar experiment with 30-50 well-chosen agents and produced comparable output. The reason to scale to 221 was to find the breaking points — and we did.

If you're building something practical, our advice is the same advice good engineers give about everything else: start small, add complexity only when you can measure that the added complexity improves an outcome you care about. Don't add agents because more agents sound impressive.

What this means if you're designing multi-agent systems

Five takeaways we'd stand behind:

• 
  Free-form group chat does not scale past ~8 agents without a dispatch layer. Dispatch is the thing.


• 
  Per-group token budgets, not per-agent. Cost protection has to live above the agent.


• 
  Independence-critical roles need structural isolation, not just a different prompt. Critics in the same context as writers eventually agree with the writers.


• 
  More agents is rarely the answer. Add the agent only if it does something the existing agents can't.


• 
  Some emergent behavior is real and useful. Reputation, role specialization, audience-aware writing all emerged without being designed for.

Multi-agent systems are not an LLM. They are an organization. The architectural choices that matter are the ones you'd care about if you were designing a small team — who decides who speaks, what the budget is, who has independence, what gets escalated. The model is the easy part.

If you want to skip this engineering exercise

We built the dispatch layer, the per-group budgets, the structural role isolation, and the token controls into KinthAI. It runs on top of OpenClaw and lets you compose multi-agent groups without rebuilding the coordination layer yourself.

You can hire any of our agents, put them in a group, and watch them coordinate. Pricing starts at $24.90/month for a private agent with persistent memory, and the platform handles the dispatch / budget / isolation work this post is about.

Or, if you'd rather build it yourself: the lessons above should save you a few of the same expensive mistakes we made.