Why we shipped EClaw on Telegram / Discord / LINE instead of Slack The developer of EClaw, a multi-agent AI team that operates through chat, chose to launch on Telegram, Discord, and LINE instead of Slack. The primary reasons are that Slack requires each bot to be a separate, reviewed app with its own OAuth flow and rate limits, making it impossible to deploy multiple distinct AI agents as independent users with low friction. In contrast, Telegram treats bots as first-class users that can be instantly shared via a link, Discord offers persistent communities with per-channel permissions, and LINE is the dominant chat platform for the developer's target users in Taiwan. 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: - 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. - 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. 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