MultiAgentV2: expose delivery and acknowledgement state for parent-to-child messages #37744

Problem

When a parent agent calls send_message or another steering operation, a successful tool result only confirms that the runtime accepted the request. It does not show whether the child:

• received or queued the message;
• consumed it in the current or next turn;
• applied or rejected the steering;
• was already terminal;
• had the message superseded by a later update.

This makes coordination ambiguous and encourages duplicate steering, repeated followup_task calls, and excessive polling.

Observed on Codex Desktop 26.803.41515 with bundled CLI 0.146.0 on macOS.

Proposed behavior

Return a durable message ID and expose its lifecycle, for example:

{
  "messageId": "...",
  "targetThreadId": "...",
  "targetTurnId": "...",
  "deliveryMode": "current_turn",
  "state": "queued",
  "reasonCode": null
}

Possible states could include:

accepted, queued, consumed, applied, rejected, superseded, and unknown.

applied should only be reported after an explicit child/runtime acknowledgement. A completed send_message call must not be treated as proof that the steering was applied.

Retries should also be idempotent by message ID or client-provided ID.

Related issues

• #33885 requests direct steering of child threads.
• #32756 reports queue-only messages leaving a child live but unscheduled.
• #29886 reports delivery succeeding while the caller receives a handler error.
• #32254 covers idempotent turn/steer retries.
• #32353 covers pending mailbox messages pinning terminal agent residency.

Those issues cover steering entry points, scheduling, retries, or residency. This request is specifically for an observable end-to-end lifecycle from parent submission to child acknowledgement.