How OpenClaw Handles Channels and Routing

I have spent way too much time in the past trying to figure out why a bot replied in the wrong thread or used the wrong “personality” for a specific group. It is frustrating when you have to write custom logic for every single chat platform just to keep conversations organized.

OpenClaw fixes this by making routing deterministic. Instead of letting the AI model guess where to send a reply, the host configuration controls everything. I like this approach because it means your bot won’t suddenly start talking to your boss with the settings you meant for a gaming channel.

What You’ll Need

• An OpenClaw installation with a configured state directory (default is ~/.openclaw).
• The ID of the channel you want to connect (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, or WebChat).
• Specific identifiers like peer.id, guildId, or teamId for the routing rules.

Quick Start

The fastest way to get your agent talking on a specific channel is to use the bindings configuration. This tells OpenClaw exactly which inbound messages belong to which agent.

Here is a basic setup that maps a Slack team and a Telegram group to a single “support” agent:

{
  agents: {
    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],
  },
  bindings: [
    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },
    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },
  ],
}

Once this is set, OpenClaw follows a strict hierarchy to choose the agent:

1. Exact peer match: Checks peer.kind and peer.id.
2. Guild match: Uses guildId for Discord.
3. Team match: Uses teamId for Slack.
4. Account match: Based on the accountId on the channel.
5. Channel match: Any account on that specific channel.
6. Default agent: Uses the agent marked as default, the first entry in the list, or the “main” agent.

Session Keys and Storage

OpenClaw keeps conversations isolated using session keys. If you send a direct message, it usually goes to the agent’s main session. If you are in a group or a specific thread, the session key becomes more specific.

I find these examples helpful for understanding how the “brain” stays organized:

• Telegram Topic: agent:main:telegram:group:-1001234567890:topic:42
• Discord Thread: agent:main:discord:channel:123456:thread:987654

All these sessions are saved as JSON files in your state directory, specifically under ~/.openclaw/agents/<agentId>/sessions/sessions.json. You can also find JSONL transcripts right next to them if you need to review the raw history.

Running Multiple Agents (Broadcast)

Sometimes you want more than one agent to see the same message. This is where broadcast groups come in. You can set a parallel strategy so that multiple agents reply to the same peer.

{
  broadcast: {
    strategy: "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}

Troubleshooting

The agent is using the wrong session context Check your session key shape. If you are in a Slack or Discord thread, OpenClaw appends :thread:<threadId> to the base key. If the keys don’t match, the agent won’t see the previous messages.

Messages aren’t routing to the correct agent Review the routing rules hierarchy. If you have a general “Channel match” but expect a “Peer match” to take over, ensure the peer.id in your bindings is exactly correct. OpenClaw picks the first match it finds based on the priority list.

WebChat isn’t showing cross-channel history WebChat attaches to the selected agent’s main session. It only displays context for that specific agent. If you are using different agents for different channels, you won’t see those conversations in one WebChat view.

If you hit a wall while setting up your routes, try the AI Setup Assistant.

What’s Next

• Broadcast Groups