Interruption and Steering

In one line: a long-running task means the user has time to change their mind, and a system that cannot absorb that is a system people stop trusting with long-running tasks.

Why this is a first-class requirement

Single-turn systems do not have this problem — the response arrives before there is anything to change.

An agent working for two minutes, or two hours, is different. In that window the user may want to stop it, redirect it, add a constraint, or ask what it is doing. A system that treats the task as atomic offers only one option, cancel, and cancelling loses the work.

Four distinct interventions, and they need different machinery:

Durable state

The requirement underneath all four.

The loop's state — the goal, the plan, completed steps and their results, the current step — has to live outside the process running it. Not because the process will crash, though it will, but because the user's interruption arrives through a different path than the one executing the task.

Which makes each step a checkpoint: state is persisted after every step, so a task can be paused, inspected, resumed or abandoned at any boundary. That is a small amount of engineering that unlocks all four interventions at once, and skipping it makes every one of them impossible.

The natural consequence: steps should be interruptible between them, not within them. A step in flight runs to completion — cancelling mid-tool-call risks exactly the ambiguity idempotency was introduced to handle — and the loop checks for an intervention before starting the next one.

Folding in a new instruction

The interesting case, and the one designs handle worst.

The user says "also book a hotel" while the agent is four steps into arranging travel. Three ways to handle it, in increasing quality.

Restart with the combined goal. Simple and wasteful — it discards four steps of work, and the user watches it redo what it already did.

Queue it for after. Also simple, and often wrong, because the new instruction may change earlier decisions. Booking a hotel might affect which flight makes sense.

Replan from the current state with the augmented goal. Correct and it needs the state to be inspectable: take what has been established, add the new constraint, and produce a plan for the remainder. Completed work is kept, and the new instruction can influence what remains.

Showing what it is doing

The transparency requirement, and it is a product decision with a design consequence.

A user waiting on a multi-step task with no visibility will cancel it, because an opaque delay is indistinguishable from a hang. The plan is what makes progress legible — "step three of six: checking availability" — which is the strongest practical argument for planning upfront even when execution is incremental.

Two details worth getting right. Show what it is doing, not the model's reasoning — a stream of chain-of-thought is noise to a user waiting for a hotel booking. And surface the actions taken so far, particularly writes, because that is what a user needs to decide whether to stop.

Cancellation, done properly

Not just stopping the loop.

Stop before the next step, not mid-step, for the idempotency reason above.

Report exactly what was done. The list of actions taken, especially anything that changed the world. A cancelled task that leaves three side effects the user does not know about is worse than one that ran to completion.

Offer to undo. Where the actions were designed to be reversible — a cancellable hold, an unsent draft in an outbox — cancellation should offer to roll them back rather than leaving the user to find them.

That third point is the payoff for the write-ordering discipline from the termination lesson. If writes come last and are reversible, cancellation is clean; if they are scattered and irreversible, cancellation is a mess no interface can tidy.

Asking the user mid-task

The reverse direction, and it is under-used.

An agent that hits genuine ambiguity has a better option than guessing: ask. "There are two flights that fit — the cheaper one arrives at 11pm. Which?" is a good outcome, and it is far better than a confident wrong choice the user has to unpick.

Three design points. The question must be specific and answerable in one interaction — an open-ended "what would you like me to do?" hands the work back. The task must survive waiting, which is the durable state requirement again, since the user may answer in an hour. And there needs to be a timeout policy: what happens if they never answer? Usually abandon with a report, never silently proceed on a guess.

That last one matters because an agent that waits indefinitely accumulates zombie tasks, and one that proceeds after a timeout has converted an explicit question into an implicit assumption.

Next: what it costs, and how to tell whether it works.