ZeroClaw separates hearing a group from answering it

Mention-only agents often lack the conversation that made a mention meaningful. The Telegram proposal preserves a deliberate middle state: the bot can record authorized room text without reacting, invoking a model or using tools. When addressed later, it has context. That is different from simply switching off the mention gate and letting every group message trigger work.

Slack has the inverse problem. Workflow Builder and application posts arrive as bot_message without a normal user field, so two existing checks reject them before an addressed request can run. The opt-in proposal admits that subtype and resolves the posting bot’s identity through the peer allowlist. It applies across Socket Mode, polling and thread replies, while leaving historical context hydration as a separate decision. A workflow being allowed to wake the agent does not mean all bot history becomes model input.

The facts

- PR #10640 proposes Telegram passive_group_context with a false default. - Authorized unaddressed group text becomes reply-target-scoped history without an agent turn; unaddressed media remains excluded. - The implementation reuses passive-context fields from the earlier WhatsApp Web proposal #8389. - PR #10622 proposes Slack allow_bot_messages, also off by default, using bot_id for the peer allowlist when a bot message has no user field. - Slack self-echo is rejected using the application’s own bot identity, and bot admission does not add historical bot-message hydration.

Why it matters

Multi-bot rooms need more than a binary ‘respond to everything’ switch. Hearing, storing and acting have different privacy and cost consequences. The WhatsApp groundwork returns from passive processing before reactions, media handling, tools and cancellation bookkeeping; Telegram extends that design to text. Slack bot admission narrows the authorized sender list rather than treating automation as a trusted class. These are useful distinctions for teams mixing people, scheduled notifications and several agents.

Current

Inspected on 2026-09-06. The ZeroClaw stable-release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is zeroclaw-labs/zeroclaw PR #10640 (https://github.com/zeroclaw-labs/zeroclaw/pull/10640). Supporting context comes from zeroclaw-labs/zeroclaw PR #10622 (https://github.com/zeroclaw-labs/zeroclaw/pull/10622); zeroclaw-labs/zeroclaw PR #8389 (earlier design context) (https://github.com/zeroclaw-labs/zeroclaw/pull/8389). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Review a group’s retention expectations before enabling passive history. Test an allowed unaddressed text, an unaddressed attachment, a denied sender and a later explicit mention as separate cases. For Slack, allow named bot identities and prove the agent’s own echoes cannot retrigger it. Validation must compile the channel actually changed: the Slack source explicitly warns that the default channel feature set does not build slack.rs, so a generic green test run can miss the entire implementation.

Caveat

The Telegram and Slack records were open at inspection; the WhatsApp record is earlier design context. No default behavior changes are promised. Group text retention can still expose information across permitted participants even when it spends no model tokens.