OpenClaw broadcast groups

One message, several specialists: a reviewer, a writer, a security auditor, each answering from its own angle. OpenClaw’s agent group threads run multiple agents on the same inbound message from a top-level broadcast config, each in its own session, and channel-qualified entries can select participants by mention and allow a bounded number of follow-up rounds so agents build on sibling replies. The feature is marked experimental and the legacy WhatsApp arrays remain supported. Here are the configuration forms and caps, selection and rounds, isolation, strategies, the flow, the guidance, and the limits.

Configuration

• A qualified key has the form channel colon peer id, such as a Discord channel, a Slack channel, a Telegram group or a WhatsApp group JID, and its value is an agent id array or a strict object with the agents, mention gating on by default, a rounds count from one to four including the initial round, and a turns count from one to thirty-two; unknown fields are rejected, at most sixteen participants are allowed, a qualified WhatsApp key beats an unqualified one, and unqualified object entries are not supported.
• The ordinary channel route still needs an agent, so a binding selects one for admission before group dispatch; in the docs’ example a reviewer and a writer with distinct mention patterns answer a mentioned draft, and mentioning only the writer selects only the writer for the first round.
• The turns budget counts agent runs started by the coordinator, including runs that pass or fail, with slots reserved synchronously before parallel launch so parallel participants cannot overspend; when the budget is smaller than the eligible count, configured order decides who runs, and a turn can produce several platform messages that the budget does not count or cap. Telegram, Discord and Slack disable shared preview and progress drafts for qualified threads so concurrent participants do not overwrite each other.
• The legacy single-pass form uses unqualified WhatsApp peer ids, a group JID or a sender phone number, mapped to agent arrays: every listed agent processes one turn with no follow-up rounds or selection. Every listed id must exist in the roster, validation rejects unknown ids, deleting an agent prunes it, and the canonical entries roster is used whenever present.

Group threads do not bypass channel allowlists, command authorization, or exclusive ACP bindings.

Selection and rounds

Selection uses only explicit at-style matches in the current inbound text, computed once for the participant set; a name in prose or a bare emoji selects nobody. Mention patterns resolve from the agent’s group-chat patterns, then the global group-chat patterns, then identity-derived ones, so participants need distinct patterns to be addressed separately. With gating on, matches select only the matching participants for round one and no match selects all; with gating off, all are selected, and neither setting turns off the channel’s mention requirement, sender allowlists or command authorisation. After a completed round, another can run only within both the rounds and turns limits; eligible participants are those that produced a final reply in the previous round or were addressed by name in a sibling’s final, each receives an attributed digest of sibling finals bounded to four thousand characters per participant and sixteen thousand combined, with an instruction to reply only when adding something new and otherwise return the silent token, and passing produces no visible reply. Everyone passing ends the thread, as does either limit or cancellation; continuations carry their own identities rather than replaying the inbound message, and the sequential strategy only changes launch order within a round, not into a pipeline. Budget state is in memory, scoped to the channel, account, conversation, thread and root message, and a Gateway restart loses it. When a qualified entry configures more than one participant, Discord, Slack and Telegram replies begin with the participant name in bold, even if only one responds; WhatsApp presentation is unchanged.

Flow, isolation, strategy

• The flow: a message arrives, channel allowlists, activation rules and configured ACP binding ownership are applied, and if no ACP binding owns the route OpenClaw checks the qualified key, then the legacy WhatsApp key; if broadcast applies, selected participants process the message within the limits, each with its own session key and isolated context, in parallel by default or sequentially, and WhatsApp audio is transcribed once before fan-out so agents share one transcript.
• Each agent keeps separate session keys, conversation history shared only through the bounded digests, workspace and sandbox, tool access and memory files, so a read-only reviewer can sit beside a read-write fixer; on Discord, Slack and Telegram, delivery and completion hooks use the responding participant’s session and media roots. On WhatsApp one input is shared on purpose, the recent group context buffer per peer, cleared once after the fan-out completes.
• Strategy is parallel by default, with replies arriving in any order, or sequential, with agents processing in array order each waiting for the previous; the docs’ use cases are specialist dev teams, multi-language support agents, a support agent shadowed by a QA agent that answers only when it finds issues, and several agents consuming one status update.

OpenClaw channel routing is the ordinary routing that still provides the conversation route, and OpenClaw bot loop protection the coordinator budget and pair guard that keep the rounds finite.

Guidance and limits

Keep agents focused on one responsibility, use descriptive ids and names, give them different tool access, prefer parallel with a handful of agents on lighter models, and remember failures stay isolated, one agent’s error is logged without blocking the others. Broadcast takes priority over ordinary route bindings, while configured ACP bindings are exclusive and dispatch to the ACP session instead. Agents not responding means checking roster ids, the qualified key and normal gating, with a fan-out log line as the success signal; only one responding means mentions, the turns budget, passing, or an exclusive binding. The limits: digests hold bounded finals rather than full sessions, parallel replies arrive unordered, participants share the account’s transport limits, budget state cannot survive a restart, and the Control UI has no dedicated team-thread session yet. OpenClaw on WhatsApp is the channel with the legacy single-pass form, and OpenClaw sandboxing explained the isolation each participant can run under.

On Diali

On Diali each instance runs one assistant, so a broadcast group means several Diali assistants configured on the same room, each with its own workspace and plan; a single assistant answering from several angles is a prompt, not a broadcast. Hosted OpenClaw on Diali is the assistant and Diali pricing what each one costs.

• Qualified key, up to sixteen agents, four rounds, thirty-two turns.
• Mentions select; digests feed follow-ups; passing is silent.
• Isolated sessions; budgets die with a restart.