An agent is twenty minutes into a database migration and you change your mind. You press stop. The process dies in under a second, the terminal comes back, and for a moment that feels like control. Then you go and look. Four tables have the new column, eleven do not, and nothing on disk says which four. The plan it wrote at the start went with the process, along with a test run that took nine minutes. You did stop it. What you did not do is stop it anywhere in particular, and those are not the same act.

A countdown is built around its holds

A launch count does not slide smoothly to zero. It is a sequence of marks with pauses designed into it, and any team in the room can call a hold at one of them. Calling a hold at four minutes costs almost nothing. The count freezes, the vehicle sits exactly as it is, and when the issue clears the count resumes from the same mark. Call one after the tanks are full and stopping is no longer free: somebody has to drain them, which takes hours, and the vehicle is not back where it began until they have. Past the moment the engines light there is a shrinking window in which they can still be shut down, and then a point where nothing anyone says changes the outcome.

An agent run has that shape too, whether or not anybody designed it that way. Reading a file, drafting a plan, running the suite: drop those halfway and nothing needs undoing. Creating the bucket, sending the mail, charging the card: those need an undo written in advance, by you, because the tool will not hand you one. So a run that can be stopped is one that knows which of the two it is currently inside, treats the stop as part of its own state rather than a button drawn on a screen, and writes down where in the run the signal arrived.

Keep the diff, refuse the deploy

Picture the good version of the migration. The agent has built the change, produced a diff, and run the tests. You stop it before it applies. What survives is the plan, the diff and the test output; what does not happen is the deploy. Tomorrow a fresh session opens at the review step rather than at the first file, because the costly part of the run was the thinking, and the thinking had been written down before the effect was attempted.

That only works if the stop is read somewhere specific: a point where the effect has not run yet and the evidence already exists. Such a point is already in the loop, immediately before anything high-impact, because that is where a run checks whether it has approval to proceed. Checking there on every single call would be a tax on the trivial ones, so the check is staged. A fast pass looks at what the person actually asked for and what the call actually does, and waves through safe reads and edits inside the project. Only the few calls it flags get the slow, reasoned look. Notably, the fast pass does not read the agent’s own explanation of why the action is fine, which is the one input guaranteed to argue for going ahead.

Reading the stop signal at that same point costs nothing extra. It is already the place where the run pauses to ask a question.

The stop is only as good as the undo

Some tools have no undo at all, and no amount of runtime cleverness invents one. For those, the honest design is to put the decision in front of the action rather than pretend a stop can reach behind it. The same goes for the cleanup you owe after a half-finished sequence: if nobody wrote the compensation, the stop is a wish. This is the quiet argument for a loop that keeps its work on disk as it goes, the discipline described in The Loop Is the Product — resumable state is the thing a stop is protecting, and there is nothing to protect if the run held everything in memory.

None of this comes from the model. It has no idea a stop signal exists, cannot tell a cancellable call from an irreversible one, and would not remember either way. Interruptibility is a property of the loop, and somebody writes it on purpose. An agent you can only stop by killing it is an agent you have to sit and watch.