One Gateway, Every Chat Platform — How OpenClaw Unifies Messaging

If you've ever built a chatbot, you know the pattern: pick a platform, read its API docs, write an integration, deploy it. Then your team asks for the same bot on another platform. So you write another integration. Then another.

Before long, you have three separate bot deployments, three sets of credentials, three slightly different codebases handling the same logic with platform-specific quirks. The bot on Telegram can do things the Slack bot can't. The Discord version has bugs the WhatsApp version doesn't. Updates require deploying to multiple services.

This is the multi-channel problem, and it's surprisingly hard to solve cleanly.

The Naive Approach Doesn't Scale

The most common solution is an abstraction layer: define a universal message format, write adapters for each platform, and route everything through a common handler.

In theory, this works. In practice, you quickly run into the edges.

WhatsApp identifies users by phone numbers. Telegram uses numeric IDs. Discord uses snowflake IDs with guild and channel hierarchies. Slack uses workspace-scoped member IDs. Each platform has different concepts of groups, threads, reactions, message editing, read receipts, typing indicators, and media support.

A thin abstraction layer either:

• Reduces everything to the lowest common denominator (text in, text out), losing platform-specific features
• Becomes a thick abstraction that's as complex as the platforms themselves

OpenClaw takes a third approach that I think is more interesting.

Channel-Aware, Not Channel-Agnostic

OpenClaw doesn't try to abstract away the differences between platforms. Instead, it lets the agent know which platform a message came from and adjusts behavior accordingly.

When a message arrives from Telegram, the Gateway knows it's Telegram. It knows the user's numeric ID, whether the message came from a group or DM, whether the bot was @mentioned, and whether the group has Privacy Mode enabled. When the agent replies, the Gateway knows that Telegram supports message editing (for streaming responses), custom command menus, and forum topics.

When a message arrives from WhatsApp, different rules apply. Users are identified by phone numbers. Streaming isn't supported — the response arrives as a complete message. But read receipts work, emoji reactions can acknowledge receipt, and media handling follows WhatsApp's specific format.

The agent logic in the middle is shared. The routing is deterministic — replies go back to the channel they came from. But the Gateway handles platform-specific behavior at the edges.

This is the right level of abstraction. The agent doesn't need to know the API differences between Telegram and WhatsApp. But the system does need to handle them.

22 Platforms, One Process

The current count is 22 supported platforms:

Built-in: WhatsApp, Telegram, Discord, Signal, iMessage (via BlueBubbles), Google Chat, WebChat

Via plugins: Slack, Microsoft Teams, Mattermost, Matrix, IRC, LINE, Lark/Feishu, Nextcloud Talk, Nostr, Twitch, and more

All of them connect to the same Gateway process. You can run WhatsApp, Telegram, and Discord simultaneously — messages from each platform route to their own sessions, managed by the same agent.

The engineering challenge here isn't just "make 22 adapters work." It's managing the stateful connections that each platform requires. WhatsApp needs a persistent session with local state (the Baileys library maintains a session directory). Telegram needs a long-polling connection or webhook endpoint. Discord needs a WebSocket connection to Discord's Gateway. Slack can use either Socket Mode or HTTP Events.

Each platform has its own reconnection logic, rate limiting, and failure modes. The Gateway manages all of this in a single process, which is both its strength (operational simplicity) and its constraint (single point of failure).

The Pairing Problem

Here's a question that doesn't get enough attention in multi-channel architectures: who is allowed to talk to your agent?

When you deploy a public-facing Slack bot, the answer is usually "anyone in the workspace." When you deploy a personal WhatsApp assistant, the answer should be "only me."

OpenClaw solves this with a pairing system that works across all channels. When an unknown user messages your bot, they receive a pairing code — an 8-character alphanumeric string. You approve or reject the request from the CLI or Dashboard. Until approved, the agent doesn't respond.

What makes this interesting is that the pairing system is channel-specific. Being approved on Telegram doesn't automatically grant access on WhatsApp. Group access is separate from DM access. Each security boundary is independently configurable.

For multi-user setups, there's an additional layer: DM scope isolation. By default, all DMs share one session — which means Alice's messages are in the same context as Bob's. Switching to per-channel-peer scope gives each user their own isolated session, even though they're all messaging the same bot number.

These are the kinds of details that matter when you're connecting real humans to AI agents through real chat platforms.

Group Messages: Three Layers of Filtering

Group behavior is where most multi-channel bots get wrong because the expectations vary so much across platforms.

OpenClaw uses three-layer filtering:

1. Group policy: Is the group allowed at all? (open, allowlist, disabled)
2. Sender policy: Is this sender allowed to trigger the bot in this group?
3. Mention filter: Does the message @mention the bot?

The mention filter has a nuance that I find well-designed: even when a message is filtered out because it doesn't mention the bot, OpenClaw still stores it as context. Next time someone does @mention the bot, the previous messages are injected as background — so the agent understands what the group has been discussing.

This means the bot can answer "what have people been saying about the release?" even though it didn't respond to any of those earlier messages.

Cross-Channel Identity

Here's a problem unique to multi-channel systems: the same person messages you on Telegram and WhatsApp. To the Gateway, these look like different users. But you might want them to share a session — same memory, same context, same conversation thread.

OpenClaw handles this with identity links:

{
  session: {
    identityLinks: {
      alice: ["telegram:123456789", "whatsapp:[phone]"],
    },
  },
}

Now messages from Alice on either platform feed into the same session. The agent remembers the Telegram conversation when Alice messages on WhatsApp.

This is a small feature with outsized impact. It's the difference between the agent feeling like a unified assistant and feeling like it has amnesia every time you switch platforms.

What Unification Actually Means

The promise of "one gateway for all platforms" is easy to state but hard to deliver. The real work isn't in the message routing — it's in correctly handling the behavioral differences between platforms while presenting a consistent experience to the user.

OpenClaw's approach — channel-aware routing with platform-specific edge handling — is the pragmatic middle ground between full abstraction and platform-specific silos. It doesn't pretend WhatsApp and Telegram are the same thing. It just makes them work together.

For anyone building multi-channel AI infrastructure, the lesson is this: don't abstract away the differences. Acknowledge them at the edges. Keep the core logic shared. And invest heavily in the details that make each platform feel native.

---

Full documentation: OpenClaw Docs

GitHub: openclaw/openclaw

---

This is Part 3 of a series on AI agent infrastructure. Follow for more.