Hermes Bot Mode Turns Profiles Into Named Teammates

Nous Research has bundled Bot Mode into Hermes Desktop, turning separate agent profiles into a roster of named bots with their own conversations and operating context. The feature is now described as default-on in the desktop app and landed with Hermes Agent v0.20.3, according to the source report. For operators, the important change is not another model: it is a clearer way to organise several specialised Hermes identities on one machine.

Definition: Hermes Bot Mode is a desktop roster for independent Hermes profiles, presented as named bots with separate identity, memory, skills, credentials, and chat history.

Example: A research bot can scout sources, a writing bot can draft, and a reviewer bot can fact-check while each keeps its own profile context.

Key takeaway: Bot Mode adds a teammate-style interface and message handoffs on top of Hermes profiles rather than creating a separate agent runtime.

Business impact: Small teams can divide recurring research, writing, review, and operations work across named bots, but they still need to supply their own access controls and governance.

What changed in Hermes Bot Mode?

Hermes Bot Mode changes the unit a user sees in the desktop interface: instead of a flat list of sessions belonging to one agent identity, the interface shows named bots. Each bot is still a real Hermes profile under ~/.hermes/profiles/<name>/, with isolated configuration, memory, skills, credentials, and chat history. That architecture means a user can organise specialists without learning a second persistence system, while a profile remains the boundary for context-sensitive state.

A bot therefore represents more than a label or avatar. Hermes Bot Mode lets a user create or edit a profile with a name, title, description, model and persona file, and can clone an existing profile's configuration, skills, memory and appearance. For a business operator, the practical takeaway is to assign a bot a narrow role and explicit access rather than treating the roster as a collection of interchangeable chat tabs.

Hermes Bot Mode also keeps model choice close to the bot. The source describes per-bot provider and model pinning, so a research bot can use a reasoning-oriented model while a routine drafting bot uses a cheaper option. That separation applies when the profile is configured; it does not guarantee that any model is automatically better for a role. Operators should document why a bot has a model, skill set and tool access before attaching it to scheduled or external work. See also Grok Bot turns AI teammates into 24/7 operators.

How do Hermes bots hand work to one another?

Hermes Bot Mode uses persistent Agent Inbox conversations for bot-to-bot work, and each handoff is a real CLI invocation rather than an in-process function call. An @mention in a bot's chat can route a request to another profile, which reads the attributed message in its own inbox and returns a reply through the active bot. The result is a traceable profile-to-profile exchange, but the receiving bot sees the message on its next invocation rather than interrupting a conversation already in progress.

A typical handoff chain separates roles without pretending that the bots share one mind: a scout gathers material, a writer turns it into a draft, and a reviewer checks the result. Hermes Bot Mode makes that chain visible in the roster, while the profile boundary keeps each bot's memory, credentials and skills from silently merging. Operators should pass only the context required for the next role and keep privileged tools away from bots that only need to read or review.

The handoff protocol is documented in the archived Hermes-Bot-Mode repository, which also records the desktop-plugin design and the limitation that delivery is per invocation. That detail matters for workflow design: a bot chain is a sequence of bounded runs, not a continuously shared conversation or a live interrupt mechanism.

What can each bot configure?

Hermes Bot Mode gives each named bot a profile-level configuration surface, including a custom SOUL.md, enabled skills, toolsets, provider, model and appearance. The feature also supports routines backed by ordinary Hermes cron jobs, namespaced with the bot name while remaining visible through the normal cron listing. A scheduled research sweep or report can therefore belong to a specific bot without requiring a new scheduler.

Avatars are part of the roster's identification layer rather than proof of capability. Hermes Bot Mode offers geometric faces, colours, uploaded images, generated portraits and pixel pets, while the eyes can show activity as a bot works. The useful operational rule is to make the name, description and permissions carry the role; the avatar should help a human scan the roster, not substitute for a documented boundary.

Profiles are not complete multi-tenant security by themselves. Hermes's existing profile model isolates configuration and state paths, but users still control the host, filesystem, gateway and credentials around those profiles. A public channel, shared workstation or unrestricted shell can weaken the separation, so a production-minded setup should pair named bots with allowlists, approvals, sandboxing and narrowly scoped tools.

What did the bundled release add?

The standalone Bot Mode beta moved into the main Hermes desktop application, and pull request #87886 describes the bundled plugin as default-on with a core teammate protocol. The same change also describes a multi-source roster that can merge profiles from registered desktop connections. For users, the transition reduces installation friction: Bot Mode becomes a desktop capability to enable or disable in Settings rather than a separate repository to maintain.

The bundled version adds groups and group rooms alongside the individual roster. Groups organise bots into labelled sections that can sync across machines, while a room can include two to six bots and run up to three serial rounds of member turns. Mentioned bots respond; if a message names nobody, every member can respond; and a bot can pass rather than forcing another contribution. Those bounds make group discussion more predictable than an unlimited fan-out, but they do not remove the need for a human to review consequential output.

For readers new to the category, Yowox's AI agent explainer covers the broader distinction between a tool-using agent and a conventional chatbot. For a Hermes-specific overview of providers, memory, skills, messaging and execution, see Hermes Agent explained. Bot Mode is best understood as a new operating surface for those existing capabilities: it gives the operator several named identities, while Hermes remains the runtime underneath.

Is Bot Mode deployable for a business?

Hermes Bot Mode is deployable today on a desktop at no license cost under MIT-licensed projects, making it immediately relevant to solo builders, startups and small-to-mid engineering teams. The source positions it for software engineering, AI research, technical media, developer relations, quantitative research and IT operations, with examples such as scheduled inbox digests, project-specific agents and scout-to-reviewer handoffs. The sensible first step is a low-risk workflow with clear inputs, outputs and approval points.

Hermes Bot Mode is not described as managed enterprise infrastructure: the source explicitly notes the absence of an admin console, SSO, central audit log and policy layer. That boundary is material for regulated or large organisations, because the desktop feature does not provide central governance by itself. Teams that need those controls should treat Bot Mode as a workstation component and add their own identity, logging, network, secret-management and review layers before expanding access.

The rollout signals a shift from one general-purpose Hermes session toward a roster of persistent specialists. That shift is useful when role separation reduces context leakage and makes recurring work easier to find, but it also creates more profiles to maintain. The practical test is simple: give each bot one clear responsibility, one justified model and one bounded toolset; if the roster cannot make ownership clearer, the extra identities are only interface complexity.