Hermes Agent
Hermes traces routed-profile history loss to workspace identity
A Hermes report says multiplexed profile routing can present history=0 on every turn. Two Desktop changes around stable Bot Mode workspaces and chat wake-up behavior point to workspace identity as the seam between routing and conversation continuity.
NousResearch/hermes-agent issue #90410 is the inspected primary source: “Multiplexed gateway: routed profile via profile_routes loses conversation history every turn (history=0).” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- NousResearch/hermes-agent issue #90410 was created 2026-08-20T01:10:13Z and was open at inspection; its title is “Multiplexed gateway: routed profile via profile_routes loses conversation history every turn (history=0).” - NousResearch/hermes-agent PR #90398 was created 2026-08-20T00:48:23Z and was open at inspection; its title is “fix(desktop): keep Bot Mode group chats in one workspace.” - NousResearch/hermes-agent PR #90405 was created 2026-08-20T00:58:16Z and was closed at inspection; its title is “fix(desktop): opening a Bot Chat wakes reliably instead of hanging, stranding, or emptying Sessions.” - The repository reported 233069 stars, 33645 open issues, default branch main, and last push 2026-08-20T01:17:27Z. - The latest tagged-release baseline checked was v2026.8.18 published 2026-08-18T07:26:46Z.
What changed
NousResearch/hermes-agent issue #90410 reports: Bug Description When gateway.multiplex_profiles: true is set and gateway.profile_routes routes a chat (e.g. one Signal/Telegram/etc. sender sharing a single adapter credential with other contacts) to a non-default profile, the routed profile's conversation loses memory on every turn: the agent always sees history=0 in agent.log, even after dozens of real prior turns have already been exchanged. This makes multi-turn conversation impossible for any profile reached via profile_routes on a shared adapter. Root Cause gateway/run.py's _handle_message calls _handle_message_with_agent(...) directly, with no _profile_runtime_scope wrapper. Inside _handle_message_with_agent, self.async_session_store.get_or_create_session(...) and self.async_session_store.load_transcript(...) therefore resolve get_hermes_home() against whatever profile scope is currently active for the *adapter* (the default/primary profile for a shared credential), not the profile that profile_routes matched for this specific chat. Only much later, inside _run_agent_with_profile_scope (~line 27636), does the code correctly enter _profile_runtime_scope(self._resolve_profile_home_for_source(source)) before running the actual agent turn. Net effect: the turn's session row and transcript get written to profiles/ /state.db (because the *agent run* is correctly scoped), but the *next* turn's history load reads from the *default* profile's state.db — which never received those writes. Every turn therefore starts from an empty transcript regardless of how long the conversation actually is. Steps to Reproduce 1. Enable multiplexing and add a profile_routes entry that routes one chat (matched by chat_id) on a shared-credential platform adapter (e.g. Signal) to a secondary profile: 2. Restart
NousResearch/hermes-agent PR #90398 reports: What does this PR do? Prevents Bot Mode group chats from rendering in both the narrow Bots pane and the main workspace after a group row is selected. The selected-group state now records the main workspace before notifying the pane, and the pane renders its compatibility fallback only when no main group-chat tab exists. Desktops without host.openWorkspace, or hosts where that call fails, still use the existing in-pane room. Related Issue Discord report: https://discord.com/channels/1053877538025386074/1539779952776318976 Type of Change [x] Bug fix (non-breaking change that fixes an issue) [ ] New feature (non-breaking change that adds functionality) [ ] Security fix [ ] Documentation update [ ] Tests (adding or improving test coverage) [ ] Refactor (no behavior change) [ ] New skill (bundled or hub) Changes Made Gate the legacy Bots-pane group room on the absence of a registered main workspace tab in apps/desktop/src/plugins/hermes-bots/plugin.js. Register the main workspace before publishing the selected group, avoiding a transient duplicate render. Add behavioral coverage for modern, missing, and failed openWorkspace hosts in apps/desktop/src/plugins/hermes-bots/tests/group-chat.test.mjs. How to Test 1. Open Desktop Bot Mode and select a group chat. 2. Confirm the group chat appears in the main workspace while the narrow Bots pane keeps the roster visible. 3. Run the group-chat tests and confirm older hosts without a working openWorkspace capability still render the room in
NousResearch/hermes-agent PR #90405 reports: Opening a Bot from the roster had three separate ways to fail, and they all live in the same function — host.openSession. Three contributors each fixed one phase; every pair conflicts with every other pair in the same ~15 lines, so this lands them together rather than resolving the same merge three times. The wake never settled.** ensureGatewayProfile awaits a dial that HermesGateway.connect() never bounds, and the hydration timer is armed downstream of that await. A backend that accepts the socket and never finishes the handshake left the pane frozen with no error, no Retry, and no timeout — a bug that hangs past its own deadline. Activation now gets its own copy of the wake budget. A cold backend that lost the race got stranded.** On a hydration timeout openSession arms $resumeExhaustedSessionId before rethrowing, which latches the full-screen "Couldn't load this session" overlay until the user clicks Retry — and Retry usually worked, because the backend was warm by then. The timeout is now retried once internally, before the latch is ever armed. Opening a bot emptied the Sessions list.** The open was treated as a workspace switch, scoping chrome REST onto the bot profile whose forever-chat is hidden — so the sidebar looked empty and the roster vanished. A plugin open is navigation now: dial the bot backend
Why it matters
Profile routing is useful only if the routed workspace remains the same conversation. Losing that identity each turn converts a multi-tenant gateway into a stateless prompt relay. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-20. The tagged-release baseline was v2026.8.18 published 2026-08-18T07:26:46Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/NousResearch/hermes-agent/issues/90410. Supporting records are https://github.com/NousResearch/hermes-agent/pull/90398 and https://github.com/NousResearch/hermes-agent/pull/90405. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Bind routed profile, workspace and conversation identifiers in one durable mapping, then test continuity through gateway and Desktop restart paths. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.