Overlong prompts get cut off or forgotten
Aliases: prompt barge-in · trailing-clause loss · prompt length
What it is
Once a prompt outruns what a listener can hold while waiting to speak, it has two fates: barge-in, so the second half never enters the ear, or heard-but-gone, so the second half has dropped from memory before the mouth opens. A parking-payment pillar that reads thirty seconds of tariff rules before “please give your plate” will be interrupted at the second sentence by someone late for the gate; the time-limited discount clause might as well not have played. This is not a copy-tone problem. The channel truncates information in time.
Why it happens
Two forces act together. One is encoding: speech has no glance-back, so prompt clauses form a temporal queue and middle items fall out first. A constraint parked at the tail (“reserved vehicles only”) is squeezed out as the user starts to assemble a reply. The other is production grabbing the floor: many people already have the utterance they will say when the prompt begins. They are not listening-then-planning; they are waiting for a seam they can enter. If barge-in is on, the seam cuts the tail. If barge-in is off, attention moves from listening to rehearsing their own line, and the tail is still not encoded.
“Read it all, then ask” therefore does not protect the information. The tail of a long prompt goes systematically missing under both policies — and what goes missing is often the restriction, exception, or prohibition the writer most wanted to keep. That is a different claim from whether users have a right to interrupt playback. The right can be granted; the tail still does not arrive.
Studying it
Prompt-length recall tests: segment the prompt into clauses, then take immediate serial recall after listening (or after a forced interrupt at a chosen point). Independent variables: clause count, position of the constraint clause (first, middle, last), barge-in on or off. Dependent measures: clause recall, latency of barge-in from prompt onset, and whether subsequent behaviour obeys a constraint that was not recalled.
Live logs are harder evidence: align timestamps from prompt start to user speech, and plot which clause the opening lands in. If openings mass on the first two clauses, later clauses are already dead text in the product. Labs that forbid barge-in and instruct “please listen to the end” undercount real truncation and overcredit tail constraints.
Where it stops holding
When the user is genuinely waiting for unknown information (first use, no idea what will be asked), they listen longer and tails survive more often; that measures patience under uncertainty, not a licence for long prompts in practised scenes. Too-fast synthesis makes even a short word count feel “too long” — length is listening time, not characters. In noise, the second half loses intelligibility first, so truncation arrives earlier. Moving a key constraint to the front can save it; stacking three exceptions at the front then shoves the act itself to a tail that will be forgotten.
Applying it
- Put the slice the next user turn actually needs in the first two seconds: act or critical constraint first, explanation later, and assume the later part often never arrives.
- In logs, mark each prompt's speech percentile (how far the prompt had been read when the user opened). Delete or defer anything in a half that almost nobody hears.
- Split required legal sentences from the action sentence and make them skippable; do not count on both landing inside one long playback.
- How to check: sample real sessions and align timestamps. If the share of openings that occur after the constraint clause is low, move the constraint forward, park it on a later confirm turn, or speak it only on the turn where the user has already started to violate it.