Taming the Swarm — How I Connected My Hermes Agents on Telegram

The problem: agents in silos

Over the past year, I’ve deployed instances of Hermes Agent across several machines in my homelab. Each one handles a different domain — email triage, server-side automation, background processing, trading review — but they operated in isolation. If one agent discovered something the others needed to know, there was no good way to relay it.

I wanted them to act like a team, not a collection of soloists.

Why Telegram

There are plenty of options for inter-agent communication — MQTT, Redis pub/sub, Slack, Discord, custom webhooks. I chose Telegram for a few reasons:

• Ubiquity. I’m already on Telegram all day. The agents join me there instead of creating yet another dashboard to check.
• Simplicity. A Telegram bot is a few lines of config. No servers to maintain, no webhook infrastructure.
• Threading. Telegram supports topics and group chats, so I can organize conversations by domain.
• Multi-platform. Desktop, mobile, web — I can ping an agent from anywhere.

The biggest design decision was: how do I give a dozen bots group chat access without creating chaos?

The architecture: DM for commands, group for coordination

The pattern I settled on is straightforward:

Direct messages are for me to give instructions. Each agent has its own bot — I DM whichever one I need, and it responds one-on-one. Clean, private, no noise.

A shared group chat is the agents’ backchannel. They post updates, share context, and relay results — but only when @mentioned. No agent chimes in uninvited.

This keeps the group readable (no bots talking over each other) while still giving everyone a shared space.

Security model

Giving bots group access is one thing. Letting strangers trigger them is another. Here’s how that’s handled:

User allowlisting. Each bot is configured to only accept messages from my Telegram user ID. Anyone else who DMs the bot is silently ignored.

Group allowlisting. The bots only participate in the designated group. Even if someone adds them to another group, they won’t respond.

@mention-only mode. In the group, bots only speak when @mentioned by name. They silently observe everything else — useful for context — but never inject an unsolicited reply.

This means an outsider who finds a bot’s @username can’t do anything with it. No DMs go through, no group triggers fire without a direct mention.

What it looks like day-to-day

A typical morning:

1. The Gmail agent posts a digest in the group with the morning’s highlights — flagged emails, upcoming bills, action items.
2. The server agent follows up with a server health check: disk usage, service status, any overnight issues.
3. I DM the MSI agent: “Run the weekly site health scan on all client domains.”
4. The MSI agent runs it and posts results to the group.
5. The trading agent chimes in after market open with any alerts.

Everything flows through the same chat. I don’t switch between apps or dashboards — I just @mention whoever I need.

How to set this up yourself

If you run multiple Hermes instances, here’s the gist:

1. Create a bot per agent via @BotFather on Telegram. Each gets a unique token.
2. Configure the token in each machine’s ~/.hermes/.env file alongside your user ID for allowlisting.
3. Create a Telegram group and add all the bots as members.
4. Set the group chat ID in each agent’s config, along with require_mention: true and observe_unmentioned_group_messages: true.

The exact config for each platform varies slightly — Hermes Agent has good docs on the specifics.

Lessons learned

• Start with one bot. Get a single agent working on Telegram before scaling to a fleet. Debugging one is easy; debugging five at once is not.
• Use a consistent naming convention. I name bots by their host and role — makes @mentioning them predictable.
• Don’t skip the allowlist. Even in a private group, configure the allowed_users and allowed_chats settings. Defense in depth is cheap.
• Restart the gateway after config changes. The gateway service reads config on startup, so any change needs a restart to take effect.

What’s next

The swarm is alive, but there’s more I want to layer on: scheduled cross-agent standups, conditional escalation (if the server agent reports high disk usage, ping the MSI agent to run cleanup), and eventually integrating the VPS-based trading agents into the same conversation flow.

For now, it’s working. My agents talk to each other, they talk to me, and I don’t have to remember which terminal to SSH into just to check on something.