Messages sent during a teammate's busy-to-idle transition are never processed — same lossy-wake class as #79570, opposite direction, still ~100% reproducible
duplicate-checked 2026-08-04; nearest prior report is #79570 (subagent-to-dispatcher direction, closed COMPLETED). This report is the dispatcher-to-subagent direction, reproduced ~10/10 times on 2026-08-03/04 — after #79570's closure — suggesting the fix didn't cover this transition window or regressed.
In a session using named teammate agents (Agent tool with name:, follow-ups via SendMessage), a task message sent in the window where the recipient is transitioning to idle is accepted (success: true, msg_id returned) but the agent never acts on it. The agent's next event is an idle_notification; the message appears lost until the sender re-sends.
Observed over a ~24h orchestration session (2026-08-03, Claude Code CLI, macOS/iTerm2 backend):
- 10+ occurrences, effectively 100% reproduction when the dispatch raced a completion: every task message sent within a few seconds of the recipient finishing its previous task required a follow-up "receipt check" re-send before work started.
- Pattern: teammate posts its completion message → orchestrator immediately sends the next task → teammate emits
idle_notification(timestamped seconds after the send) → no ack, no work. A re-send after the idle notification is always processed. - Messages sent while the agent is actively mid-task are delivered reliably; only the completion→idle transition window loses them.
- Workaround in production use: an explicit receipt-ack protocol (every dispatch expects an ack; no ack after the next idle ping → re-send with the full brief inlined). This roughly doubles orchestration round-trips.
Expected: a message accepted into the inbox (success: true) should be processed regardless of the recipient's lifecycle transition — either delivered before idling or waking the idle agent.
Happy to provide session IDs / timestamps for the specific occurrences on request.