The interrupt handle
How the user stops a running agent without losing state.
An agent that can't be stopped mid-flight is an agent you can't trust. Most products ship a single "cancel" button and call the problem solved. But interrupt is not one concept. It's at least three: pause (I want this but not right now), redirect (this is the wrong path, change course), and cancel (stop entirely, save what you've got). Collapsing them into one button is the product equivalent of replying to every email with the same sentence.
"Interrupt is not a single button. Pause, redirect, cancel are three different thoughts."
Three buttons, one bar, always visible.
While the agent runs, a control bar sits below the task list with three buttons: pause, redirect, cancel. Elapsed time is shown in small monospace. Clicking pause halts current work and holds context. Redirect opens a text field to rewrite the next step. Cancel stops everything and saves partial work to the thread.
- QueuedFetch customer list
- QueuedJoin against MRR table
- QueuedScore churn risk
- QueuedWrite summary memo
Interrupt is not one button. Pause, redirect, cancel are three different thoughts.
Users interrupt for very different reasons.
A user who says "pause" is coming back. A user who says "redirect" has new information. A user who says "cancel" has lost trust, or changed their mind entirely. A good interrupt system responds to those states differently. A single button forces all three into one behavior and loses the signal.
Details that make interrupt safe.
- Always visible. Interrupt is not buried in a dropdown. It sits where the user can reach it the second they want to.
- Name the consequence. "Pause — resume keeps context." "Cancel — partial work saves to thread." Users should never click and wonder what they just did.
- Elapsed time in view. Seconds on the clock change the emotional weight of the buttons. After ten seconds, cancel feels more expensive. The number is a truth-teller.
Cancel that doesn't really cancel.
Some agents keep running after cancel — emails get sent, files get moved, because the step was already in-flight. If cancel means "stop queueing new work" but doesn't mean "abort current work," the user is operating on a false promise. Every surprise action after a cancel destroys trust that can't be rebuilt in the same session.
What this pattern gets wrong when it gets wrong.
- Runaway agent
- An agent that loops, spends, or edits past the user's intent with no visible cap.
- Ambiguous state
- Running, done, errored, paused all look the same. The user has to infer from context.
Three shipping variants worth copying.
- A fixed handle at the bottom of the run with elapsed + step count
- Pause freezes the agent, Redirect opens a mini-composer
- Resume continues exactly where it paused, with a one-line diff of user input