hermes - 💡(How to fix) Fix delegate_task interrupt semantics: subagent killed while work is already complete

Bug Description

When a parent conversation is interrupted (e.g. via /btw, /stop, or the user sending a new message), all child subagents spawned via delegate_task are immediately killed — even if they have already completed their substantive work and are only in the final summarization/response phase.

This creates a misleading user experience: the subagent may have executed 28 API calls, written files to disk, and performed all its meaningful work over 4+ minutes, but the parent sees status: "interrupted" with no summary and no indication that the work actually succeeded.

Steps to Reproduce

1. Parent spawns a delegate_task subagent with a long-running goal (e.g. API research involving many calls)
2. Subagent completes all work (writes files, makes network calls) and enters the final LLM response summarization step
3. Meanwhile, user starts a new conversation (e.g. /btw or sends a new message)
4. Parent conversation is interrupted
5. Result: subagent is killed with exit_reason: "interrupted" — even though all side-effect operations already succeeded

Actual Behavior

Subagent returns status: "interrupted" despite having completed all substantive work. The written artifact exists on disk, but the parent gets nothing back.

Expected Behavior

Option A: Allow in-flight subagents to drain — once a subagent has completed its task execution (tool calls + file writes), let it finish returning its summary even if the parent is interrupted.

Option B: Return accumulated side-effect info — include a flag like work_partially_complete: true with any available execution trace.

Option C: At minimum, document in delegate_task tool description that side effects may persist even on "interrupted" status.

Environment

• Hermes Agent (latest, running via terminal)
• deepseek-v4-flash model
• Parent interrupted via /btw

Additional Context

Discovered in practice: a subagent researching AI agent frameworks performed 28 API calls over 256 seconds, wrote a complete report to disk, and was killed during the final LLM response summarization step. The report existed on disk and was usable. The parent saw only "interrupted".