OpenClaw's Slack allowBotsFrom Is a Small Config Key With a Big Multi-Agent Governance Point

Multi-agent collaboration has a funny way of starting as a demo and ending as an access-control problem. Put four agents in Slack, give them names, let them post into the same channels, and the surface looks like teamwork. Underneath, the transport is deciding which messages exist, which bots are allowed to trigger replies, and whether one agent can accidentally make another spend tokens forever. PR #90329 is small, but it points at the layer every serious multi-agent platform needs: explicit trust edges between agents.

The new OpenClaw Slack option is allowBotsFrom. It lets operators specify trusted Slack bot IDs that may trigger replies even when global allowBots remains false. The immediate use case comes from issue #89043, where multi-agent OpenClaw deployments need separate Slack app tokens to hear each other without opening the workspace to every bot message. The behavior is intentionally narrow: allowBots: true still allows all bots; allowBots: false plus a matching bot_id in allowBotsFrom allows only that trusted bot; unknown bots remain dropped.

That narrowness is the feature. The lazy fix would be to tell users to enable bot messages globally and trust prompts, routing rules, or human patience to clean up the mess. That is how workspaces become bot soup. A trusted-bot allowlist is a better primitive because it recognizes that agent-to-agent communication is not a vibe. It is an identity relationship with consequences.

Slack makes write-path identity look easier than read-path delivery

Issue #89043 documents the transport wrinkle that makes this more than a config nicety. A user running four agents on one gateway with one Slack app can post with per-agent identity using chat:write.customize. From the channel, that looks like separate agents speaking. But Slack Socket Mode does not redeliver an app's own posts back to that same app. Same-app internal echo produces zero inbound events. Posts from a different app bot, however, are delivered and can be routed. So cross-app trusted-bot collaboration can be solved with an allowlist. Same-app self-delivery needs a separate gateway-level mechanism because Slack will not provide the event.

This is exactly the kind of platform-specific mismatch agent frameworks have to expose honestly. The human-visible channel is not the runtime event stream. Display names are not delivery semantics. Write-path customization is not read-path observability. If users build coordination protocols on the assumption that "the message is in Slack, therefore every agent saw it," they will get intermittent coordination failures that look like model flakiness and are actually transport behavior.

PR #90329 adds allowBotsFrom?: string[] at Slack top-level, account-level, and channel-level config. The lists merge additively, so operators can set broad trusted partners or narrower per-channel policy. The file surface is modest: Slack config types, Zod provider schema, schema help, the Slack prepare handler, and 74 test lines. The example is unsurprising and useful: "allowBots": false with "allowBotsFrom": ["B012PARTNER"].

The governance point is larger than Slack. Multi-agent systems need answers to questions most single-agent demos never ask. Which agents may trigger which other agents? Which channels permit cross-agent replies? Is a synthetic event distinguishable from a platform-delivered event? Can one bot cause another to enter an unbounded reply loop? Are token budgets enforced per agent, per channel, or per coordination graph? Can a compromised partner bot socially route commands through a more privileged agent? If those answers live only in prompts, the system is not governed. It is hoping.

The partial nature of this PR is also healthy. Cross-app partner bots and same-app internal echo are different problems. The former is a platform-delivered event from a known external bot ID. The latter would be a synthetic event generated inside the gateway because Slack never sends it. Those mechanisms should not be collapsed into one flag. If OpenClaw later distributes same-app outbound posts internally as room events, that path needs provenance fields: source agent, original Slack channel, posted timestamp, Slack message ID if available, synthetic-event marker, delivery scope, and loop-prevention metadata. Otherwise internal echo becomes a hidden message bus with chat-shaped vibes.

Paperclip surfaced in the same research window as context rather than a selected source, and its existence is a useful market signal. Products are starting to treat OpenClaw bots, Claude Code sessions, scripts, and webhooks as manageable workers with budgets and governance. That tells you where the category is going. The problem is no longer "can I make an agent post in Slack?" The problem is "can I operate many agents without turning Slack into a recursive automation bill?"

For practitioners deploying OpenClaw in Slack, the immediate recommendation is to keep allowBots false by default and use allowBotsFrom only for known partner bot IDs. Scope it at the channel level where possible. Monitor for loops. Give agents explicit budget and reply-depth limits. Treat any bridge that converts outbound posts into inbound events as a privileged component, not a convenience feature. And document the distinction between cross-app bot events and same-app synthetic delivery so future operators do not assume Slack will behave like a generic pub/sub bus.

For framework builders, the lesson is transport-aware governance. Multi-agent orchestration cannot be implemented solely in the model layer because the chat platform determines what messages exist. Slack, Discord, Teams, Telegram, and email all have different bot identity and delivery semantics. A serious agent runtime needs those semantics represented in policy, telemetry, and loop prevention, not buried in adapter code.

allowBotsFrom is a small config key. The idea behind it is not small at all: least privilege for agent-to-agent chat. Multi-agent collaboration should mean explicit trust edges, platform-aware delivery, and cost controls before the agents start performing teamwork at your expense.

Sources: OpenClaw PR #90329, OpenClaw issue #89043, Paperclip