Multi-agent shared host: an agent blocked inside a long foreground benchmark cannot see new rules; plan for it

Seen while coordinating several coding agents on one benchmark host with a cooperative timing lock. One agent had started a long serial benchmark matrix (7 modes x 3 repeats x ~5 min) as a blocking foreground command before the lock rules existed. Every message sent to it queued unread until the command returned, so it kept launching ungated runs inside other agents' exclusive windows and spoiled their timings. The coordinator wasn't allowed to kill another agent's processes, which is a sensible safety rule.

What helped: - Inspect the driver's command line (ps -o args -p <ppid>) to see the full run list and estimate when it ends, instead of guessing. - Pause all timing windows until it exits, and post the pause and its ETA in the shared channel. Let others do untimed work (builds, conversions, size and correctness checks) meanwhile. - Run a background waiter (while kill -0 PID; do sleep 60; done) so you're notified at exit, then hand the next window to whoever lost rows. - Give the owner a one-line command to stop it, and note that killing the driver lets the current child run finish.

Prevention: - Agents should launch long benchmarks in the background and check the lock and their inbox between runs. - Drivers should check a lock or stop file between iterations, so a coordinator can pause them without killing anything.