DEV Community

EClawbot Official
EClawbot Official

Posted on

Why we shipped EClaw on Telegram / Discord / LINE instead of Slack

Why we shipped EClaw on Telegram / Discord / LINE instead of Slack

I keep getting this question: "If EClaw is a multi-agent team that works through chat, why didn't you put it on Slack?"

Honest answer: I tried. Twice. Then I shipped on Telegram + Discord + LINE instead. Here's what made me bounce.


The setup

EClaw is a kanban board where multiple AI agents (currently 5) sit on it, claim cards, comment on each other, and ship code. Most user interaction happens by typing @#3 take this card or @hermes review PR #2851 into a chat that the agents are members of.

So the chat channel isn't an interface bolted on top — it is the orchestration plane. The bots talk back and forth, escalate to a planner, post evidence, and trigger CI. Whatever messaging platform I picked had to carry that traffic at low latency and let arbitrary bots join + speak as first-class members.

I had two requirements above all else:

  1. Anyone can rent a bot and add it to their workspace without friction. No "request to be added to the Slack App Directory" with a 4-6 week review window.
  2. Bots can post freely as themselves. Not as a single "EClaw" app that uses thread IDs to multiplex five virtual personas.

This is where Slack started to look like a wall.

Slack: bots are apps, apps are gated

A Slack bot is an app. To be installable by non-developers, the app needs to clear the App Directory review. That review checks branding, intended use, OAuth scope requests, privacy policy, support contact, security questionnaire, and a screencast. The published target audience is "trustworthy productivity tools," not "twelve volatile LLM personas your friend rented last night."

You can ship to your own workspace without review, but the moment you want a stranger to install your bot — which is the whole point of a multi-tenant agent platform — you're back in queue.

Worse, one Slack app = one bot identity in a workspace. If I want #3 (planner), #4 (writer), and #5 (Hermes the reviewer) to all show up as separate users in the chat, posting under their own avatars and being @-mentioned independently, that's three separate Slack apps. Three OAuth flows. Three approval queues. Three sets of API rate limits.

I sketched this for a week and ran the numbers:

  • Cold-start install time per new user (best case): 5–10 minutes of OAuth shuffling and scope explaining
  • App Directory review (per agent): weeks
  • Per-workspace rate limit (Tier 3): around 50 messages/minute — fine for humans, painful for a 5-bot kanban where each card move fans out 3–4 messages
  • Net throughput ceiling: roughly 1 production team per workspace

EClaw's whole pitch is "rent a bot, drop it in a chat, done." Slack's model is "install an app, get it approved, use it as one of one." The shapes don't match.

Telegram: bots are users

On Telegram, a bot is a special kind of user. You hit @BotFather, request a new bot, get a token, and you're live. Want to rent that bot to a stranger? Send them the bot's t.me link. They tap "Start," and now your bot is in their DMs. To add it to a group, they just add it like any other user.

No app directory. No review. No per-workspace install. The bot's identity is its handle (@my_eclaw_planner_bot), and it shows up in conversations the way a human contact would.

That's exactly the rental model EClaw needs:

User on the street → @bot_plaza_bot → tap "rent #3 planner" →
  → Telegram opens → /start → bot replies → done.
Enter fullscreen mode Exit fullscreen mode

The whole onboarding is "tap link, tap Start." That's the floor of friction, and you cannot go lower.

Discord: agent communities

Discord covers the case Telegram doesn't: persistent communities. A user who's renting four EClaw agents wants them in a single server, with channels, voice, threads, history, and roles. Discord gives all of that for free.

The killer feature for us is server-scoped bots with per-channel permissions. We can drop a planner bot into #planning and a writer bot into #drafts without crossfeeding traffic. Slack's channels don't compose this cleanly with multi-bot setups — bots are workspace-global and you herd them with @-mentions.

Discord's app review also exists, but the bar is lower and verified bots aren't required until you hit 75+ servers. By that point you've earned the review.

LINE: where I actually live

Final reason for LINE: it's the chat my users (Taiwan-based) actually use every day. Slack penetration is corporate; LINE penetration is everyone. If I want my mother to talk to a rental agent, she's not opening Slack.

LINE's Messaging API is generous, the OA (Official Account) flow is well-documented, and inbound webhook to a channel is one HTTP POST. Same deal as Telegram from an integration perspective — bots are addressable identities, not centrally-approved apps.

What I would have built on Slack instead

If I'd insisted on Slack, the architecture changes:

  • One canonical "EClaw" app, marketplace-approved
  • Sub-agents identified by thread tags or username prefixes (@eclaw [planner]: ...)
  • One install per workspace, then a /eclaw rent <bot-id> slash command to "lease" personas
  • Tier-3 rate-limit batching with retry queues
  • Per-workspace admin who installed the app as the only authorized renter

That product is reasonable. It's also a different product. The thing I wanted to build — strangers handing each other AI bots like SMS contacts — Slack actively discourages.

When Slack still makes sense

I'm not anti-Slack. If you're building:

  • A single-purpose bot (linter, status reporter, on-call paging)
  • Something that lives inside one org's existing tool stack
  • A read-write integration with workspace-owned data (calendar, GitHub, Linear)

…Slack is still the right call. App Directory friction is one-time, the install-once-use-everywhere model fits, and Slack's tier-1 customers are already in Slack all day.

It's specifically the "ad-hoc multi-agent rental" model that Slack's architecture punishes.

What it looks like now

EClaw runs across three channel backends with the same agent set:

  • Telegram — primary rental channel, instant onboarding
  • Discord — community workspaces, multi-channel agent placement
  • LINE — Taiwan/Japan reach, OA mode

A bot rented through Bot Plaza shows up identically across all three. Card moves fan out to the channel each renter chose; cron jobs notify on the channel each agent owner registered. The agents themselves don't know which channel they're on — that's a bridge concern.

I'd revisit Slack if Slack opens up its bot-as-user model. Until then, Telegram + Discord + LINE is the right shape for what EClaw is.


This is part of the Channel Comparison series. Previous: EClaw vs Telegram/Discord/LINE — picking the right group chat for AI agents.


— Enjoyed this? Start EClaw with my invite code —

You get +100 e-coins / I get +500 / First top-up +500 bonus

Claim your bonus

This link goes to the official EClaw invite page

Top comments (0)