[MultiAgentV2] Idle parent does not resume after child batch completion without polling

Summary

MultiAgentV2 can deliver a child completion into the parent mailbox without
starting a parent continuation turn. When the parent has no further model work
and is idle, the result is not consumed until the user sends another message or
the parent performs another status/read operation.

This issue focuses on the narrower runtime contract needed for a parent-owned
parallel work batch. It is related to, but more specific than, #15723: the
parent must retain final admission and delivery ownership while the runtime
provides one event-driven continuation after the batch is ready.

Reproduction / evidence

• Installed Codex runtime: 0.146.1.
• MultiAgentV2 parent spawns multiple children and then has no independent work.
• Child completion notifications are queued with trigger_turn=false.
• The parent remains idle and does not consume the result without a later turn.
• In a local smoke run, the parent path still became wait_agent -> wait_agent:

one child result woke the mailbox wait, but the first wait did not collect the
whole batch. No automatic parent continuation occurred after the parent had
become idle.

The current source shape is:

child reaches completion
  -> completion watcher queues parent mailbox message
  -> trigger_turn=false
  -> idle parent does not start a turn
  -> result is consumed only on a later parent turn

wait_agent also waits for mailbox activity, not for a declared set of child
agents, so using it as a wait-all barrier requires repeated model-mediated
coordination and can reprocess a large parent context.

Required contract

The desired behavior is not child-owned final delivery and not unconditional
wake-up for every child event:

1. The parent remains the only final admission, integration, and delivery owner.
2. After a parent explicitly starts a parallel child batch, runtime state tracks

that batch and its owning parent.

1. Child terminal results are delivered as bounded, durable, deduplicated

completion receipts.

1. Results for a batch are coalesced and cause at most one parent continuation

when the parent is idle.

1. The parent continuation receives all currently terminal child results in one

turn and decides admission; the runtime does not perform semantic admission.

1. Running children do not cause polling turns. A batch liveness deadline must

prevent an indefinitely stuck child from leaving the parent waiting forever.

1. Existing user-interrupt semantics must remain intact. In particular, the

design must not globally redefine Interrupted as an auto-restart trigger.
Error, interruption, timeout, shutdown, and missing-child outcomes should be
distinguishable to the parent.

Why the current wait guidance is insufficient

Longer or configurable wait_agent timeouts reduce call frequency but do not
provide a wait-all barrier, do not wake an idle parent, and still return control
to the model at each timeout boundary. This leaves both the liveness and token
cost problems unresolved.

Related reports and prior art

• #15723 — general background subprocess/subagent completion wake gap.
• #34468 and #35259 — repeated status/wait turns and measurable token waste.
• #35108 and #24951 — repeated parent boundaries and incomplete end-to-end wait

deadlines.

• #31178 and #16386 — parent workflow feels serial or does not resume after

interruption/reconnect.

• #9837 — prior event-driven subagent delegation proposal with batched parent

completion delivery; closed without merge.

• #18400 — prior parent-mailbox/trigger semantics proposal; closed draft.

Questions for maintainers

1. Is the intended direction to extend the existing completion watcher and

pending-work scheduler with an opt-in parent continuation barrier?

1. Should this be implemented as a runtime-owned batch receipt, or is there an

existing parent/child join primitive planned for MultiAgentV2?

1. What is the intended policy for naturally completed, errored, timed-out,

interrupted, and shutdown children when the parent is idle?

This report is intended to consolidate a precise current-runtime reproduction
and design boundary. It does not propose changing all completion notifications
to trigger_turn=true, which could conflict with existing interruption and
error-handling semantics.