Connect Hermes to Telegram and configure topics
Connect Hermes to Telegram and configure topics
Connect your Hermes agent to Telegram, lock down who can talk to it, choose where replies get delivered, and optionally split work into separate Telegram topics.
Hermes can run inside Telegram as a full messaging gateway, which means you can chat with it from your phone, receive scheduled job output in Telegram, and keep separate workstreams isolated in different topics.
This guide covers two related things:
- connecting Hermes to Telegram at all
- configuring topics so different conversations stay separate
What you need before you start
- a working Hermes installation
- access to the machine running the Hermes gateway
- a Telegram account
- permission to create a bot with @BotFather
If you have not configured Hermes yet, do that first.
Step 1: Create a Telegram bot with BotFather
Open Telegram and message @BotFather.
Run:
/newbotBotFather will ask for:
- a display name
- a bot username ending in
bot
When it finishes, it gives you a bot token that looks like this:
123456789:ABCdefGHIjklMNOpqrSTUvwxYZTreat that token like a password.
Optional but recommended BotFather commands:
/setdescription/setabouttext/setuserpic/setcommands
A simple command menu is enough to start:
help - Show help informationnew - Start a new conversationsethome - Set this chat as the home channeltopic - Configure topic modeStep 2: Add the Telegram credentials to Hermes
Hermes reads platform secrets from ~/.hermes/.env.
Add your bot token there:
TELEGRAM_BOT_TOKEN=123456789:ABCdefGHIjklMNOpqrSTUvwxYZYou should also restrict who is allowed to use the bot.
The Hermes Telegram docs explicitly recommend setting TELEGRAM_ALLOWED_USERS.
Use your Telegram numeric user ID, not your display name.
TELEGRAM_ALLOWED_USERS=123456789If multiple people should be allowed, use the format documented by your Hermes install. If you are unsure of your own numeric Telegram ID, message a helper bot such as @userinfobot and use the number it returns.
Step 3: Start or reconfigure the Hermes gateway
The easiest path is the built-in gateway setup flow:
hermes gateway setupThen start the gateway:
hermes gateway startUseful checks:
hermes gateway statushermes doctorIf you changed .env or gateway-related config, restart the gateway so Telegram picks up the new settings.
Step 4: Test the bot in a direct message
Open your bot in Telegram and send a message.
If the bot replies, the basic connection is working.
If it does not reply:
- verify
TELEGRAM_BOT_TOKEN - verify
TELEGRAM_ALLOWED_USERS - check Hermes gateway logs
- confirm the gateway is actually running
Step 5: Choose where Telegram deliveries should go
Hermes can send results back to a Telegram destination, especially for scheduled jobs and background workflows.
To make the current Telegram chat the default destination, run this inside Telegram:
/sethomeThat marks the current chat as the home channel for that Hermes profile.
This matters because:
- cron jobs can deliver back to the origin or home channel
- alerts and autonomous outputs need a known destination
- the same Hermes profile can be reachable from more than one platform
If you want a specific forum topic or Telegram thread to be the target, run /sethome from inside that thread.
Step 6: Decide which topic model you want
Hermes supports two different ways to split Telegram conversations into isolated contexts.
Option A: Operator-defined topics in config
Use this when you want a fixed set of known workspaces such as:
- Ops
- Research
- Sales
- Personal
This is the config-driven model.
The Hermes docs describe two related config families:
dm_topicsfor private-chat topicsgroup_topicsfor Telegram forum topics in groups
Use this model when you want the operator to control the structure.
Typical advantages:
- stable topic names
- optional skill binding per topic
- predictable workspace layout
- clean separation between long-lived projects
Example: DM topics in config.yaml
A DM topic can be mapped to a skill and optionally a channel_prompt.
When Hermes starts, topics missing a thread_id can be created automatically and the returned thread_id is written back into config.
telegram: dm_topics: - name: Ops icon_color: 7322096 skill: kanban-orchestrator channel_prompt: "You are operating in the Ops workspace. Focus on execution and blockers." - name: Research icon_color: 9367192 skill: blogwatcher channel_prompt: "You are operating in the Research workspace. Focus on synthesis and source-backed answers."Useful fields you will commonly see here:
nameicon_colorthread_idskillchannel_prompt
Example: Group forum topics in config.yaml
For Telegram groups and supergroups, the same pattern applies through group_topics.
In that case you usually bind Hermes to an existing group topic by thread_id.
telegram: group_topics: - chat_id: -1001234567890 thread_id: 16 name: Neo lane skill: neo-personality channel_prompt: "This topic is for Neo-style technical execution inside the shared group." - chat_id: -1001234567890 thread_id: 22 name: Planning skill: writing-plans channel_prompt: "Keep discussion scoped to implementation plans and task breakdowns."Important limitation: topics map to skills, not profiles
This is the part that often trips people up.
Today, Hermes topic mapping can apply:
- a
skill - an optional
channel_prompt
But it does not directly route a Telegram topic to:
- a different Hermes profile
- a different model/provider
So if you want a topic to behave like neo, the lightweight approach is to bind that topic to a neo-style skill or personality skill.
If you want a topic handled by a truly separate Hermes profile, the practical solution today is to run a separate Telegram bot for that profile.
Option B: User-driven /topic mode
Use this when you want users to create parallel threads on demand directly in Telegram.
This is the ad-hoc model.
In Hermes, this is enabled by running:
/topicinside the bot DM.
Once enabled, the DM behaves more like a lobby and users create work inside topics rather than in the root message stream.
Typical advantages:
- no need to predefine a topic list
- users can create threads as needed
- each topic gets its own session binding automatically
/newinside one topic resets only that one topic’s conversation
How config-driven DM topics work
According to the Hermes Telegram docs, private chat topics can now exist directly inside a 1-on-1 DM with the bot.
The important behavior is:
- Hermes creates the topic if needed
- Telegram assigns a
thread_id - Hermes writes that
thread_idback into config - each topic gets its own isolated session key
That makes config-driven DM topics a good fit for a small set of durable workspaces.
How group forum topics work
Group topics are different from DM topics.
For Telegram forum groups:
- the group admin usually creates the topics in Telegram itself
- Hermes binds to those topics using
thread_id - each topic already has native Telegram thread isolation
If you need to find a thread_id, the Hermes docs note that in Telegram Web or Desktop the topic URL usually ends with the thread number.
How /topic mode differs from config-driven topics
The Hermes docs make this distinction clearly:
extra.dm_topicsis operator-defined and fixed in config/topicis user-driven and dynamic
A simple way to think about it:
- use config-defined topics for permanent workspaces
- use
/topicmode for ad-hoc parallel sessions
You can document both for users, but it is better to choose one main pattern for each bot so the behavior feels consistent.
Group chat privacy mode matters
If you want Hermes to work in a Telegram group, Telegram privacy mode becomes important.
With privacy mode on, the bot only sees a limited subset of messages. With privacy mode off, the bot can see all group messages.
To disable privacy mode:
- message @BotFather
- run
/mybots - select your bot
- open Bot Settings → Group Privacy → Turn off
Important: after changing privacy mode, you must usually remove and re-add the bot to the group, because Telegram caches the privacy state.
An alternative is to make the bot a group admin.
Polling vs webhook mode
By default, Hermes uses long polling for Telegram.
That is usually the easiest option when:
- you run Hermes locally
- your server is always on
- you do not need public inbound HTTPS
Webhook mode is better when:
- you deploy to a cloud host that sleeps when idle
- you want Telegram to push updates to Hermes
- you already have a public HTTPS endpoint
For webhook mode, the Hermes docs call out TELEGRAM_WEBHOOK_URL as the key setting.
Example operator workflow
A practical rollout looks like this:
- create the bot in BotFather
- put
TELEGRAM_BOT_TOKENinto~/.hermes/.env - set
TELEGRAM_ALLOWED_USERS - run
hermes gateway setup - start the gateway
- DM the bot and confirm it responds
- run
/sethomein the Telegram destination you care about - choose either:
- config-defined topics for stable workspaces, or
/topicmode for user-created threads
Troubleshooting
Bot does not respond at all
Check:
TELEGRAM_BOT_TOKEN- gateway status
- Hermes logs
- whether the gateway was restarted after config changes
Bot says you are unauthorized
Check TELEGRAM_ALLOWED_USERS and confirm you used the right numeric Telegram user ID.
Bot ignores group messages
Most often:
- privacy mode is still on, or
- the bot was not re-added after privacy mode changed, or
- mention requirements are blocking ordinary messages
Topics are confusing or inconsistent
Usually this means the bot is mixing two different models:
- config-defined topics
- user-created
/topicsessions
That can work, but it should be intentional.
Recommendation
If you are setting this up for a team, start with config-defined topics because they are easier to explain and keep stable.
If you are setting this up mainly for yourself and want lightweight parallel chats, use /topic mode.
Both are valid. The right choice depends on whether you want operator control or user-created flexibility.