On September 15 someone filed a bug against CopilotKit, one of the popular toolkits for putting agents inside web apps. The Stop button sent a stop to the conversation, not to the run. So if you pressed Stop, changed your mind and immediately asked again, a stop that arrived a moment late could kill the new request instead of the old one. You stop the wrong thing, and the thing you meant to stop was already gone.

It's a small bug with a one-line fix: say which run you mean. But I keep coming back to it, because it shows how Stop usually gets built. It gets added late, aimed at "whatever is happening right now", because it looks like the least interesting button on the screen.

I think that gets it backwards. When the interface is being built while you watch, interrupting it is how you steer, and steering is most of the job.

You find the question by asking a worse one

Most software assumes you know what you want before you ask. You fill in the form, then press the button. Undo exists for the cases where you didn't, and it only works after the fact.

That isn't how anyone actually thinks through a problem. You ask a rough version, watch what comes back, and realize halfway through that you meant something slightly different. With a chatbot this barely registers, because the answer is text and it arrives quickly. With a generative interface it gets worse. The system is fetching real data and building a screen around it, and that takes seconds, sometimes much longer. Those seconds are exactly when you're watching the first panels appear and thinking "oh, I should have said cheaper ones too."

If the only options are to wait or to start over, people adapt the way people always adapt to rigid tools. They write longer, more defensive requests up front, trying to cover every case, because correcting course costs a full restart. The interface has taught them to rehearse. A computer that's supposed to work from intent shouldn't need rehearsed intent.

Three kinds of second thought

A paper from April, "When Users Change Their Mind", gives a useful vocabulary for what people do mid-task. An addition brings in a new requirement ("also include flights on Sunday"). A revision changes one that was already there ("actually, Lisbon, not Porto"). A retraction takes one back ("forget the hotel"). The authors built a benchmark around these on top of web navigation tasks and found that every model they tested struggled to adapt, and struggled to recover without wasting work.

Another paper, "Are Large Reasoning Models Interruptible?", presented at ICML this year, found that updates arriving late in a model's reasoning can cut performance by up to 60%. The failure modes have names I wish I'd invented: panic, where the model gives up reasoning under pressure, and self-doubt, where it second-guesses correct work once new information arrives.

So you can't just pipe the user's new message into the running model and hope. Something outside the model has to decide what an interruption means and when it lands.

What Stop should leave behind

The first question is the least glamorous one: when you press Stop, what's on the screen afterwards?

We shipped Stop in Beacon last week, and this was the part that needed actual design. A generative UI mid-turn is full of half-finished things: placeholders waiting for data, a chart halfway through being redrawn with fresh numbers. A careless Stop leaves you staring at skeletons. An overcautious one throws away the good results you'd already gathered.

We settled on a rule that sounds obvious once you say it: anything real stays, anything promised goes. Panels that already hold data remain. Empty placeholders disappear. A panel that was being refreshed goes back to the version you had before. And stopping isn't treated as an error. The turn finishes, it just finishes early. That distinction matters more than it sounds, because anything that treats a stop as a failure will eventually show you a red error message for something you did on purpose.

The CopilotKit bug is the other half of this. Stop has to belong to one piece of work. Once the stopped turn is stopped, nothing it produces afterwards gets to reach the screen, including the stragglers that were already in flight when you clicked.

Queue or steer?

The harder case is when you don't want to stop at all. You want to add something.

Tools disagree here. OpenAI's Codex puts a message typed during a run into a queue for later, and you promote it by hand if you meant it as a correction. In July a user asked for a setting to make steering the default, because the corrections kept getting lost in the queue. That's a reasonable complaint, and also a reasonable design, because some messages really are new requests, and folding them into the current work would muddle both.

Beacon defaults the other way. A second thought typed mid-turn is treated as an amendment to the work in flight, and the interface says so while it happens: adding to the current work, then folded in. Whether it's truly an amendment is a judgment the planner makes, and if it decides you've actually asked for something separate, the message waits its turn. Three edge cases needed their own rules.

If the amendment arrives after the system has decided it's done gathering, it goes back for one more look rather than delivering an answer that never saw your update. If it arrives too late to absorb, it becomes the next request. And if the original request failed or you stopped it, the amendment is dropped, because refining a question that never got an answer is nonsense. You'd end up with "also include the cheaper options" running on its own, with nothing to be cheaper than.

I'm not certain our default is right for everyone. It fits a workspace built for research and decisions, where most mid-turn messages are refinements. A coding agent, where a new message is often a new task, might reasonably choose the queue.

Reversibility is what makes interruption cheap

The April paper that I found most clarifying is "Revisable by Design". Its central claim is that an agent's flexibility is bounded by its reversibility. If every action can be undone, you can change your mind at any point. Each irreversible action makes that harder.

Generative UI is lucky here. Most of what it does is reading and drawing: looking things up and laying out panels. All of that can be discarded or redone at almost no cost. The expensive exceptions are actions that touch the world, like sending an email or deleting a file.

This is where interruptibility meets consent. In Beacon, an action that can't be taken back, such as sending a message on your behalf, only happens when you click for it. We adopted that rule for trust, but it turns out to be what makes the rest of the system safe to interrupt. If the only irreversible steps sit behind a button you press, then everything before the button is a draft, and you can tear a draft up whenever you like.

Honest limits

Our tests fake the model, so they tell us the rules above behave as intended. They don't tell us how well a real model folds a vague amendment into half-done work, and that's the part the research says models are bad at. We'll learn that from use, not from a test suite.

The question I actually care about isn't an engineering one. If being wrong becomes cheap, do people start asking shorter, rougher questions, trusting that they can steer? I suspect they do. If so, a generative interface can't only be good at answering well-formed requests. It has to be good at the half-formed ones, the kind people ask when they know they can change their minds.

If you want to try interrupting it yourself, Beacon is at studioaices.com/download.

Further reading