How to use Broadcast Groups for Multi-Agent Teams

I’ve spent a lot of time trying to build the perfect “do-it-all” agent, but it usually ends up bloated and slow. When one agent tries to handle code reviews, documentation, and security audits all at once, the logic gets messy and the context window fills up too fast.

I prefer breaking things down into smaller, specialized agents. The challenge has always been getting them to work on the same message without manual routing. With Broadcast Groups, I can now have an entire team of agents listen to a single WhatsApp group and respond at the same time.

What You’ll Need

• OpenClaw version 2026.1.9 or later.
• A WhatsApp web channel already configured.

Quick Start

Setting this up takes about five minutes. You just need to tell OpenClaw which WhatsApp chat should trigger multiple agents.

1. Identify your Peer ID

You need the ID of the chat where the broadcast will happen. For WhatsApp groups, this is the JID (like 120363403215116621@g.us). For direct messages, use the phone number in E.164 format (like +15551234567).

2. Update your Configuration

Add a broadcast section to your config file. Put it at the top level, right next to your bindings.

{
  "broadcast": {
    "strategy": "parallel",
    "120363403215116621@g.us": ["code-reviewer", "security-auditor", "docs-generator"]
  }
}

By default, the strategy is set to parallel, so all your agents will start processing the message at the same time. If you need them to go in a specific order, you can change this to sequential.

How It Works

When a message hits a broadcast group, OpenClaw bypasses the standard “first match” routing. Instead of picking one agent, it runs every agent you’ve listed for that ID.

I like this because each agent stays completely isolated. They each get their own:

• Session keys: Their history doesn’t mix with other agents.
• Workspaces: They can have separate sandboxes and file access.
• Tool lists: You can give one agent write access while keeping the others read-only.
• Models: You can run a fast model for a “Linter” agent and a heavy model for a “Security Auditor.”

Best Practices

To keep things running smoothly, I follow these four rules:

1. Keep Agents Focused: Give each agent one job, like formatting code or checking grammar.
2. Use Descriptive Names: Name them “Security Scanner” or “Test Generator” so it is clear who is talking in the chat.
3. Configure Different Tool Access: Only give an agent the tools it actually needs to do its specific job.
4. Monitor Performance: If you have 10 agents running in parallel, check your rate limits and model costs.

Troubleshooting

If things aren’t working as expected, check these four areas:

• Agents Not Responding: Make sure the agent IDs in your broadcast list exactly match the IDs in your agents.list.
• Only One Agent Responding: Check if the Peer ID is accidentally left in the bindings section but missing from broadcast. The system prioritizes the broadcast config.
• Performance Issues: If responses are slow, try using lighter models or reducing the number of agents in the group.
• Logs: You can watch the broadcast logic in real-time by running this command:

  tail -f ~/.openclaw/logs/gateway.log | grep broadcast

Need help building your first specialized agent team? Ask the AI Setup Assistant.

What’s Next

• Multi-Agent Configuration
• Routing Configuration
• Session Management