Subagent turns frequently end with zero final text mid tool_use near turn end; deliverable writes lost (SendMessage resume recovers 100%)

Summary

Subagents (both Agent-tool dispatches and Workflow-tool agent() calls) frequently end their turn with zero final text while issuing a tool call near the end of a long, tool-heavy turn. The agent's transcript shows substantial completed work (20–30 tool calls), then the turn simply stops — no final assistant text, no error surfaced to the caller. The caller receives an empty result string.

This looks related to #38905 (stream abort can end an agent turn with no final text), but the failure signature here is narrower and highly reproducible: the cut lands disproportionately on the last tool_use of the turn — exactly where the agent's deliverable write happens.

Evidence (one orchestrated pipeline run, 2026-07-08, v2.1.204)

A single workflow run (nested Workflow orchestration, Opus agents, macOS 26.3.1) produced 7 empty-final-text agent turns:

• Two independent analysis agents (initial + its retry dispatch) died at the identical point: transcript ends with "Let me generate the report path and write the report" / "Let me compute the report path and write the report" — i.e., mid-issuing the Bash call that writes their report file. Both had done 26 and 22 tool calls of real work respectively (full test-suite runs, file reads).
• A test-writer agent died mid-investigation after 29 tool calls (last text mid-hypothesis, no deliverable).
• Four more agent turns in the same run returned empty results with work visible in their transcripts.

Two structurally identical deaths at the exact same "about to write the deliverable" step, in one run, plus five more empties, is a pattern we now see across weeks of daily use: in interactive sessions we have recovered stalled subagents with a SendMessage nudge ("emit your report now") 27 out of 27 times — the agent state is fully intact and it completes in one more turn. The turn ended; the model didn't fail.

Why this hurts

• In headless/workflow orchestration there is no human to nudge. Callers must build mirror-file fallbacks, bounded re-dispatches, and no-progress detection around every agent leg (we have; it works; it roughly doubles orchestration code).
• The deliverable-at-end-of-turn pattern (do work → write report → emit summary) is the natural agent shape, and it concentrates all loss at the cut point.

Repro characteristics

• Long tool-heavy turns (≥20 tool calls, several minutes) raise the probability sharply; we've also seen it on short turns with small inputs, so it is not purely a context/turn-size effect.
• Not model-specific in our observations (seen on Opus-class agents at multiple effort levels).
• The caller-visible symptom is an empty result string from the Agent/Workflow tool; the transcript file shows the turn ending immediately after (or while issuing) a tool_use, with no stop-reason surfaced.

Ask

1. Surface some terminal signal to the caller when a subagent turn ends without final text (stop reason / error code), so orchestrators can distinguish "cut" from "returned empty on purpose".
2. If the turn is being ended by an internal budget/stream condition while a tool_use is being issued, consider letting that tool call complete (or at least flushing pending text) before ending the turn — the current behavior maximizes work loss.
3. If there's a recommended caller-side pattern beyond "retry the whole leg", document it.

Happy to provide sanitized transcript excerpts (tool-call sequences + timings) on request.

Environment

• Claude Code v2.1.204, macOS 26.3.1 (arm64), Node v24.15.0
• Subagents dispatched via the Workflow tool (agent()) and the Agent tool; both affected
• Related: #38905 (stream aborts), #75247 (nested workflow rendering — same orchestration, different issue)