GitHub Repo
Hermes Agent 0.21.5 Adds Per-Profile Start and Stop Controls for Partial Shared-Gateway Maintenance
The release lets admins independently stop and start a selected agent on a shared gateway, with a persistent marker to retain its disabled state. Already-dispatched scheduled jobs continue running, and compatibility should be checked for older multi-process deployments.
Nous Research released Hermes Agent 0.21.5 on September 24, tagged `v2026.9.24`. The release adds stop, start, and restart operations for individual profiles within a shared gateway, allowing administrators to maintain one agent while the same process continues serving other profiles. This is a consolidated release for container images and hosted deployments; the full categorized breakdown is expected with 0.22.0. [Release notes](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.24)
Hermes profiles can separately host research, writing, or coding agents, each with its own memory and messaging-platform credentials. A shared gateway centralizes their message entry points in one process. From an operations perspective, this update allows centralized management and maintenance of individual profiles to coexist, making it suitable for deployments running multiple low-traffic bots on the same host. [Official architecture documentation](https://hermes-agent.nousresearch.com/docs/user-guide/multi-profile-gateways)
The CLI implementation in the release tag first attempts to handle profile-specific lifecycle operations, then determines whether to enter the system service management flow. This order connects per-profile controls to existing commands, and means deployment scripts must distinguish between shared and standalone processes instead of assuming the scope from the command name alone. [Version source code](https://raw.githubusercontent.com/NousResearch/hermes-agent/v2026.9.24/hermes_cli/gateway.py)
When you run `hermes -p coder gateway stop`, the system first writes `gateway.parked` to that profile's directory, then asks the main process to disable its messaging interfaces and exclude its associated jobs from subsequent scheduler polling. The disabled state persists across restarts of the main process, while existing conversations and schedule definitions remain. Starting the profile removes the marker; restarting it reloads the configuration and rebuilds that profile's connections. [Version documentation](https://github.com/NousResearch/hermes-agent/blob/v2026.9.24/website/docs/user-guide/multi-profile-gateways.md)
These operations have clear limits: jobs already dispatched by the scheduler are not terminated. If the control channel does not acknowledge a request, the CLI displays a warning. The main process rescans the marker every 30 seconds to apply the state, and closing interfaces or connections may take time. Starting or stopping the default profile still affects the entire main process, so disabling an individual profile should not be treated as an immediate cancellation of all running work. [Stop semantics and limitations](https://hermes-agent.nousresearch.com/docs/user-guide/multi-profile-gateways)
Upgrading also involves topology compatibility. The version documentation says that existing settings that disabled shared mode are rewritten to enable it, with a notification displayed. `gateway.standalone: true` lets a selected profile temporarily run in a separate process, but the project describes this as a transitional measure. WhatsApp bridging and dashboard scoping for secondary profiles remain listed gaps. Engineering teams should verify message handling after disablement, scheduled-job dispatch, and recovery after restart, then track the announcement about removing the transitional setting. [Compatibility notes](https://github.com/NousResearch/hermes-agent/blob/v2026.9.24/website/docs/user-guide/multi-profile-gateways.md)