Overview

Broadcast groups run multiple agents on the same inbound message. Each agent processes the message in its own isolated session and posts its own reply, so one WhatsApp number can host a team of specialized agents in a single group chat or DM.

Broadcast groups are evaluated after channel allowlists and group activation rules. In WhatsApp groups, broadcasts happen when OpenClaw would normally reply (for example: on mention, depending on your group settings). They only change which agents run, never whether a message is eligible for processing.

The live WhatsApp QA lane includes whatsapp-broadcast-group-fanout, which verifies that one mentioned group message can produce distinct visible replies from two configured agents.

Configuration

Basic setup

Add a top-level broadcast section (next to bindings). Keys are WhatsApp peer ids, values are arrays of agent ids:

• group chats: group JID (e.g. 120363403215116621@g.us)
• DMs: sender E.164 phone number (e.g. +15551234567)

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

Result: when OpenClaw would reply in this chat, it runs all three agents.

Every listed agent id must exist in agents.list: config validation reports unknown ids, and the runtime skips them with a Broadcast agent <id> not found in agents.list; skipping warning.

Processing strategy

broadcast.strategy sets how agents process the message:

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

Complete example

{
  "agents": {
    "list": [
      {
        "id": "code-reviewer",
        "name": "Code Reviewer",
        "workspace": "/path/to/code-reviewer",
        "sandbox": { "mode": "all" }
      },
      {
        "id": "security-auditor",
        "name": "Security Auditor",
        "workspace": "/path/to/security-auditor",
        "sandbox": { "mode": "all" }
      },
      {
        "id": "docs-generator",
        "name": "Documentation Generator",
        "workspace": "/path/to/docs-generator",
        "sandbox": { "mode": "all" }
      }
    ]
  },
  "broadcast": {
    "strategy": "parallel",
    "120363403215116621@g.us": ["code-reviewer", "security-auditor", "docs-generator"],
    "120363424282127706@g.us": ["support-en", "support-de"],
    "+15555550123": ["assistant", "logger"]
  }
}

How it works

Message flow

Session isolation

Each agent in a broadcast group maintains completely separate:

• Session keys (agent:alfred:whatsapp:group:120363... vs agent:baerbel:whatsapp:group:120363...)
• Conversation history (an agent does not see other agents' replies)
• Workspace (separate sandboxes if configured)
• Tool access (different allow/deny lists)
• Memory/context (separate IDENTITY.md, SOUL.md, etc.)

One exception is shared on purpose: the group context buffer (recent group messages used for context) is shared per peer, so all broadcast agents see the same context when triggered. It is cleared once after the fan-out completes.

This allows each agent to have different personalities, models, skills, and tool access (for example read-only vs. read-write).

Example: isolated sessions

In group 120363403215116621@g.us with agents ["alfred", "baerbel"]:

Use cases

• Specialized agent teams: a dev group where code-reviewer, security-auditor, test-generator, and docs-checker each answer the same message from their own angle.
• Multi-language support: one support chat with support-en, support-de, support-es responding in their languages.
• Quality assurance: support-agent answers while qa-agent reviews and only responds when it finds issues.
• Task automation: task-tracker, time-logger, and report-generator all consume the same status update.

Best practices

`reviewer` is read-only. `fixer` can read and write.

Compatibility

Providers

Broadcast groups are currently implemented for WhatsApp (web channel) only. Other channels ignore the broadcast config.

Routing

Broadcast groups work alongside existing routing:

{
  "bindings": [
    {
      "match": { "channel": "whatsapp", "peer": { "kind": "group", "id": "GROUP_A" } },
      "agentId": "alfred"
    }
  ],
  "broadcast": {
    "GROUP_B": ["agent1", "agent2"]
  }
}

• GROUP_A: only alfred responds (normal routing).
• GROUP_B: agent1 AND agent2 respond (broadcast).

Troubleshooting

1. Agent IDs exist in `agents.list` (config validation rejects unknown ids).
2. Peer ID format is correct (group JID like `120363403215116621@g.us`, or E.164 like `+15551234567` for DMs).
3. The message passed normal gating (mention/activation rules still apply).

**Debug:**

```bash
openclaw logs --follow | grep -i broadcast
```

A successful fan-out logs `Broadcasting message to <n> agents (<strategy>)`.

**Fix:** add ordinary route-bound peers to the broadcast config, or remove/change the configured ACP binding if fan-out broadcast is desired.

Examples

One code snippet in the group produces four replies: formatting fixes, a security finding, a coverage gap, and a docs nit.

API reference

Config schema

interface OpenClawConfig {
  broadcast?: {
    strategy?: "parallel" | "sequential";
    [peerId: string]: string[];
  };
}

Fields

Limitations

1. Max agents: no hard limit, but many agents (10+) can be slow.
2. Shared context: agents do not see each other's responses (by design).
3. Message ordering: parallel responses may arrive in any order.
4. Rate limits: all replies come from one WhatsApp account, so every agent's reply counts toward the same WhatsApp rate limits.

Related

• Channel routing
• Groups
• Multi-agent sandbox tools
• Pairing
• Session management

Source: docs/channels/broadcast-groups.md