TaskStop gives a subagent no chance to hand back partial work before it dies

TaskStop gives a subagent no chance to hand back partial work before it dies

What happens today. TaskStop kills a running subagent immediately. There is no signal sent
to the subagent first, no grace window, and no mechanism for it to persist whatever it had already
produced. The kill is recorded as status: "killed", "Agent ... was stopped by Claude" — clean and
correct as a kill, but total as a loss: nothing the subagent held in memory at that instant is
recoverable.

Measured impact (one incident). A parent session launched a batch of background subagents,
then discovered a real upstream data-quality bug partway through their runs — the input each one
was working from was malformed for most of the batch. The parent correctly used TaskStop to kill
every affected subagent rather than let them keep grinding on bad input, fixed the underlying bug,
and re-ran the batch correctly. That triage decision was the right call. But every one of the
killed subagents had already made real tool calls and spent real tokens (tens of millions of
tokens total, tens of thousands of them genuinely fresh model output, not cached context) before
being killed, and none of it was recoverable — not because the work was worthless, but because
TaskStop gives no opportunity to say "here is what I have so far" before the process ends.

Ask. A last-chance flush: before actually terminating a subagent, send it a bounded window (a
few seconds, or one final turn) to call its hand-back mechanism with whatever partial result it
already has, and surface that partial result to the caller alongside the "killed" status. This
would not change when or why an orchestrator decides to stop a subagent — it would just stop that
decision from also discarding paid-for, possibly-useful partial work by default. A deliberate
"kill and discard everything" mode could remain the default or an explicit flag if immediate
termination is sometimes the point (e.g. a runaway process).