hermes - 💡(How to fix) Fix Feature request: active session awareness and inter-session coordination [1 participants]

Feature Description

Hermes should be aware of other active Hermes sessions running under the same user/profile/fleet and be able to coordinate with them intentionally.

Concretely: a Hermes session should be able to discover active sibling sessions, ask "what are you doing?", receive a concise status/handoff answer, and synchronize work so multiple Hermes agents do not duplicate effort or step on each other's files, terminals, crons, gateway conversations, or external side effects.

Motivation

Hermes already supports multiple execution contexts: CLI sessions, gateway sessions, cron jobs, spawned Hermes processes, profiles, worktree mode, delegated subagents, and Kanban workers. In practice, users can have several Hermes agents alive at once:

• a CLI agent implementing something locally
• a gateway agent responding to Telegram/Discord
• a cron agent running scheduled operations
• a spawned worker doing a long task in tmux
• Kanban workers touching related repos or systems

Right now those agents are mostly unaware of each other unless the user manually relays context. This creates avoidable problems:

• duplicate work on the same task
• conflicting edits in the same repo or worktree
• repeated external actions because one session cannot tell another already did them
• lost handoffs when a long-running session has important context but another session takes over
• difficulty answering "what are my active Hermes agents doing right now?"

The user experience should feel more like a small coordinated agent team than isolated terminals.

Proposed Solution

Add a local/session-scoped coordination layer, tentatively "Session Mesh".

1. Active session registry

Each running Hermes process periodically advertises a heartbeat to a shared registry, likely backed by Hermes state storage and scoped by Hermes home/profile.

Suggested fields:

• session id, profile, platform/source, model/provider
• process id / host / start time / last heartbeat
• current user-visible task summary
• current working directory / repo / git branch / worktree, when applicable
• active tools or long-running processes, when safe to expose
• claimed resources: repo paths, files, ports, cron jobs, external accounts, etc.
• status: idle, thinking, tool-running, blocked, waiting-for-user, done, errored
• privacy/safety flags for whether the session accepts queries or coordination messages

Stale sessions should expire automatically.

2. Inter-session query and messaging API

Expose internal tools and CLI commands for controlled communication:

• session_list_active() — show live sibling sessions with task summaries and claimed resources
• session_query(session_id, question) — ask a sibling session a bounded question such as "what are you doing?", "are you touching repo X?", or "summarize your last useful finding"
• session_send(session_id, message) — send a coordination message or handoff note
• session_broadcast(message, scope=...) — ask all relevant sessions for status before a risky action
• session_claim_resource(resource, reason) / session_release_resource(resource) — lightweight advisory locking for paths, ports, cron jobs, gateway conversations, etc.

The target session should answer through its own normal agent loop or a cheaper status responder, but with clear constraints: answer concisely, do not perform new external side effects unless explicitly asked by its own user/session, and do not leak private conversation contents outside the configured scope.

3. User-facing commands

Possible UX:

/sessions active
/sessions ask <session-id> what are you working on?
/sync
/handoff <session-id>

Example output:

Active Hermes sessions:
- cli:2026-05-19-abc123 — editing ~/project, branch feat/auth, status: running tests
- cron:finance-daily — last heartbeat 42s ago, status: importing transactions
- telegram:home — waiting for user, last task: summarized IBKR runtime status

Before potentially conflicting work, Hermes could proactively say:

I see another Hermes session currently editing this repo on branch feat/auth. I will ask it for status before making changes.

4. Synchronization behavior

The feature does not need hard distributed locking at first. Advisory coordination would already be valuable:

• warn before editing a repo/path claimed by another active session
• ask another session for a handoff summary before resuming related work
• avoid duplicate cron/gateway actions when another session has already completed them
• create explicit handoff notes in the session store
• integrate with Kanban task state where available

Safety and Privacy Requirements

• Scope discovery by Hermes home/profile by default; cross-profile visibility should be opt-in.
• Do not expose full transcripts by default. Prefer concise self-reported status and explicit handoff summaries.
• External side effects must remain governed by the active session's normal approval/safety rules.
• Avoid deadlocks and infinite agent-to-agent chatter. Enforce timeouts, message budgets, and cycle detection.
• Treat resource locks as advisory unless/until a robust locking model exists.
• Make the feature disableable in config.

Implementation Notes

Potential integration points:

• hermes_state.py / SessionDB for persistent registry and handoff records
• CLI slash command registry for /sessions, /sync, /handoff
• gateway status commands for remote visibility
• Kanban plugin/dispatcher for worker status and task ownership
• worktree mode and git metadata for repo conflict detection
• cron scheduler for reporting active scheduled runs

A minimal first version could be:

1. heartbeat table for live sessions
2. /sessions active command
3. a session_list_active tool
4. manual session_query that asks a target session for a short status/handoff response
5. advisory warnings when another live session claims the same cwd/repo

Alternatives Considered

• Relying on the user to manually relay context: simple, but brittle and exactly the current pain.
• Only using Kanban: useful for planned multi-agent work, but does not cover ad-hoc CLI/gateway/cron sessions.
• Reading raw transcripts directly: powerful, but worse for privacy and can confuse stale context with live intent. A live status/handoff protocol is safer.

Acceptance Criteria

• Hermes can list active sibling sessions with last heartbeat, source/platform, current status, and safe task summary.
• A session can ask another active session what it is doing and receive a bounded response.
• Sessions can publish and clear advisory resource claims.
• Hermes warns before starting work in a repo/path currently claimed by another active session.
• Stale/dead sessions are pruned or clearly marked stale.
• The feature is covered by tests for registry heartbeat, stale expiry, query timeouts, and config scoping.