Problem or Use Case
I run multiple persistent Hermes sessions that hold specialized context (one for research, one for builds, one as a personal assistant, each with its own SOUL.md, memories and skills). Today there is no way for these agents to address each other. session_search is read-only, and delegate_task spawns ephemeral subagents that cannot hold persistent state or be re-engaged later. The human is forced to act as a manual relay, copying analysis from session A into session B every time — which defeats the point of having specialized persistent agents.
Proposed Solution
Add a first-class way for one session to send a message to another session and receive its reply, e.g.:
- A
send_to_session tool: send_to_session(session_id="20260801_110135_3a75b0", message="...") — the target session's agent processes the message in its own full context (memories, skills, persona) and returns its reply to the caller
- A gateway-injected
@session:default/<id> mention syntax in prompts, same semantics
- Safety: a config allowlist (
agent.session_messaging.allow) so sessions can only message sessions the user permits; deny by default
This turns N isolated assistants into one persistent multi-agent team with division of labor — the missing primitive for agent-team workflows.
Alternatives Considered
delegate_task (exists) — subagents are ephemeral, share no persistent memory, can't be re-engaged; not a substitutesession_search (exists) — read-only archive access; the target agent never processes anything or replies- Do it manually (current state) — human as relay; works for 2 sessions, collapses for N
- A skill wrapping
session_search — can read history but cannot trigger the target agent to act; needs harness-level session routing and an active agent loop on the target side, which is exactly what skills cannot do
Related but distinct
Environment
Hermes v2026.8.x, Windows 10, weixin gateway
Problem or Use Case
I run multiple persistent Hermes sessions that hold specialized context (one for research, one for builds, one as a personal assistant, each with its own SOUL.md, memories and skills). Today there is no way for these agents to address each other.
session_searchis read-only, anddelegate_taskspawns ephemeral subagents that cannot hold persistent state or be re-engaged later. The human is forced to act as a manual relay, copying analysis from session A into session B every time — which defeats the point of having specialized persistent agents.Proposed Solution
Add a first-class way for one session to send a message to another session and receive its reply, e.g.:
send_to_sessiontool:send_to_session(session_id="20260801_110135_3a75b0", message="...")— the target session's agent processes the message in its own full context (memories, skills, persona) and returns its reply to the caller@session:default/<id>mention syntax in prompts, same semanticsagent.session_messaging.allow) so sessions can only message sessions the user permits; deny by defaultThis turns N isolated assistants into one persistent multi-agent team with division of labor — the missing primitive for agent-team workflows.
Alternatives Considered
delegate_task(exists) — subagents are ephemeral, share no persistent memory, can't be re-engaged; not a substitutesession_search(exists) — read-only archive access; the target agent never processes anything or repliessession_search— can read history but cannot trigger the target agent to act; needs harness-level session routing and an active agent loop on the target side, which is exactly what skills cannot doRelated but distinct
Environment
Hermes v2026.8.x, Windows 10, weixin gateway