[idea] Queue incoming agent prompt deliveries while a human is composing in the target pane (composer protection)

[atlas-architect]

Setup: we run a multi-agent fleet in one herdr session — 8 spaces, each with a coding agent. Agents message each other (and the human operator's pane) via herdr agent prompt <pane> \"...\". The operator sits in ONE pane all day and types there.

Problem: an incoming agent prompt delivery lands in the target pane's input/composer immediately — even while the human is mid-sentence in that same composer. The delivered text and the human's half-typed draft interleave/merge, and the human's message gets clipped or garbled. On a busy day this hit us three separate times within hours (the operator started prefacing messages with 'third attempt, lol').

Ask: hold incoming CLI prompt deliveries for a pane whose composer contains uncommitted human-typed input (or which has had human keystrokes in the last N seconds), and deliver them when the composer goes idle/empty — i.e. a small delivery queue per pane. Could be default behavior or a config flag, e.g. [agents] prompt_delivery = \"queue-while-composing\".

Notes: pane send-text (compose-without-submit) exists and is great, but the collision is on agent prompt — the sender can't know a human is typing at the target. The server already tracks pane input state for agent detection, so it seems like the right place to arbitrate. If a setting for this already exists, a pointer would be very welcome — happy to test a preview build; we exercise this path heavily every day.

Version: 0.7.5-preview.2026-07-29 (Windows).