The headline feature of Hermes Agent v0.2.0 was not a model integration or a skills system. It was the Multi-Platform Messaging Gateway — a single Hermes process listening on seven chat platforms simultaneously: Telegram, Discord, Slack, WhatsApp, Signal, email (IMAP/SMTP), and Home Assistant. By the April 8 release the list had grown to thirteen, with Matrix, Feishu, WeCom, Mattermost, DingTalk, and SMS (via Twilio) added along the way.
The thing that is easy to miss about this is that building one Telegram bot is not very hard. Building seven simultaneous chat integrations that share a single agent, a single memory, and a single tool registry — that is where the architectural work goes. This post walks through how Hermes actually does it.
The naive approach, and why it does not work
If you were to build "an AI bot that answers on Telegram and Discord," the first instinct is to stand up two separate bots. Each one has its own process, its own database, its own state. They both call the same language model API. The user on Telegram and the user on Discord get conceptually the same agent but in practice get two agents that do not know about each other.
This is what most existing bot projects do, and it is awful in ways that take a while to become obvious:
- •Memory diverges. A user who mentions on Telegram that they are allergic to peanuts will not have that fact when they ask a cooking question on Discord. The agent has to be taught the same thing twice.
- •Tool state drifts. A cron job set up via Slack does not show up when the user checks cron via Telegram. Session history is fragmented. Authorization tokens for shared resources (a Notion integration, say) have to be installed into each bot separately.
- •Operational overhead multiplies. N bots means N processes, N services, N log streams, N config files, N places something can break. The complexity grows linearly with platforms.
- •Safety rules fragment. If you tighten a dangerous-command approval policy in one bot, you have to remember to update it in the others. Security drift is the default.
Hermes makes a different call: there is exactly one agent process, exactly one session database, exactly one memory store, exactly one tool registry. The platforms are adapters — thin front doors that funnel messages into and out of the shared agent.
The shape of the gateway
Internally, the Hermes gateway has three layers.
At the bottom is the agent itself — the same Hermes core that runs in CLI mode. It does not know anything about chat platforms. It receives messages, runs its agent loop (LLM calls, tool calls, memory lookups, checkpoints), and produces responses. Its only interface to the outside world is a queue-based API.
In the middle is the gateway core — session management, user/platform routing, approval dispatch, cron scheduling, streaming, media handling. This is the part that turns "a message arrived on platform X from user Y in channel Z" into "an agent run in session S with these permissions." It also handles shared concerns: rate limits, flood control, duplicate message detection, inactivity-based timeouts, approval button routing, cross-platform state.
At the top are the platform adapters. There is one per platform: a Telegram adapter, a Discord adapter, a Slack adapter, and so on. An adapter's job is narrow — connect to its platform (via polling, long-poll, WebSocket, webhook, or whatever the platform's SDK prefers), translate incoming platform-native events into the gateway's internal message format, and translate the gateway's outgoing responses back into whatever the platform expects (Markdown, MarkdownV2, mrkdwn, Discord rich embeds, Matrix HTML, Slack blocks, email MIME).
The adapters are intentionally small. Adding a new platform (a community contributor added Mattermost in under 300 lines of Python in v0.4.0) is mostly a question of mapping its SDK's events into the gateway's internal message shape and vice versa.
How sessions work across platforms
A Hermes session is a conversation thread with its own memory window, tool state, and running history. On a single platform, sessions map naturally — one session per Telegram chat, one per Discord channel, one per Slack thread. Across platforms, things get more interesting.
By default, Hermes treats each platform/chat combination as a distinct session. Your Telegram DM with the bot, your Slack thread with the bot, and your Discord channel with the bot are three separate conversations with three separate running contexts, but they all share the same long-term memory through the pluggable memory provider (Honcho by default in v0.7.0 and later). So the cross-session information you expect to carry — "the user is allergic to peanuts," "the user's name is Alice," "the user's project is called Atlas" — rides on the memory layer, while the short-term context of each conversation stays scoped to the platform you are using.
This is the design that lets the same assistant feel like the same assistant on every platform, without turning every message into a tangled global broadcast.
Why shared thread sessions matter
In v0.4.0, Hermes added a feature called shared thread sessions by default — in group chats, each user gets their own session inside the same thread. This sounds small and is huge for anyone who has ever tried to run a multi-user bot in a group.
Without per-user sessions in a group chat, every message is part of one shared conversation. If Alice asks the bot a question, and Bob asks a different question thirty seconds later, the bot's context is now a tangled mix of both. Answers get crossed. Memory for Alice gets polluted with Bob's data. Gateway mode gets worse as more users join.
With shared thread sessions, Alice and Bob each have their own private session inside the thread. They see each other's messages in the visible chat, but the agent keeps separate contexts and separate memory writes per user. In v0.8.0 this became the default behavior across all gateway platforms. It is the kind of fix that is invisible until you have been burned by the alternative, at which point you never want to go back.
What the gateway is actually for
Once you squint at the architecture long enough, the gateway stops looking like "a way to run bots on chat platforms" and starts looking like the thing it really is: a coordination layer between humans (on whichever app they happen to be using) and a singular AI assistant with shared memory and shared tools.
The chat platforms are not the product. They are the entry points. The product is the assistant that exists behind them, and the fact that you never have to think about which entry point you are using.
That is the feature Hermes shipped on day one. Everything else is the story of what that coordination layer learned to do over the next four weeks.