Multi-Channel AI: Running One Agent Across Slack, Discord, and WhatsApp

One agent. Three channels. That's the pitch. And with OpenClaw, it's not just possible — it's the default way to run things.

Most people start with one channel (usually Slack or Telegram), get comfortable, and then ask: can my agent also live in Discord? Can it respond on WhatsApp too? The answer is yes, and it's simpler than you'd expect. OpenClaw was built around the idea that your agent shouldn't be locked to a single platform.

This post covers how multi-channel routing works in OpenClaw, how to configure Slack + Discord + WhatsApp simultaneously, how to control which messages your agent sees, and how session isolation keeps contexts clean across platforms.

How OpenClaw Handles Multiple Channels

The core concept is simple: the Gateway is the router. Every incoming message — whether from Slack, Discord, or WhatsApp — hits the same Gateway process. The Gateway inspects the message's origin and routes it to the correct agent and session.

OpenClaw routes replies back to the channel the message came from. If you send a message via WhatsApp, the reply goes to WhatsApp. If you send via Discord, the reply goes to Discord. The model never decides — routing is deterministic and configured by you.

Sessions are isolated by default. A conversation in your Slack DM doesn't bleed into your WhatsApp conversation. Each channel+peer combination gets its own session bucket:

{codeBlock5}

Direct messages across all channels default to the agent's main session. So if you're the only user talking to your agent, your Slack DM and WhatsApp DM share the same brain. This is intentional — you want your agent to remember the context from earlier, regardless of which app you used.

The Basic Multi-Channel Config

Here's what a minimal config looks like with all three channels enabled:

{codeBlock1}

That's it. Once the Gateway starts with this config, your agent is live on all three channels simultaneously. The enabled: true flag activates the channel; without it, the channel block is ignored.

Slack Setup Requirements

Slack requires creating a Slack app in your workspace. You'll need:

• An App Token (xapp-...) with connections:write scope — for Socket Mode
• A Bot Token (xoxb-...) — for posting messages
• Socket Mode enabled in your Slack app settings
• Bot events subscribed: app_mention, message.channels, message.im, and others

Socket Mode is the default and recommended mode. It works behind firewalls and doesn't require a public URL. If you need HTTP webhooks instead, you can set mode: "http", but Socket Mode is easier for most setups.

Discord Setup Requirements

Discord requires a bot application in the Discord Developer Portal:

• Create an application, add a Bot, and copy the Bot Token
• Enable Message Content Intent (required) and Server Members Intent (recommended)
• Invite the bot to your server with bot and applications.commands scopes
• Grant permissions: View Channels, Send Messages, Read Message History, Embed Links

Discord DMs require pairing by default — unknown users must be approved before they can interact with your agent. This is the same safety model as other channels.

WhatsApp Setup Requirements

WhatsApp uses the Baileys library (WhatsApp Web protocol) and requires QR pairing:

openclaw channels login --channel whatsapp

This opens a QR code in your terminal. Scan it with your WhatsApp mobile app (Settings → Linked Devices). Once linked, the Gateway maintains the session. If you have a separate WhatsApp number for your agent, use it — it keeps work messages clean.

WhatsApp groups require separate allowlisting. The groupPolicy: "allowlist" and groupAllowFrom fields control which groups your agent participates in.

Access Control Per Channel

Running multiple channels means more surface area for unwanted interactions. OpenClaw gives you fine-grained control over who can talk to your agent on each channel:

{codeBlock3}

The key options for each channel:

• dmPolicy: "pairing" (requires explicit approval), "allowlist" (only listed IDs), or "open" (anyone)
• allowFrom: Array of user IDs/numbers allowed to DM. Format varies by channel (Slack user ID, Discord user ID, WhatsApp phone number with country code)
• groupPolicy: Controls group/channel behavior — "allowlist", "open", or "closed"
• groupAllowFrom: Which users can trigger the agent inside groups (WhatsApp and others)

I recommend starting with "pairing" on all channels when you first set up multi-channel. It means the first message from any new sender triggers a pairing request that you have to approve. Once you've vetted the contacts, you can switch to "allowlist" for tighter control.

Routing Different Agents to Different Channels

The examples above use a single agent across all channels. But OpenClaw also supports routing different channels (or even specific Slack workspaces or Discord servers) to different agents:

{codeBlock2}

This is useful when you want:

• A personal agent on Slack/Discord, and a customer support agent on WhatsApp
• Different workspace files and memories per channel
• Isolated SOUL.md and AGENTS.md per agent
• Different model configurations (e.g., Opus for Slack, Sonnet for WhatsApp)

The bindings array is evaluated top-to-bottom. The first match wins. Bindings can match on channel, teamId (Slack), guildId (Discord), accountId, or specific peer IDs.

If no binding matches, OpenClaw falls back to the default agent (the first agent in agents.list, or the agent flagged with default: true).

Running Multiple Agents in Parallel (Broadcast)

There's a more advanced pattern called broadcast groups, where a single message triggers multiple agents simultaneously:

{codeBlock4}

This runs both main and logger agents when a message arrives in a specific WhatsApp group. The strategy can be "parallel" (both run at the same time) or "sequential" (one after the other).

Practical use cases: a primary agent that responds + a logging agent that silently records conversations. Or a support agent + a monitoring agent that flags unusual requests.

Shared Context Across Channels

One of the more powerful aspects of multi-channel setup is that your agent's memory files are shared across channels by default. Your MEMORY.md, USER.md, and workspace files are the same regardless of which channel a message comes from.

So if you tell your agent on Slack "I'm going on holiday next week, hold non-urgent tasks," that context is in the workspace. When you send a WhatsApp message the next day, the agent knows.

This is different from session state (conversation history), which is isolated per channel. Memory files are the persistent layer that spans channels. Session transcripts are per-session.

The distinction matters: your agent won't "remember" the specific conversation you had on Discord when you open Slack. But it will remember anything that was written to a memory file during that conversation.

Practical Tips for Multi-Channel Setups

Use different channels for different modes

I run Slack for day-to-day team operations (with threads, channel context, cron jobs), Discord for community/external interactions, and WhatsApp for quick personal messages when I'm on mobile. Each channel has a natural use case — lean into it.

Start with one channel, expand gradually

It's tempting to configure everything at once. Don't. Get one channel working perfectly — right access controls, right agent behavior, right memory setup. Then add the next. Debugging multi-channel issues is easier when you know each channel works independently first.

Verify with openclaw status

After starting the Gateway with multiple channels, run:

openclaw gateway status

It shows which channels are connected, which accounts are active, and any connection errors. If a channel isn't connecting, the status output usually tells you why (bad token, missing permissions, etc.).

WhatsApp session persistence

WhatsApp sessions are stored on disk under ~/.openclaw. If you restart the Gateway, the session re-authenticates automatically — you don't need to re-scan the QR code every time. But if the session expires (WhatsApp enforces its own timeout rules), you'll need to re-pair. This is a WhatsApp limitation, not an OpenClaw one.

Discord thread sessions

Discord threads get their own session key (:thread:<threadId> appended). This means a thread conversation is isolated from the channel conversation. Useful for focused, multi-turn conversations that don't pollute the main channel context.

Putting It Together

Multi-channel isn't just a configuration option — it's a fundamentally different way to operate an AI agent. Instead of opening a chat app, navigating to your bot, and talking to it, your agent is just there — in whatever app you're already using.

The workflow becomes natural: slack message for work stuff, WhatsApp for quick personal queries, Discord for community context. Same agent, same memory, same capabilities — just wherever you are.

The configuration overhead is surprisingly low. One Gateway process. One config file. Three channels blocks. That's the whole setup.

Where it gets interesting is when you start adding routing rules, binding specific agents to specific channels, and building workflows that span channels (like an agent that receives a task on WhatsApp and posts the result to a Slack channel). That's where OpenClaw's architecture really shines — but that's a post for another night.

Want the complete guide? Get The OpenClaw Playbook — $9.99 for the full OpenClaw setup playbook, channel configs, and agent workspace templates.