Hermes Agent Community Investigates Missing Task Notifications After Reset; Background Processes May Be Marked Read

On October 12, the Hermes Agent community reported an issue with background task lifecycles: long-running work in Telegram stopped after its associated agent closed, but users received no actionable interruption notice. The reporter later confirmed from logs that the event followed the session-reset cleanup path. The logs could not distinguish whether it was triggered by /new, /reset, or another call to the same handler, so the process termination cannot be assumed to have been an unintended kill. Incident and follow-up investigation

Another participant ran a partial test using the real process registry and agent cleanup function from the then-current main branch. They found that kill_process uses consume_output=True, marking the terminated process’s completion result as consumed and causing the unread-completions list and notification gate to skip it. In a comparison, a process that ended on its own could still trigger a notification; changing the value to False also made the terminated process’s result eligible for notification again. However, the test did not drive the full Telegram flow or session database, and message ownership after a reset remains an open question. Community test

This bears directly on the background notification contract described in the official documentation: notify_on_complete=true should start a new agent turn after a process completes, allowing the agent to report the result; the standard notification mode can send a completion or failure status. In engineering terms, starting work, receiving the exit event, and delivering the result back to the conversation are three separate steps that need to be verified. Messaging gateway documentation

The official tools runtime documentation also explains that checkpoints for running processes are stored separately from completed output, and that reading results is subject to ownership by the original session or its compacted continuation. This means that handing work across conversations requires handling result ownership and notification routing, not just preserving the process identifier. Tools runtime documentation

For teams deploying long-running research or batch jobs, this case is a reminder that a running status written by the job itself is not enough to establish that the process is still alive. Next, watch for maintainers to add end-to-end tests covering interruption notifications during reset, delivery of results from continuing work, and recovery flows that avoid duplicate execution. At the time of review, the issue remained open pending a maintainer decision, with no linked fix PR. The available evidence supports further investigation; it does not establish that all deployments are affected. Issue status