A new SubagentHandback tool lets a subagent deliver its final report directly to the agent that spawned it, with delivery tracked end to end
What
- A new tool,
SubagentHandback, lets a subagent send its final report straight to the agent (or main thread) that spawned it, as its one and only last tool call. It isn't a progress-update channel — it can only be called once, requires a non-empty message, and only works when the agent has an active "handback contract" with a recorded recipient. - Long reports are compacted or summarized before delivery, and get safety-review framing (blocked/refused/unavailable) attached.
- The subagent's completion result now carries a
handbackpayload (and ahandbackInterimvariant), and the finalize step computes whether the handback was sent, flagged, or withheld, appending a message to the result accordingly. - Async subagents can now explicitly hand control back to a specific owning agent (tracked as
handbackRecipient) rather than only running to completion or being polled. - For subagents running in "auto" mode, this mechanism is what actually counts as the final answer: plain trailing text is discarded unless delivered through
SubagentHandback. The feature is off by default, controlled by theCLAUDE_CODE_SENDMESSAGE_HANDBACKenvironment variable or an internal rollout gate. - Depending on the handback outcome (
send,flagged, orwithheld), the step that classifies a sub-agent's final output is skipped or has its text discarded, so results aren't double-processed.
Why This gives subagents a reliable, explicit way to report back to whatever spawned them, instead of relying on trailing text that might get lost, mis-parsed, or double-classified — useful for orchestration flows where a parent agent needs a clean, single final report from a subagent it dispatched.
tengu_lively_waffle Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.267: off
Read once, for one account on one subscription tier, against v2.1.267. It isn't a statement about your account. What a flag value here can and cannot tell you
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
The second filter applies to subagents running in the background. Apart from `Agent` and `ExitPlanMode`, which follow the first filter's conditions wherever the subagent runs, a background subagent keeps every MCP tool but only these built…sub-agents see the edit
| `content` | array | `[{"type": "text", "text": "Found 12 endpoints..."}]` | The subagent's final text blocks, or, for a subagent whose report goes through `SubagentHandback`, a short note about that hand-back in their place |hooks see the edit
A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Nothing has been read yet about whether the `tengu_lively_waffle` flag that controls this is on or off by default.
Anthropic's documentation has since written up SubagentHandback, on Hooks reference.
New in this build: tengu_lively_waffle