Background Subagents Now Report Back: Streaming Wait Mechanism Upgraded

Recently, news about an update to the Background Subagents mechanism has sparked discussion in the developer community. The core change: subagents are no longer "fire and forget"—instead, upon completion they return their results to the parent agent as a follow-up turn within the same run. This means that stream() and wait() calls can span the entire subagent lifecycle until all subagents have finished.

From "Fire and Forget" to Closed-Loop Reporting

In multi-agent systems, parent agents often dispatch subagents to handle subtasks in parallel—such as retrieval, code generation, and data validation. In the past, collecting results from these background subagents often relied on polling or independent callbacks, and the parent agent's streaming output might close before subagents completed, causing lost results or requiring extra state management.

The new mechanism binds subagent results as follow-up turns of the same run. When the parent agent calls stream(), the stream does not terminate immediately after the parent's own output ends; instead, it continues waiting for subagent reports. wait() similarly blocks until all subagents complete. For scenarios requiring aggregation of multiple result streams, this reduces the complexity of manual orchestration.

Subagent is a division-of-labor pattern in multi-agent architectures: a controlling agent (parent agent) delegates divisible subtasks to several controlled agent instances, each carrying independent context to execute, then aggregates results back to the parent. This structure is common in retrieval-augmented, code generation, and multi-step validation pipelines.

Early implementations mostly adopted "fire-and-forget" semantics: the parent agent only dispatched, and subagent results were collected via polling, callbacks, or independent session channels—there was no shared execution trace between parent and child. The cost was that the parent agent had to maintain its own task state table, completion counters, and result aggregation logic; if the streaming connection closed early, results not yet returned could be lost. The new mechanism incorporates subagents into the parent agent's same run, essentially replacing application-layer manual orchestration with runtime state management.

Technical Details: Follow-up Turns of the Same Run

The phrase "follow-up turn of the same run" deserves unpacking. It means subagent results are not injected as independent sessions but treated as a continuation of the parent agent's execution trace. The benefit is contextual continuity: in subsequent turns, the parent agent can directly continue reasoning based on content returned by subagents without re-establishing state.

This also imposes requirements on the runtime—the scheduler needs to track each subagent's completion status and insert turns on the streaming channel in order or by completion order. For concurrent subagents, result return order may differ from dispatch order, and developers need to consider whether their aggregation logic is order-sensitive.

run and turn are two-level concepts in agent runtimes. A run represents the complete lifecycle from a user request to the final answer, which may contain multiple turns: each turn is a cycle of "model inference—tool call—result backfill." Inserting subagent results as follow-up turns of the same run means it reuses the parent agent's existing message history and tool call trace rather than starting a new session.

In contrast, if results were injected as independent sessions, the parent agent would need to re-declare task context in the context, and the two sets of state could easily become inconsistent. Note that inserting turns within the same run requires the streaming channel to support ordered concatenation of multi-segment output; schedulers typically write in completion order rather than dispatch order, so aggregation logic that assumes "first dispatched, first returned" may fail.

Practical Impact on Developers

The most direct change is the semantic extension of the streaming interface. Previously, the end of stream() was often understood as "this round of tasks is done"; now it needs to be understood as "this run and all its subagents are done." When building frontend real-time displays or logging systems, this difference affects loading state determination.

Second, wait() blocking time may become longer. If there are time-consuming tasks among subagents, the parent agent's waiting period will extend accordingly. Timeout settings and cancellation mechanism designs need re-evaluation to avoid the entire process being dragged down by a single stuck subagent.

Termination semantics of streaming interfaces have changed here. The end signal of traditional stream() (such as stream closure or end marker) corresponds to "this generation is complete"; when subagents are incorporated into the same run, the actual meaning of that signal extends to "all pending tasks within this run have settled." If frontend loading states, progress bars, and log segmentation still use the old semantics, mismatches will occur where "the UI shows complete but results arrive afterward."

Correspondingly, wait() blocking semantics also change from "wait for the parent agent's current round output" to "wait for the entire subagent tree to settle." In practice, layered timeouts are usually needed: set independent time limits for individual subagents, a total time limit for the overall run, and provide cancellation propagation so that when the parent agent aborts, it can also terminate still-running subagents, preventing orphan tasks from consuming resources.

Questions Still to Be Observed

Current public information is relatively brief and has not yet clarified reporting behavior when subagents fail, result size limits, and whether nested subagents (subagents spawning further subagents) also apply this mechanism. These details will directly affect reliability design in production environments.

Overall, this update moves background subagents from "asynchronous bypass" toward "run closed-loop," a step toward more natural semantics for multi-agent orchestration.

One-line Summary

Background subagent results are returned as follow-up turns of the same run, changing streaming and blocking semantics accordingly.

Paragraph Summary

The article discusses an important update to the background subagent mechanism: subagents are no longer "fire and forget" but return results to the parent agent upon completion as follow-up turns of the same run. As a result, stream() and wait() span the entire subagent lifecycle, terminating only after all subagents finish. The article unpacks the meaning of "follow-up turn of the same run," noting its advantage in contextual continuity and reduced manual orchestration, but also requiring schedulers to track completion status and insert turns in order—concurrent scenarios may return in different order than dispatch. For developers, streaming interface end semantics extend to the entire run, wait() blocking time may increase, and timeout and cancellation mechanisms need re-evaluation. Subagent failure reporting, result size limits, and nested subagent behavior remain to be clarified.