OpenClaw Channel Routing: Keep One Agent Smart Across Every App

A lot of multi-channel AI setups feel clever right up until the reply lands in the wrong app, the wrong thread, or the wrong agent brain. That is the real routing problem. It is not about whether your model is smart enough. It is about whether your control plane is boring and deterministic enough to keep sessions, accounts, and agents separated.

OpenClaw is opinionated here in a way I like. The model does not choose where to answer. Routing is deterministic, controlled by host configuration, and based on channel, account, peer, and binding rules. That gives you something most AI stacks quietly lack, which is confidence that one agent can stay coherent across several apps without turning into a context leak.

This post is about how that routing layer actually works, what group and mention rules do on top of it, and how multi-agent bindings keep one Gateway from becoming one giant shared brain.

The first rule: replies go back to the channel they came from

The routing docs state this plainly: OpenClaw routes replies back to the channel where a message came from. The model is not making that decision. The host configuration is.

That sounds small, but it is the foundation of sane operations. If a message came from Slack, the reply goes back to Slack. If it came from Telegram, it goes back to Telegram. If it came from a Slack or Discord thread, that thread identity is part of the session key. Routing stays attached to the origin instead of drifting based on whatever the model decides sounds helpful in the moment.

The docs also define the pieces involved:

• Channel, like slack, telegram, whatsapp, discord, or signal
• AccountId, when a channel has multiple account instances
• AgentId, which is the isolated workspace and session store, basically one brain
• SessionKey, which controls where context is stored and how concurrency is isolated

If you are trying to keep one operator smart across every app, these are the levers that matter. Not prompt tricks.

Session keys are what stop channels from smearing together

OpenClaw does not dump every conversation into one history bucket. Direct messages can collapse to the agent's main session, but groups, channels, and threads stay isolated.

The routing docs show the shapes clearly:

• main direct session: agent:<agentId>:<mainKey>
• groups: agent:<agentId>:<channel>:group:<id>
• channels or rooms: agent:<agentId>:<channel>:channel:<id>
• Slack and Discord threads append :thread:<threadId>
• Telegram forum topics embed :topic:<topicId> in the group key

That means your Slack DM with an agent, a public Discord channel, and a Telegram topic do not silently share transcript context. They can still belong to the same agent, but the session buckets remain separate. That is exactly what you want if one agent is spanning daily chats, group operations, and support threads at the same time.

There is also a subtle protection around direct messages when session.dmScope is main. The docs note that OpenClaw can pin the owner route from allowFrom so a random non-owner DM does not overwrite the main session's lastRoute. I am glad this exists. Shared DM funnels get messy fast otherwise.

Bindings decide which agent owns the message

Routing is not just about the destination channel. It is also about which agent gets the work. OpenClaw resolves that through bindings, and the matching order is deterministic.

According to the docs, routing checks these tiers in order:

1. exact peer match
2. parent peer match for thread inheritance
3. Discord guild plus roles
4. Discord guild
5. Slack team
6. account match on the channel
7. channel match across any account
8. default agent fallback

If a binding includes multiple match fields, all provided fields have to match. That is important. It means routing is not fuzzy. It is not "close enough." It is explicit.

{
  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" },
  ],
}

For a solo setup, you may only need one default agent. But once you run separate operators for support, coding, or alerts, bindings become the difference between isolation and accidental crossover.

Groups are allowed separately from DMs, and that is the right call

The group docs make a distinction I wish more systems would make. DM access is not the same thing as group access.

In OpenClaw, group handling is controlled by groupPolicy plus group allowlists and sender allowlists. The default behavior is restricted:

• groupPolicy: "allowlist" means only configured groups or rooms are allowed
• groupPolicy: "disabled" blocks all group messages
• groupPolicy: "open" bypasses allowlists, though mention gating can still apply

The docs also spell out the group flow in a way that is refreshingly direct: policy first, then allowlists, then mention gating. If any of those layers say no, the message is either dropped or kept for context only.

{
  channels: {
    whatsapp: {
      groups: {
        "*": { requireMention: true },
        "123@g.us": { requireMention: false },
      },
    },
    slack: {
      groupPolicy: "allowlist",
      channels: { "#general": { allow: true } },
    },
  },
}

This separation is how one agent can be perfectly fine in your personal DM while still behaving conservatively in public groups. I would not trust a cross-app operator if it treated those surfaces the same.

Mention gating is what keeps public groups from turning noisy

By default, OpenClaw expects a mention in groups unless you override that behavior. The docs say replying to a bot message can count as an implicit mention on channels that support reply metadata, including Telegram, WhatsApp, Slack, Discord, and Microsoft Teams.

You can set default behavior under group configs, and you can also define per-agent mentionPatterns as case-insensitive safe regex patterns. That matters when several agents share the same group or when native mention detection is inconsistent.

The clean mental model is this:

• Policy decides whether the group is even eligible
• Allowlists decide who and which room is trusted
• Mentions decide whether the message should trigger a reply right now

If you want one agent to live across several apps without becoming a noisy group participant, mention gating is not optional. It is the brake pedal.

One agent across many apps is fine, but one brain is not the same as one session

The docs explicitly say that WebChat attaches to the selected agent and defaults to that agent's main session, which lets you see cross-channel context for that agent in one place. That is useful, but it does not mean all channels are sharing one transcript. The session-key rules still apply.

This is the part I think operators should remember: a single agent can have a shared workspace, shared memory files, and shared identity while still maintaining separate session buckets per group, channel, and thread. That is a good design. It keeps the brain coherent without flattening every conversation into one unreadable log.

If you need stricter separation, the multi-agent docs go further. Each agent gets its own workspace, its own auth profiles, its own session store, and its own state directory. The docs are blunt about not reusing agentDir across agents because it causes auth and session collisions.

Multiple accounts let one Gateway host multiple identities cleanly

Multi-agent routing is not just about persona separation. It also covers multiple account instances on the same channel. The docs list many channels that support this pattern, including WhatsApp, Telegram, Discord, Slack, Signal, iMessage, and more.

That gives you a practical setup like this:

{
  agents: {
    list: [
      { id: "main", workspace: "~/.openclaw/workspace-main" },
      { id: "alerts", workspace: "~/.openclaw/workspace-alerts" },
    ],
  },
  bindings: [
    { agentId: "main", match: { channel: "telegram", accountId: "default" } },
    { agentId: "alerts", match: { channel: "telegram", accountId: "alerts" } },
  ],
  channels: {
    telegram: {
      accounts: {
        default: {
          botToken: "123456:ABC...",
          dmPolicy: "pairing",
        },
        alerts: {
          botToken: "987654:XYZ...",
          dmPolicy: "allowlist",
          allowFrom: ["tg:123456789"],
        },
      },
    },
  },
}

Here the same channel family, Telegram in this case, can route different account IDs to different agents. The message origin stays deterministic, and each agent remains isolated. You do not have to run separate Gateway processes just to keep an alerts bot from sharing sessions with a main assistant.

The docs also mention an important detail: if a binding omits accountId, it matches the default account only. If you want a channel-wide fallback across all accounts, use accountId: "*". Small config detail, big difference in behavior.

Broadcast groups are the exception, not the default

Most of the time, routing picks one agent. OpenClaw does have broadcast groups, but the docs frame them very specifically: they let you run multiple agents for the same peer when OpenClaw would normally reply.

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

I would treat this as an advanced pattern, not the baseline. If every incoming message fans out to multiple agents by default, your operator stack is probably compensating for unclear ownership. Broadcast groups are useful for parallel agents like support plus logging, but they work best when used intentionally.

The safe way to think about multi-app routing

If you want one agent smart across every app, I would use these rules:

• Keep one agent only when shared persona, files, and memory are actually desirable.
• Let session keys isolate DMs, groups, channels, and threads automatically.
• Use allowlists and mention gating so public surfaces do not become accidental hot mics.
• Use separate agents when auth, workspace, or trust boundaries should not mix.
• Use account-specific bindings instead of hoping the model will infer the right identity.

That is the whole game. Deterministic routing, explicit isolation, and just enough shared context to stay useful.

Bottom line

OpenClaw channel routing works because it is not magical. Replies go back to the source channel. Bindings choose the agent. Session keys separate contexts. Group policy and mention gating keep public spaces controlled. Multi-agent isolation keeps separate workspaces and auth from colliding.

That is how one Gateway can stay coherent across Slack, Telegram, WhatsApp, Discord, and more without turning one smart agent into one confused one.

Want the complete guide? Get ClawKit — $9.99