People insert new requests in the middle of a task

What it is

A taxi booking has reached pickup; the user suddenly asks “is it raining out.” That is not a derailment. It is the normal shape of task dialogue: the main task still open, a new request pushed in. Mid-task insertion treats that move as legal nesting, not as an answer to the current slot. Insertion happens between turns, while a question is still unanswered. It has to be taken as a new goal, not as “pickup = raining.”

Why it happens

Slot filling’s default is that the next utterance fills the empty slot. That prior is strong, so “is it raining” gets stuffed into location, or treated as unrecognised and the pickup is re-asked. People insert for reasons that usually sit outside the dialogue: a glance out the window, another fact needed immediately, someone in the car interrupting. Insertion is mixed initiative — the user takes the questioning role back. A system that clings to the current agenda denies that grab. Detecting insertion means looking at two things at once: the expected type of the current slot, and whether the utterance is better explained as an independent intent. On conflict, the independent intent should win and the current task is suspended, not rewritten. Dropping the insert as noise makes people raise their voice and say the new request again; the main task is delayed either way.

Studying it

In Wizard-of-Oz, plant insertion probes on fixed beats of a slot-filling flow: pickup, car type, just before confirm, each with an unrelated but reasonable request (weather, time, send a text). Independents: semantic distance from the current slot, presence of a discourse marker (“quick question,” “oh and”). Dependents: rate of being taken as a slot fill, rate of being taken as a new intent with the main task suspended, number of times the user repeats the insert.

From live logs, pull turns where the system was asking for slot A and the user utterance is labelled intent B; hand-separate insertion, repair, and genuine slot answers. Do not count every intent switch as an insertion — some people are changing the current task, not nesting a new one.

Where it stops holding

One utterance that contains both the current slot and a new request (“airport, and is it raining”) is a compound command, not a mid-task insertion; insertion is a new request as its own turn while a task is still unclosed. If the insert is actually an indirect answer to the current question (“what time should we leave” → “my meeting ends at three”), infer and fill rather than suspend. On a high-consequence confirm beat (“pay now?”), treating every aside as an insert leaves the confirm hanging; pin the confirm first or say payment is being suspended. Screenless, if the inserted skill does not exist, admit it cannot be done and return to the original question rather than fake a successful insert.

Applying it

• On every pending slot, keep a detector for “this does not look like filling this slot”: when independent-intent confidence beats slot filling, take the insert; do not write it into the current slot.
• Accepting an insert does two jobs in one line: take the new request, and mark that the main task is still there (“weather first. cab is not booked yet.”), so it does not sound like a change of job.
• Do not treat insertion as recognition failure and re-ask the original slot; re-asking squeezes the new request out.
• How to check: on three fixed beats of a taxi flow, insert one weather line. If any beat writes “raining?” into pickup, or ignores it and only repeats the original question, insertion was not treated as nesting.

Related

• Same group: M1.05.2 After the insert, the original task has to resume · M1.05.3 Nesting depth needs a hard cap · M1.05.4 A topic switch and a correction are different intents · M1.05.5 A suspended task must keep its full mid-state · M1.05.6 Abandoning a task needs an explicit exit
• Nearby: M2.13 Multi-Intent and Compound Commands · M3.09 Barge-in and Interjection · M2.07 Dialogue Flow and State Design
• Search terms: mid-task insertion · mixed initiative · nested request