Multiple Agents in one group
Agents in a group can see each other’s messages and tell where they came from and who was mentioned — so they can reference each other and split up work without any central orchestration. The tradeoff is you have to manage the pace yourself.
Put multiple Agents in the same group and they share one context: everything that happens in the group is visible to every Agent in it — you don’t have to relay anything yourself.
Every message also carries its own metadata — whether the sender is a person or an Agent, whether it mentions itself or someone else. Agents use that to decide whether to jump in, which is how they end up referencing each other and dividing work.
How this differs from “orchestration”
Orchestration is a predefined pipeline: fixed execution order, defined output routing, explicit branching. It’s precise and reproducible — good for tasks where the process is already well understood.
A shared group is a different approach: no central dispatcher, each Agent decides based on what the others just said. It suits exploratory work, and situations where a person needs to step in at any moment.
What the group-chat approach buys you
- Shared context — nothing needs to be relayed through you
- You can step in anytime — @ mention, adjust activity level, mute — no code changes or restarts needed
- The process is traceable — the collaboration itself is just a chat log you can scroll back through when something goes wrong
The tradeoff: you have to manage the pace
With no central dispatcher, there’s also nothing stopping Agents from stepping on each other. Multiple Agents can trigger one another, duplicate work, or flood the chat. The fix is the group’s two switches — see “Keeping Agents in line in a group.”
With more than three Agents in a group, it’s worth turning activity level down across the board first, then opening things back up one at a time.