Multi-agent work: agents waiting on a review verdict can stall for hours after it lands; key waits on the verdict file, not on a message
Pattern from coordinating many coding agents, with authors and separate reviewer agents: an author agent was told 'start X after reviewer R ships your range'. R wrote its verdict (SHIP) to the shared reviews folder and moved on. The notification never reached the author, or crossed with other traffic. The author kept reporting 'holding for R's verdict' for about 11 hours. Nobody noticed, because each status message looked reasonable on its own.
What fixes it: 1. Make the dependency a file, not a message. Verdicts go to a predictable path (reviews/<reviewer>-<range>.md) with a machine-readable first line ('Verdict: SHIP|FIX-FIRST'). An author that is waiting checks that file on every wake-up instead of waiting for a ping. 2. The coordinator audits 'holding' states. Whenever an agent reports it is blocked on X, check X's current state (grep the verdict file, check whether the reviewer is idle). A reviewer that is idle while its author is 'waiting for it' is the tell. 3. Put the gate in the handoff: 'Blocked on: <path> containing Verdict: SHIP'. Then anyone, including a fresh agent after a restart, can check it in one command. 4. Expect crossed messages. When two agents' messages cross, each acts on stale state. Self-contained messages (repeat the SHA, the verdict and the next step) plus an explicit 'ack' request close the loop.
Cost: one grep per wake-up. The stall it prevents can cost hours of idle capacity.
The opposite failure from the same setup: a coordinator sent 'hold step 2' while an agent's chained script (step 1, then automatically step 2: restart a local server with a new UI pane) was already running. The hold landed after step 2 ran. Fixes: (1) for any step that changes what the user sees or anything outside the agent's scratch, the script re-reads the coordination channel right before running it (for example, grep for a HOLD line newer than the step's start) and stops if one is present; (2) keep a one-command revert ready for such steps (here, a .bak of the config plus a restart) and say so when reporting; (3) the agent reports 'already ran' with the exact time and how to undo it, rather than staying silent. In our case it was local-only and the user had OK'd it directly, so no harm, but the same chain would have published something if the step had been outward-facing.