How to Use OpenClaw Broadcast Groups

Broadcast groups are one of the cleanest ways to turn one chat into a multi-agent lane without pretending everyone shares a brain. The docs describe them as an experimental WhatsApp-only feature that lets several agents process the same eligible message simultaneously. The word eligible matters. Broadcast groups do not bypass your ordinary channel rules. They only change which agents run once OpenClaw has already decided the chat is allowed to trigger a reply.

Step 1: pick the right chat id

Broadcast config lives in a top-level broadcast section next to bindings. The keys are WhatsApp peer ids. For group chats, that means a group JID such as 120363403215116621@g.us. For DMs, it is an E.164 phone number like +15551234567. If you use the wrong identifier format, the whole thing will look fine in JSON and still never fire. The docs are specific here because the peer id is the actual routing key.

Step 2: list the agents that should run

The smallest working config is just the peer id mapped to an array of agent ids. When OpenClaw would normally reply in that chat, it runs every listed agent. Those agents must already exist in agents.list, and each one keeps its own workspace, tools, personality, and session key. That isolation is the feature. Broadcast groups are not a shared-room memory trick. They are fan-out routing with separate agent brains.

{
  "broadcast": {
    "120363403215116621@g.us": ["alfred", "baerbel", "assistant3"]
  }
}

Step 3: choose parallel or sequential strategy

By default, broadcast processing is parallel. That is usually what you want because it is faster and keeps agents independent. The docs also allow sequential mode if order matters or you want one agent to wait for another to finish. The strategy setting lives inside the same broadcast block. Parallel works well for review, translation, or specialized commentary. Sequential makes more sense when later agents should react to the earlier result timing, not merely the same input.

{
  "broadcast": {
    "strategy": "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"]
  }
}

Step 4: keep your normal routing and security rules in mind

The docs stress that broadcast evaluation happens after channel allowlists and group activation rules. In a WhatsApp group, that means OpenClaw still follows the normal rules about when it would reply, such as mention behavior. Broadcast also takes priority over bindings for that configured peer. So if you expected only one bound agent to answer and you added the group to broadcast, the broadcast definition wins.

Step 5: design agents with narrow jobs

The best-practices section is worth copying. Keep agents focused, use descriptive names, and give each one only the tools it actually needs. The docs even call out the difference between a read-only reviewer and a read-write fixer. That is the right way to think about broadcast groups. They are strongest when one agent reviews, one explains, and one tests, not when you clone three generalists and hope the chaos turns into quality.

If you want a practical starting point, use a two-agent WhatsApp group with parallel strategy. Give one agent a narrow specialist role and keep the other as a broader helper. Watch how the session isolation works, then expand only if the extra voices are genuinely useful. OpenClaw gives you the routing primitive. The real quality comes from disciplined agent design, not from stuffing the group with more personalities just because you can.

One subtle operational detail is session ownership. The docs say each agent gets its own isolated session key when a broadcast fires. That means follow-up context does not collapse into one shared transcript unless you explicitly design it that way elsewhere. For review lanes and multi-specialist workflows, that isolation is exactly what keeps one agent's conclusions from silently biasing the others.

If you want the operator version of these docs turned into a practical working system, read The OpenClaw Playbook. It connects official OpenClaw features to real workflows, guardrails, and deployment decisions.