Hermes Bot Mode: How Bots, Routines, Groups, and Profiles Work

Hermes Bot Mode turns existing Hermes profiles into named specialist Bots inside Hermes Desktop. Each Bot keeps its own model, instructions, memory, skills, credentials, tools, and persistent chat. Bot Mode then adds a roster, recurring Routines, group chats, direct Bot-to-Bot messages, and routing across connected Hermes machines. It is an interface over profiles, not a second agent runtime or a hosted computer.

What Hermes Bot Mode actually adds#

Bot Mode is built into Hermes Desktop and enabled by default. It adds four practical layers on top of the profile system:

1. Bots roster: one activity-aware row per profile, with an avatar, description, latest-message preview, search, hidden-Bot controls, and a canonical Bot Chat.
2. Routines: recurring work attached to the Bot responsible for it. Underneath, each Routine is a profile-scoped cron job.
3. Groups: rooms where two to six Bots can deliberate, mention one another, and escalate a judgment call to the user.
4. Connections: one roster can include profiles from local, remote, SSH, Docker, or cloud backends while each Bot continues to run on its owning machine.

This separation matters. A polished Desktop roster does not move a Bot's memory, tools, browser session, provider credentials, or uptime into the app. The backend that owns the profile still owns the work.

A Bot is an isolated Hermes profile#

Hermes does not introduce a separate storage format for Bots. A named Bot lives under the normal profile boundary at ~/.hermes/profiles/<name>/. That boundary isolates the Bot's config, memory, skills, credentials, sessions, and instructions from other profiles.

This makes specialist Bots useful when broad, all-purpose context has become noisy. Instead of loading sales instructions, coding tools, research sources, personal memory, and support procedures into every turn, you can create narrow profiles such as:

• Research Bot: web, browser, citation, and source-analysis skills.
• Content Bot: editorial rules, content graph access, and publishing checks.
• Operations Bot: dashboards, logs, scheduled monitors, and incident runbooks.
• Client Bot: one customer's files, terminology, integrations, and channel access.

The isolation is operational, not decorative. A Bot only has the capabilities and secrets available to its profile and backend. That is safer and usually cheaper than giving every agent every tool, but it still requires deliberate permissions. Read the profiles isolation guide before cloning a profile that contains sensitive skills or credentials.

Create a Bot in Hermes Desktop#

Use this minimal setup path:

1. Install or update Hermes, run hermes doctor, and open Hermes Desktop.
2. Select Bots in the left sidebar. Bot Mode is bundled and on by default.
3. Click New Agent.
4. Enter a Name, Title, and Description. These fields tell people and other Bots what the specialist does.
5. Create the Bot and wait for its first message in the canonical Bot Chat.
6. Give it one real task before adding more tools or automations.

Use the Advanced section when the job genuinely needs it. You can clone an existing profile or start fresh, pin a model/provider, write a custom SOUL.md, and select individual skills, toolsets, and MCP servers. A minimal Bot is easier to understand and debug than a clone with every capability enabled.

If Desktop itself is not working, fix that first with the Hermes Desktop setup guide. Bot Mode cannot compensate for a broken provider, missing profile, or unreachable backend.

Canonical Bot Chat versus a normal session#

Each Bot gets one persistent canonical Bot Chat. It is meant to preserve the ongoing relationship with that specialist. Regular Hermes sessions still exist for temporary or project-specific work, but the Bot Chat is the stable home for that Bot's direct messages and recurring context.

Inside canonical Bot Chat, reset requests are intentionally redirected to context compaction rather than forking the permanent relationship. When a long Bot Chat becomes unwieldy, compact its working context; the conversation identity remains the same.

CLI users retain parity because the Bot is still a profile:

hermes profile list
hermes -p research chat
hermes cron list

The first command shows profiles, the second opens the same specialist from a terminal, and the third lists its Routines as ordinary cron jobs.

Routines are profile-scoped cron jobs#

A Routine is recurring work displayed beside the Bot that owns it: a morning research brief, a repository audit, an inbox summary, or a quiet service check. Bot Mode gives that scheduled job a clearer human owner, but the scheduler remains the normal Hermes cron system.

Use this acceptance test for every Routine:

1. Confirm the correct Bot/profile owns the job.
2. Inspect the schedule and timezone.
3. Set the delivery target explicitly when the result belongs in Telegram, Discord, Slack, email, or Bot Chat.
4. Run it once manually.
5. Inspect cron history and the output artifact.
6. Verify the result in the real destination, not only in the Routines pane.

The AI agent cron jobs guide covers script-only jobs, delivery limits, run history, retries, and end-to-end proof. A Routine card is not proof that the work completed.

Group chats coordinate specialist Bots#

Bot Mode group chats put two to six Bots in one room. Mention particular Bots when you want a scoped answer; when nobody is mentioned, members decide whether they have something useful to add. Hermes caps the exchange at three serial rounds and ten messages per send so a group cannot deliberate forever.

A useful group has distinct roles. For example, a release group could contain:

• @builder to implement the change,
• @reviewer to inspect correctness and risk,
• @publisher to verify documentation, links, deployment, and the live page.

Do not create five nearly identical generalists. Group chat is most valuable when each profile has a clear job, bounded capabilities, and a reason to disagree. Bots can use @user when a decision requires human judgment.

Bot-to-Bot messages and handoffs#

Canonical Bot Chats include a message_agent capability for direct handoffs. A Bot selects a teammate from the current roster, composes a message, and delivers it with sender attribution. The receiving Bot runs later and its response returns as a background completion; delivery is not a live interruption of another active turn.

From a human chat, an @researcher mention resolves against the live roster and tells the active Bot which teammate you mean. Hermes does not blindly forward your original text: the active Bot composes the actual handoff. This is useful for delegation, but it also means you should verify the receiving Bot's output rather than assume the wording was preserved.

For cross-machine direct messages without Desktop in the loop, Hermes also supports registered peer gateways through hermes peer. Keep peer API keys in the Hermes environment, use a private network or VPN, and treat the remote gateway as an authenticated service boundary.

Bots across local and remote machines#

Desktop Connections can combine profiles from multiple Hermes backends into one roster. When the same profile name exists on more than one machine, Bot Mode disambiguates the handle with the device name. A group can also include Bots whose turns execute on different machines.

The important rule is unchanged: the owning backend holds the Bot's state and runs its tools. A local Desktop can route to a Bot on a VPS, NAS, Docker host, or remote workstation, but it does not copy that Bot's files or memory locally. Use the remote backend guide to secure and verify that connection.

When a remote Bot disappears or the roster looks incomplete, check the connection and target backend before changing memory or recreating the profile. Confirm the backend is current, the profile exists there, and Desktop is connected to the intended machine.

Bot Mode does not provide cloud computers#

Bot Mode organizes agents; it does not supply an always-on computer. If a Bot lives on a laptop, its tools and Routines stop when that laptop sleeps or powers off. If it lives on a VPS or another always-on machine, you still own that machine's updates, provider credentials, backups, security, logs, and recovery.

That boundary leads to a simple choice:

• Use self-hosted Bot Mode when you want specialist profiles and full control of the runtime.
• Use the self-hosted versus hosted AI agent comparison when uptime and operating burden are the real decision.
• Use FlyHermes when you want a managed cloud Hermes workspace with browser/mobile access and connected channels instead of maintaining the runtime yourself.

Troubleshooting Hermes Bot Mode#

The Bots pane does not load after an update#

Update Hermes Desktop and the backend together, then confirm the gateway/backend is reachable and the profile list loads outside Bot Mode. Recent roster-loading fixes require current builds on both sides. Do not delete profiles to repair a UI inventory problem.

A remote Bot is missing#

Open Desktop Connections, identify the backend that owns the profile, and verify that exact backend independently. A remote status probe can pass while a live chat or profile inventory still fails because authentication or the WebSocket path is different.

A Routine cannot be opened or looks stale#

Check hermes cron list under the Bot's owning profile and inspect cron history. The Desktop pane is a view over the scheduler, not a separate job store. Update first if the row is not clickable or the panel repeatedly redraws.

Browser links open in Sessions instead of Bots#

Update Hermes Desktop. Current Bot Mode routes browser activity back to the owning Bot; older builds had Session-only routing behavior. Then run one real browser task and verify the artifact belongs to the expected profile.

A Bot loops or ignores its role#

Separate context problems from model tool-selection problems. Compress the canonical chat, inspect SOUL.md and enabled capabilities, then test the same small task with another supported model before deleting memory. The memory and context troubleshooting guide explains that decision tree.