Connecting Discord, Slack, Telegram, and WhatsApp Integrations

Wire Discord, Slack, Telegram, and WhatsApp as adapters into one self-hosted personal agent brain - not as four separate agents.

Platform APIs and terms change. Verify bot capabilities, rate limits, and automation rules at build time.

Summary

Normalize every platform into one event shape, authorize per-platform sender ids, run a single bounded agent loop, and egress through the same adapter that received the message. Add platforms only after the first private channel is boringly reliable.

Recipe

1. Choose a primary control channel. Prefer a private Telegram DM or a locked Discord/Slack channel you alone can use.
2. Create bot credentials in each platform developer console; store tokens in the host env file (chmod 600).
3. Implement one adapter interface per platform: parse_inbound → ChatEvent, authorize, send_message.
4. Allowlist sender and channel ids per platform (default deny). Group chats stay off high-risk tools.
5. Route all events into the same agent runner with max_turns and shared prefs/memory.
6. Preserve reply routing metadata (platform, thread_id, channel_id) so answers return to the right place.
7. Add idempotency on platform message ids to survive retries and double delivery.
8. Smoke-test each adapter alone, then together; confirm cross-platform users cannot share one identity by accident.
9. Document pause and token rotation for every bot token you added.

Working Example

Shared types and a multi-adapter dispatch sketch:

from pydantic import BaseModel
from typing import Callable, Protocol
 
class ChatEvent(BaseModel):
    platform: str
    sender_id: str
    text: str
    channel_id: str
    thread_id: str | None = None
    message_id: str
 
class ChatAdapter(Protocol):
    name: str
    def poll_or_handle(self) -> list[ChatEvent]: ...
    def send(self, event: ChatEvent, text: str) -> dict: ...
 
ALLOWED = {
    "telegram": {"111"},
    "discord": {"222"},
    "slack": {"U333"},
    # whatsapp: add only after Business API setup is real
}
 
SEEN: set[str] = set()  # persist to disk in production
 
def authorize(event: ChatEvent) -> bool:
    return event.sender_id in ALLOWED.get(event.platform, set())
 
def handle_event(event: ChatEvent, adapters: dict[str, ChatAdapter], run_agent) -> None:
    key = f"{event.platform}:{event.message_id}"
    if key in SEEN:
        return
    SEEN.add(key)
    if not authorize(event):
        return
    answer = run_agent(event.text, meta=event.model_dump())
    adapters[event.platform].send(event, answer)
 
def tick(adapters: dict[str, ChatAdapter], run_agent: Callable) -> None:
    for adapter in adapters.values():
        for event in adapter.poll_or_handle():
            handle_event(event, adapters, run_agent)

Telegram-shaped parse (structure only; use the official Bot API client of your choice):

def telegram_to_event(update: dict) -> ChatEvent | None:
    msg = update.get("message") or {}
    if "text" not in msg:
        return None
    return ChatEvent(
        platform="telegram",
        sender_id=str(msg["from"]["id"]),
        text=msg["text"],
        channel_id=str(msg["chat"]["id"]),
        thread_id=str(msg["chat"]["id"]),
        message_id=str(msg["message_id"]),
    )

Per-platform env sketch:

TELEGRAM_BOT_TOKEN=...
DISCORD_BOT_TOKEN=...
SLACK_BOT_TOKEN=...
SLACK_APP_TOKEN=...          # if using socket mode
# WhatsApp Cloud API (verify current field names at build)
WHATSAPP_TOKEN=...
WHATSAPP_PHONE_NUMBER_ID=...

Deep Dive

One brain, many connectors

Clawdbot/OpenClaw-style personal agents treat each platform as a connector. The model, tools, memory, and policy stay central.

Duplicating a full agent per platform multiplies cost, drift, and incident surface. Share the runner; isolate credentials and rate limits.

Platform notes (architecture level)

Exact intents, slash commands, and button payloads differ. Keep those differences inside the adapter, not in tool code.

Authorization models

• DM allowlist: map platform user id → permitted.
• Channel allowlist: even if the user is you, ignore random channels the bot was invited to.
• Role gates (Discord/Slack): useful when a household shares a server - still prefer separate tool credentials per person for mail/shell.
• Linking: store telegram:111 and discord:222 as the same human only after an explicit link flow you control.

Never trust a display name. Ids are the unit of auth.

Group vs DM policy

Idempotency and ordering

Chat platforms retry. Persist processed platform:message_id keys (SQLite or a file-backed set) so double delivery does not double-send mail later.

Do not assume global ordering across platforms. Task state should key off your internal task id, not "the last Discord message."

Rate limits and spam to yourself

Cap outbound messages per minute per platform.

Batch digests instead of one bubble per email.

Disable proactive posts during quiet hours except explicit VIP break-glass rules.

WhatsApp special case

WhatsApp is often excellent for notifications and weaker as a first deep tool-control surface because of Business API setup and policy constraints.

If you add it, start with outbound digests to yourself, not full bidirectional shell control.

Gotchas

1. One shared allowlist string for all platforms. Ids are not portable across Telegram and Discord.
2. Bot invited to a public server. Discoverable bots get random commands; deny by default.
3. Putting platform-specific if/else inside every tool. Tools should not know Discord snowflakes.
4. Logging full message bodies forever. Chat content is personal data; retain on purpose.
5. Thread metadata dropped. Replies land in the wrong place or as orphan DMs.
6. Slack workspace-wide install for a personal bot. Prefer the minimum install surface your admin allows.
7. WhatsApp session hacks. Unofficial clients break ToS and reliability; prefer official APIs.
8. Assuming buttons equal security. Approval UIs still need server-side checks that the clicker is allowlisted.

Alternatives

FAQs

Related

• Self-Hosted Personal Agents Basics - first single-platform loop
• Setting Up Clawdbot/OpenClaw on a VPS or Local Machine - host process setup
• The Self-Hosted Personal Agent Mental Model - adapters vs brain
• Self-Hosted Personal Agents Best Practices - allowlist and token habits
• Chat-Integrated Agents - platform cheatsheet
• What a Personal AI Agent Actually Does Day to Day - why chat is the UI

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.