hermes - 💡(How to fix) Fix Feature request: auto-resume prior task after handling an interrupt — agent yields cleanly but doesn't consistently pick up where it left off

Summary

Hermes already does the interrupt half well — when an operator message arrives mid-task, the agent emits ⚡ Interrupting current task (N min elapsed, iteration N/180). I'll respond to your message shortly. and yields to handle the operator's input. That part works.

The gap is the resume half: after the agent finishes handling the operator's interruption, the prior task is inconsistently picked back up. Sometimes it resumes, sometimes it doesn't, sometimes the operator has to remind it. Operator's verbatim characterization (2026-05-10):

"It'll be working on a task or two, and I'll interrupt, and it'll be good at addressing my interruption and handling that task. But when it's done with handling the interruption, it doesn't consistently remember to resume the previous work it was doing prior to the interruption, or go back to the queued todo's / tasks."

Why this matters

With no auto-resume, every interruption potentially loses work. If the operator interrupts an 8-step build at step 4, after handling the interruption the agent may simply not return to step 5. The operator then has to remember what was in flight and manually nudge "hey, continue the X you were doing." Trust in the agent's autonomy degrades quickly.

With auto-resume, the operator can interrupt freely without worrying about losing context. Interrupts become cheap; the agent treats them as side-quests and returns to the main thread.

What we'd like

1. Before yielding to an interrupt, persist a one-line continuation note: what task, what step, what next action. Write it to ACTIVE_WORK.md or an equivalent durable scratchpad, not just in-memory.
2. After finishing the operator's interrupt-response turn, on the next turn, automatically resume from the saved continuation note. Default behavior — no permission asked.
3. Auto-resume is silent unless enough time has passed that the operator may have forgotten the context, in which case a one-line "resuming X" prefix is appropriate.
4. If the operator's new message explicitly redirected ("stop doing X, do Y instead"), drop the prior task rather than resuming it. Heuristic: if the new message contradicts the prior plan, redirect; otherwise resume.

This can probably be a small addition to the existing run loop: after every turn that consumed a user-initiated interruption, check the persisted continuation note and if present, automatically construct the next-turn input to be "continue: <saved note>" rather than waiting for another user message.

Cross-reference

The sibling failure in OpenClaw is filed at openclaw/openclaw#80509 — OpenClaw is missing the interrupt half (it ignores user messages while in tool loops), Hermes is missing the resume half. Both halves matter to make the interrupt-then-resume pattern feel reliable end-to-end.

Operator-side workaround applied tonight: rewrote /root/.hermes/SOP.md General Task Discipline section to explicitly include both yield-on-interrupt AND auto-resume-after as rules. This is a prompt-level mitigation; the runtime mechanism (saving a continuation note on yield, replaying it on next turn after the interrupt response completes) is what's missing.

Environment

• Hermes Agent v0.10.0 (2026.4.16)
• WSL Ubuntu / Windows 10
• Channels affected: Telegram direct, webchat (likely all channels — the gap is in the agent's turn-management, not channel-specific)