Building a Gateway Bot: Telegram, Discord, and Slack

From CLI Agent to Platform Bot

Everything so far has run through hermes or hermes --tui, a single interactive session on your machine. The messaging gateway takes the same configured agent, same models, tools, memory, and skills, and exposes it as a bot on messaging platforms, so it’s reachable from wherever you already are, not just your terminal.

flowchart TB
    GW["Gateway process\n(single background service)"]
    TG["Telegram adapter"] <--> GW
    DC["Discord adapter"] <--> GW
    SL["Slack adapter"] <--> GW

    GW --> SESS[("Unified sessions")]
    GW --> AGENT["Same configured agent:\nmodels, tools, memory, skills"]

    style GW fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style TG fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style DC fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style SL fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style SESS fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style AGENT fill:#EEF0F7,stroke:#6366F1,color:#0F172A

Hermes’ gateway supports 27+ messaging platforms in total, this lesson covers the three most common: Telegram, Discord, and Slack. The pattern generalizes to every other adapter you’ll find in the docs.

Connecting Telegram

# ~/.hermes/.env
TELEGRAM_BOT_TOKEN=123456:ABC-...    # from @BotFather

# ~/.hermes/config.yaml
gateway:
  telegram:
    enabled: true

hermes gateway start

Connecting Discord

# ~/.hermes/.env
DISCORD_BOT_TOKEN=...

gateway:
  discord:
    enabled: true
    # optional: restrict to specific servers/channels
    allowed_guild_ids: ["123456789012345678"]

Connecting Slack

# ~/.hermes/.env
SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-...    # for Socket Mode

gateway:
  slack:
    enabled: true

What’s Actually Unified Across Platforms

The gateway centralizes several things so you don’t reimplement them per platform:

• Session management: a conversation on Telegram and a conversation on Slack draw from the same underlying memory system (Module 4), the agent’s persistent knowledge of you doesn’t fragment by platform.
• Cron delivery: a scheduled task (next lesson) can deliver its result to whichever platform makes sense, without separate scheduling logic per adapter.
• Media handling: attachments and voice transcription are handled once, at the gateway level, rather than per platform.
• Live typing status: the gateway shows a “typing…” indicator on platforms that support it (Telegram, Discord, Signal) or an “is thinking…” status (Slack), so users get the same responsiveness cue regardless of which platform they’re on.

What is not forced to be identical: tool availability. You can scope a different toolset per platform, the same platform_toolsets mechanism from Lesson 7.3, applied per adapter, so a public Discord server and a private Telegram chat with yourself can have very different capability levels while sharing the same underlying agent.

Checking Gateway Health

hermes gateway status

reports each connected adapter independently. Because platforms connect through separate adapters sharing one gateway process, one platform’s credentials expiring or connection dropping doesn’t take down the others, but it does mean you check status per platform, not just “is the gateway running.”

Exercise: connect one messaging platform (Telegram is the fastest to set up, via @BotFather) to your Hermes gateway, and send it a message that requires a tool call, something that exercises the same tool-calling loop from Module 3. Then run hermes gateway status and confirm it reports that platform as healthy.