[Bug] Continuable subagent reports can arrive after newer settlement output and trigger stale parent turns

[TTTPOB]

Summary

A continuable child can send a subagent-report, continue working, and later finish with a newer closing message. When its parent is busy, DSH can deliver these messages to the parent in the opposite order:

1. The child sends an earlier report.
2. DSH queues the report in the parent's next-turn inbox.
3. The child continues working and finishes with updated output.
4. DSH steers the settlement notice, including the updated closing message, into the parent's next-step inbox.
5. The parent consumes the settlement notice during its current turn and acts on the updated result.
6. After that turn ends, DSH consumes the older report from next-turn and starts another model turn for it.

The parent therefore sees a child's final result before an earlier report. The delayed report may be stale or contradict the result the parent already processed.

With several children, every queued report can also start a separate follow-up turn.

Reproduction

1. Start a continuable subagent while its parent is running a tool-heavy turn.
2. Have the child call report with an intermediate conclusion.
3. Let the child continue working and produce a different final assistant message.
4. Allow the child to settle while the parent is still busy.
5. Inspect the parent's session log and model-visible conversation.

The behavior does not require process restarts, cancellation, HMR, or a race involving an unavailable parent.

Observed example

A real DSH session had one L1 subagent start three L2 subagents.

The L1 session received:

• four unique subagent-report messages in next-turn
• four subagent-settled notices in next-step

One child sent an initial blocker report. After the parent challenged that finding, the child sent a second report retracting it and then finished with the retraction as its closing message.

Another child sent a report whose opening sentence said that release was blocked, although the evidence later in the same report supported release. It then finished the same turn with a closing message that explicitly said the release could proceed.

The L1 parent consumed the settlement closing messages during its original turn and produced a final GO conclusion. It then entered four additional turns, one for each previously queued report:

Parent turn	Newly claimed input
2	First child's earlier report
3	Second child's original blocker report
4	Third child's contradictory earlier report
5	Second child's retraction report

The parent had already processed the corresponding closing messages before these four turns.

The Web UI accurately showed four Context injection · subagent-report rows and four Context injection · subagent-settled rows. This was not a UI duplication or duplicate session-log insertion: each report had one stable message ID, one inbox insertion, and one later claim. The problem was cross-inbox delivery order.

Why this happens

The report tool explicitly permits continued work:

https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/subagent/tool-subagent-report/src/index.ts#L57-L61

reporting never ends your turn

For reportDelivery: "wakeup", report delivery uses parent.followup(message), which queues the message for next-turn:

https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/subagent/subagent/src/continuation.ts#L629-L650

https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/subagent/subagent/src/continuation.ts#L677-L686

Settlement delivery behaves differently. If the parent is busy, it calls parent.steer(message), which queues the settlement notice for next-step:

https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/subagent/subagent/src/continuation.ts#L1400-L1442

Inbox.claim() consumes all pending next-step messages, but only one next-turn message when opening a turn:

https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/core/agent/src/inbox.ts#L68-L77

These rules allow a later settlement message to overtake an earlier report from the same child. Multiple reports left in next-turn then create multiple additional turns.

Actual behavior

• A newer settlement closing message can become model-visible before an earlier report from the same child.
• The parent can receive stale or contradictory information after it already processed the final result.
• Each delayed report can wake a separate model turn.
• The transcript presents report and settlement as independent context messages without indicating that the earlier report has been superseded.

Expected behavior

Model-visible delivery should preserve causal order for messages from one child.

At minimum:

• a settlement notice must not overtake reports that the same child sent earlier;
• an earlier report should not wake the parent after the parent has already processed a newer settlement result from that child;
• durable logs and the Web UI should retain the distinct report and settlement events without causing stale reports to become fresh model instructions.

The report and settlement contents cannot be deduplicated by text. A child may legitimately send an interim report and later finish with a different result.

Possible directions

Any fix should preserve report durability and child-to-parent authority while preventing cross-inbox reordering. Potential approaches include:

• steer wakeup reports into next-step when the parent is already running, matching busy-parent settlement delivery;
• serialize report and settlement delivery per child through one ordered parent queue;
• mark or suppress queued reports that a later settlement has superseded, while keeping their durable history visible;
• batch already queued reports rather than starting one turn per message.

The first requirement is ordering. Batching is a related cost issue but does not by itself prevent stale conclusions.

Acceptance criteria

• Reports and settlement output from one child reach the parent model in emission order.
• A child settlement cannot overtake that child's already accepted reports.
• A report accepted before settlement does not start a stale parent turn after the settlement has already been processed.
• Multiple children settling while a parent is busy do not regress the existing one-step settlement batching behavior.
• Session history and the Web UI still show each accepted report and settlement exactly once.
• Tests cover a child that reports conclusion A, continues working, and finishes with conclusion B while the parent is busy.

[TTTPOB]

Follow-up: a steer delivery mode may provide the smallest ordered fix

The existing Agent API already has a delivery primitive that appears to satisfy both requirements:

followup(message) // next-turn + wake
steer(message)    // next-step + wake
inject(message)   // next-step + no wake

The current report configuration exposes only two combinations:

• reportDelivery: "wakeup" calls parent.followup(message)
• reportDelivery: "quiet" calls parent.inject(message)

A third mode could use parent.steer(message):

type SubagentReportDelivery = 'quiet' | 'wakeup' | 'steer'

Why steer helps

If the parent is running, an earlier report and a later settlement both enter next-step, preserving insertion order and allowing the current turn to process them together.

If the parent is idle, steer() wakes it. The report is already in next-step; if settlement arrives immediately afterward, it either joins next-step behind the report or enters next-turn. Inbox.claim('next-turn') consumes all next-step messages before one next-turn message, so the report still precedes settlement.

This gives the useful properties of both current modes:

Delivery	Wakes an idle parent	Preserves report-before-settlement order	Avoids one later turn per queued report
wakeup / followup()	Yes	No	No
quiet / inject()	No	Yes	Yes
proposed steer / steer()	Yes	Yes	Yes

Adding a mode is safer than silently changing the existing wakeup semantics because deployments may rely on reports opening ordinary later turns.

A focused regression test could keep the parent busy, deliver report A, settle the child with closing output B, and assert that the parent's next model-visible boundary contains A before B without opening a stale later turn for A.