OpenClaw for messaging: a closer look at WhatsApp and Telegram

OpenClaw has been going viral in the agentic AI community. It’s an open-source toolkit for building AI agents: pick a model, give the agent some tools and a goal, and OpenClaw runs it. Unlike a plain chatbot, OpenClaw agents remember across sessions, plug into mainstream services (email, calendar, files, plus a community library of integrations), and act proactively – kicking off scheduled tasks and reminders without being prompted.

The feature that caught our attention is its channel support out of the box, OpenClaw agents can talk to people on WhatsApp, Telegram, Signal, iMessage, Discord, Slack, and more than fifteen other channels. For any product team thinking about agentic UX, that’s a big deal – messaging is where users actually are.

So we put it to the test, with three questions in mind:

1. Is it easy to set up?
2. Could a product team realistically build their user-facing communications on top of it?
3. Does the value justify the cost in tokens, infrastructure, and maintenance?

We deployed an OpenClaw instance and pointed it at two channels: Telegram and WhatsApp. Here’s what we found.

Setup: genuinely easy

Installation is a single command followed by a short guided setup. We were chatting with our deployment from a phone within minutes.

We routed traffic across three Gemini 3.1 tiers based on task complexity – Pro Preview for multi-step reasoning, Flash Preview for summaries and intent classification, and Flash Lite Preview for trivial replies and heartbeats. Done well, this kind of routing materially cuts cost and latency.

So far, so good. The interesting parts started when we looked closer at the channels themselves.

Finding 1: “20+ channels” is really two very different lists

OpenClaw’s channel list looks uniform in the docs, but the integrations split into two tiers that behave nothing alike in production:

• Tier 1 – Official APIs (sanctioned). Telegram (Bot API), Discord, Slack, Microsoft Teams. You register an app, get a token, and operate within documented rate limits. Fully compliant with the platform’s terms.
• Tier 2 – Reverse-engineered protocols (unsanctioned). WhatsApp via Baileys, iMessage via undocumented Apple APIs. These libraries reconstruct the platform’s wire protocol from the outside. To the platform, the traffic is indistinguishable from a modified, unofficial client.

We deliberately tested one of each.

Telegram (sanctioned): boring in the best way

Pairing was a five-minute conversation with @BotFather: pick a name, get a token, hand it to OpenClaw. No QR code, no reverse-engineering, no ban risk.

In use, the bot worked exactly as advertised – with one important constraint baked into the platform itself: Telegram bots cannot send cold messages. A user has to message the bot first. Reactive workflows (Q&A, commands, group bots) work great. Proactive ones (outbound reminders, re-engagement, anything not opted into) are blocked by design.

WhatsApp (unsanctioned): technically clean, policy-risky

Pairing was equally fast: scan a QR code with your phone, exactly like linking WhatsApp Web. Once paired, the agent operates as your number – it can read every message in the inbox and send to anyone. To recipients, it’s indistinguishable from you.

The integration itself is solid. The problem isn’t engineering, it’s policy: Baileys is not sanctioned by Meta. WhatsApp’s terms explicitly prohibit automated use through unofficial clients, and accounts using libraries like this can be – and are – banned. Fine for a personal experiment. Not fine as the long-term backbone of a product.

So of the two channels we tested, one is safe but limited to inbound, and the other is unrestricted but built on a foundation Meta could pull at any moment. That’s a meaningful gotcha for anyone planning to ship on top of OpenClaw.

Finding 2: the cost is staggering – and it’s structural

Just bringing the agent up and pairing the two channels consumed ~19M tokens across 373 messages. That’s the cost of standing OpenClaw up, before doing anything useful with it.

Tokens are how LLMs charge: every word, punctuation mark, and piece of context sent to the model is metered, on both the input and the output side.

For context, most agent conversations cost a few hundred to a few thousand tokens per turn (Iternal.ai, 2026; Redis, 2026). Even on the high end, 19M tokens is the budget for thousands of real user conversations – and we burned it on setup.

Why so much? OpenClaw loads its full bundle of skills, channel adapters, and orchestration rules into the model’s context on every single call – even calls that don’t need any of it. Every message ends up dragging the entire framework behind it, and the cost compounds as conversations grow.

If messaging is a core part of your agentic workflow, running OpenClaw out of the box will very quickly run up the bill. The good news: it’s open source, so a dev team can strip the bundle down to just the skills and adapters a given workflow actually needs. The bad news: that’s real engineering work, not a config flag.

What we’re watching next

A handful of OpenClaw-inspired spin-offs have appeared over the last few months, addressing the efficiency and security issues that come with running OpenClaw out of the box: ZeroClaw, PicoClaw, NullClaw, NanoBot, TinyClaw, and NanoClaw. Smart move by these teams – we plan to put them through the same tests we ran here and follow up in a future post.

Bottom line

OpenClaw delivers on the easy parts of its messaging promise. Setup is fast, the abstractions are clean, and once paired, the agent behaves well on both Telegram and WhatsApp.

But the headline “20+ channels” hides a split between sanctioned and unsanctioned integrations that materially changes what you can build, and the default token economics make production use prohibitively expensive without customisation.

For a hackathon or an internal tool, OpenClaw is great. For a product team planning to make messaging a long-term pillar of their UX, it’s a strong starting point – not a finished platform.