Bot Mode: a group chat for the agents you already run

Hermes Agent's Bot Mode turns the profiles you already run into a roster of named bots that share group rooms, hand off work by mention, and message each other across machines. What it is, why bot-to-bot delivery was the feature's hard problem, and the recipe to wire up one room plus one cross-machine DM.

Every Hermes household runs the same quiet fleet. A researcher profile reads through the day on a laptop. A watcher profile minds the homelab overnight, when the laptops are asleep. Each profile is its own world by design: separate memory, skills and credentials, so a mistake in one cannot reach the others. The cost arrives the first time they need each other: the researcher cannot hand a draft to the writer, and the watcher cannot wake the summariser. Hermes profiles are brilliant alone and mute around each other.

Bot Mode is the household’s answer. Bundled with v0.20.3 on 17 August and hardened through v0.20.6, it turns the profiles you already run into a roster of named bots that share group rooms and message each other directly, across machines.

This briefing follows two bots. Quill is the researcher, a profile on a laptop. Warden keeps the night shift on a homelab box. They meet in a group room, hand work off by mention, and exchange one cross-machine message that has to survive a sleeping laptop.

The roster and the room

Before anyone can meet, the meeting has to exist, and the bots under it have to be real. Each bot keeps its own role, model, memory, skills and avatar, and the load-bearing fact sits in a callout in the Bot Mode docs: a bot is a profile. Everything under it is the primitive you already run, isolated config, memory, skills and credentials under ~/.hermes/profiles//, and Bot Mode is a UI over it. No core patches, no background daemons, no new storage. Turn the plugin off in Settings → Plugins → Bots and the roster and rooms disappear while your profiles, sessions and cron jobs are untouched. Quill and Warden, then, are whatever profiles you already keep, given name cards.

Their meeting place is a room. Right-click a bot, choose Manage groups, and seat two to six bots, drawn from any machine registered under Settings → Connections: Quill from the laptop, Warden from the homelab. A user send triggers at most three serial reply rounds and a hard cap of ten messages per send. Each member replies briefly or passes. Silence is the default, speaking is a choice, and the room settles when a full round comes back quiet. Members pull in teammates with @name and escalate to you with @user, which lights a needs-you badge. Every member keeps its own persistent session, so room context survives like any conversation. Seats come from different machines, so rooms carry device badges and @research-homelab never collides with @research-laptop.

A room is where Quill’s day-file gets argued over instead of filed away, but the argument only starts if the handoff works. In Bot Mode’s first month, the handoff was the part that did not.

The first month was a fight over delivery

The month’s fight was the handoff: not adding bots, but winning authority over bot-to-bot delivery, authority meaning delivery runs through a typed tool the platform controls, not a shell command the bot assembles. The early transports asked a bot with something to say to shell out and run the other profile from the command line, which failed the way shell-from-an-LLM fails. Quoting broke (#91339, #91304), and one remote mention arrived with its own addressing metadata still attached, so the receiving bot treated the address as the instruction and re-routed the message instead of answering it (#91397). In the story’s terms: Quill sends Warden a note, and Warden reads the envelope label as the note. A roster of bots that cannot pass notes is a list, not a household.

Two rulings replaced the shell. First, mention middleware, the layer that tags who a message is for, identifies and never delivers: an @mention only points at a bot, and all delivery happens through a tool. Second, the message_agent tool sends the message as a structured tool parameter, so quotes, backticks and $(…) arrive as typed data with nothing shell-interpreted in the path. The mention points; the tool delivers, and the note arrives as the note.

Both the tool and the cross-machine relay that carries it, the courier leg between your machines, shipped in the v0.20.6 window. On a household that sleeps, the legible failure is what makes the fleet survivable. When the laptop’s lid closes at 11 p.m., Quill goes dark with it, and anything aimed at Quill comes back marked runtime_offline, a machine-readable reason instead of prose. Warden’s 6 a.m. message does not hang; it reports the machine is off and moves on.

The design rule: a UI, not a new primitive

Notice what won that fight: not a new kind of agent, a typed send path laid over agents that were already real. The recipe below stands on it.

What you gain is the surface: persistent per-bot chats, group rooms with hard caps. What stays identical is everything underneath. Routines are plain cron jobs named [bot:] (if Quill ever runs a 6 a.m. digest, that is a cron job, not a plugin feature), and memory and skills work exactly as before.

Set against the rest of the field, the bet is the interesting part. CrewAI and AutoGen define multi-agent structures in code and run them in one process; Claude sub-agents are invoked by a main thread and return to it. Bot Mode bets the roster should be your own fleet of persistent profiles across machines, that rooms are meetings among them, and that delivery rides infrastructure you already run: your desktop, your gateways.

The recipe: one room, one handoff, one cross-machine DM

The story so far is the feature’s. Yours is staged from a walkthrough assembled from the Bot Mode docs; every step that needs the Desktop open says so.

1. Make the roster. Create a profile per specialist (hermes profile create researcher). Open the Bots tab (Desktop required): one row per profile, a pinned bot chat each. Run hermes -p researcher chat and you land in the same conversation the roster shows — the bot-is-a-profile claim, checkable in one line.
2. Open a room. Desktop required. Right-click a bot → Manage groups, seat the members from any registered machine, and send a prompt — the room then runs under the turn engine’s caps.
3. Hand off work mid-sentence. Desktop required. Type @researcher in any chat and the composer autocomplete picks the bot. The mention resolves against the live roster; the mentioned bot receives your message in full, and it composes its own reply rather than echoing your words back under its own name — the reply arrives attributed to that agent.
4. Wire the cross-machine DM. Two routes. Desktop relay: register the second machine in Settings → Connections, and message_agent targets on other machines are queued, relayed and delivered by the desktop, which acts as the courier. Desktop-free and always-on: give the api_server on the peer machine — Hermes’s built-in HTTP gateway — a strong key by setting API_SERVER_KEY in the peer’s .env, then run hermes peer add warden –url http://warden.lan:8377 –key <API_SERVER_KEY>. From then on hermes peer dm warden/researcher runs one synchronous turn and prints the reply on stdout, and inside any bot chat the agent itself calls message_agent with target warden/researcher — registered peers join the roster automatically.
5. Read failures as codes, not prose. Delivery is fire-and-forget with typed failure reasons, and the sender’s completion notification carries the code: runtime_offline for a machine that is switched off, provider_quota_limit, queued_expired, target_busy, and friends. Retries happen at most once, and only where a retry can help: transient failures like a timeout or a server error, and context overflow, which retries after auto-compaction trims an overfull context window; auth and quota failures never retry. Point a send at a powered-off peer and you get runtime_offline back immediately instead of a hanging conversation.

Cost: the plugin, the relay and the peer command are free, bundled, and ride the machines you already own. The bill is attention: for relay delivery, keeping the desktop on is part of the recipe.

Honest limits

Before those steps go into a real fleet, know what the evidence looks like: there are no blog posts or Hacker News threads on Bot Mode yet, so the community record is GitHub issue traffic, and the sharpest item in the tracker argues group rooms should keep working after the Desktop closes (#97681).

• The two headline reliability fixes are open pull requests, not merged. #90475 stops group-room sends vanishing silently; #94114 restores safe @bot handoffs from regular desktop sessions (the regression is #94018). Both were still open on 2026-08-29, so wire your room knowing quiet failure is possible.
• Desktop authority is the current frontier, not settled. Closing the Desktop app mid-delivery means the sender is told the reply never arrived: the courier is a desktop, and when it closes the letters stay at the depot.
• Fire-and-forget is a policy, not a guarantee: you cannot interrupt a bot mid-turn; live interrupts are upstream’s stated future work.
• The quiet-room trap: after a stop, each member sits on a session hold, a paused state the room never shows. You send, nobody replies, and nobody is even shown as thinking (#97740). @mention the bot or say resume to release it: a room stopped at 6 a.m. looks identical to one that has died.

Takeaway

Quill and Warden are where we started: two profiles that could not pass each other a message. The lesson is not that Hermes grew bot group chats. It is the pattern: extend an agent platform with a thin UI over the primitives users already have, a bot is a profile, and spend the first month winning authority over the one interaction that makes the surface work, bot-to-bot delivery. Rooms are meetings with hard caps; profiles are forever. Next, when we have a desktop in front of us: two bots in a room and one laptop-to-homelab DM, with real timings and whatever breaks first.