When the User Changes Their Mind Halfway Through
A user started a bulk update, realised after ninety seconds that the filter was wrong, and said so. The agent finished the original job, correctly and completely, and then reported success.
The Ninety Seconds
The task was updating a delivery address across a set of open orders. The agent read the filter, retrieved forty-one orders and began working through them. Ninety seconds in, the user typed that the filter should have excluded cancelled orders.
The agent did not see that message until it had finished, because our design collected user input between tasks rather than during one. Thirty-eight orders had been updated, six of which should not have been, and the report said the task completed successfully.
Why Our Design Had No Room for It
We had modelled an agent task as a request and a response. That model is correct for a step that takes two seconds and wrong for one that takes three minutes, and the boundary between those two cases had moved without anyone noticing as tasks got larger.
Zou and colleagues published work in 2026 evaluating interruptible agents on long-horizon tasks, treating the user changing their mind mid-task as a normal event to be handled rather than as an edge case.
What We Built
Checkpoints between steps. The agent checks for new user input after each item rather than at the end, and a new message pauses the run and presents what has been done so far with what remains.
That is cheap because the loop already existed; the change was to read a queue at the top of each iteration. It is not preemption, and an item in progress finishes, which for our tasks means at most one more record is affected after the user speaks.
| Task length | What we do |
|---|---|
| Under a few seconds | Nothing. Not worth interrupting |
| Seconds to minutes | Check for input between items |
| Minutes with side effects | Check, and report progress as it goes |
| Anything with irreversible steps | Confirm before starting, not during |
What an Interruption Actually Costs
The check itself is free. What costs is that the agent now has to be able to describe its own progress in a form a user can act on: thirty-eight of forty-one done, these six matched the cancelled filter you mentioned, stop or continue.
That reporting turned out to be most of the work. An agent that can pause but cannot say what it has done presents a user with a choice they have no basis to make, which is worse than not pausing.
Undo Is a Different Problem
We did not solve it. The six wrongly updated orders had to be corrected by hand, because the agent's tools write to a system that has no transactional boundary around a batch of forty-one records.
What we added instead is a record of what was changed, per item, with the previous value. That makes correction a scripted operation rather than an investigation, and it is the honest limit of what we can offer when the underlying system does not support rollback.
The Rule About Irreversible Steps
Anything irreversible is confirmed before the run starts, listed explicitly, and never inside a loop that can be interrupted halfway. An agent that sends emails to a list is not an interruptible task; it is a task that gets confirmed and then runs to completion.
That distinction is now part of how we classify agent work in design. Reversible bulk operations get checkpoints. Irreversible ones get a confirmation screen and no ability to be stopped, because a half-sent mailing is worse than either outcome.
What We Tell Users
That they can interrupt, in the interface, at the moment the task starts. A capability nobody knows about is not a capability, and our first version had the checkpoints and no indication that speaking would do anything.
Usage of the interrupt is about one run in nine, which is far higher than we expected and suggests that people were previously watching tasks run wrongly and waiting for them to finish.
What We Do Not Claim
We do not claim checkpointing makes long tasks safe. It reduces the window in which a wrong instruction keeps being executed, and the underlying risk is that a bulk operation was started on a wrong filter, which is a confirmation problem at the start rather than an interruption problem in the middle.
We also do not claim our one-in-nine figure is a good sign. It might mean the interface is working, and it might mean our task setup step is bad enough that people frequently start the wrong job. We have not separated those and we should.