Interrupting an Agent: Almost Everything Is in the First Minute
Watch which files it opens. If they are the files you would have opened, stop watching and go do something else.
The capability is trivial; the skill is knowing when
Every interactive agent lets you stop it. Press a key, the work halts, you say something different, it continues from there. As a feature this is unremarkable and takes ten seconds to learn.
As a practice it is one of the highest-leverage things you can get good at, and almost nobody treats it as a skill. The value of an interrupt is entirely a function of when it happens: at thirty seconds it costs nothing and saves an hour, at forty minutes it costs forty minutes and saves twenty. Same keystroke, wildly different economics.
Which means the useful question is not how to interrupt but how to recognise a wrong turn early — and the recognisable signals are almost all in the first minute, before any code has been written.
The opening moves tell you most of it
Before an agent changes anything, it orients: it searches for something, it opens some files, it reads. That sequence is a direct readout of its model of the problem, and it is available while the cost of being wrong is still zero.
If you asked for a change to session handling and the first three files it opens are the ones you would have opened, the model is right and you can stop watching. If it opens the HTTP layer, it has understood the problem differently from you, and thirty seconds of reading has just saved you the argument you would otherwise have at review.
This is the single most useful habit in this article: watch the opening moves, then leave. Not the whole session — the first minute, where the information density is highest and the correction is cheapest.
Four early tells
The wrong files. Covered above, and the strongest signal. It indicates a different mental model of where the behaviour lives, which means everything downstream will be built in the wrong place.
Search terms that are not yours. Searching for
retry when your codebase calls it backoff means the
agent has not found the existing implementation and is about to write a second
one. Vocabulary mismatches are cheap to fix — tell it the word —
and expensive to leave, because the outcome is a duplicate abstraction.
Reading too little. An agent that opens one file and starts editing on a task that clearly spans several has not established the context to do it correctly. The edit will be locally plausible and wrong at the boundaries.
Reading far too much. The opposite tell, and it usually means the request was ambiguous. An agent that opens twenty files on a narrow task is searching rather than working, because it does not know what you meant.
Most wrong-file starts are caused by a request that did not name a
location. "Fix the retry logic" has to be located; "fix the retry logic in
sync/backoff.ts" does not. Ten extra words removes the most
common failure entirely.
The middle of a task is where interruption gets expensive
Once implementation is under way the calculation changes. There is now partial work in the tree, the agent's context contains a chain of decisions, and an interruption leaves you in a state that is neither the original nor the intended result.
That state is the real cost. A half-applied refactor across nine files is worse than either endpoint: the code does not compile, the diff is meaningless, and deciding whether to finish it or unwind it requires understanding what it was doing. Interrupting mid-flight is sometimes right and it is never free.
Interrupt between steps, not inside one
Where you have the choice, stop the agent at a boundary rather than during an operation. Between two files is better than halfway through one. After a test run is better than during it. After a commit is much better than before.
Agents that announce what they are about to do give you these boundaries for free, which is a good reason to ask for that narration on longer tasks. The stream is not for reading closely; it is for knowing when the safe stopping points are.
Know what state you are in before you say anything
The first thing to do after stopping something mid-task is to look at
git status and the diff, not to type a correction. The agent's
description of where it got to is a summary, and summaries are the part most
likely to be optimistic about what completed.
Ten seconds of looking tells you whether you are correcting a direction or cleaning up a mess, and those need different next messages. It also stops the common failure where you redirect an agent that is holding a broken tree, and it carries the breakage into the new direction.
The correction that works
"No, stop" produces a stopped agent with no new information. It will try something else, and the something else is drawn from the same wrong model, so it is often wrong in a related way.
What works is naming the divergence: "stop — session state lives in
auth/session.ts, not in the middleware; start there." One
sentence, and it corrects the model rather than the action. The distinction
matters because you will otherwise interrupt three times on variations of the
same misunderstanding.
The general principle: an interrupt should transfer the piece of knowledge that was missing. If you cannot articulate what that is, you may be reacting to unfamiliarity rather than to an error, which is worth checking before spending the interruption.
Redirect or restart
After a substantial wrong turn, continuing the session is often worse than starting a new one. The context now contains the failed approach, the files it read for the wrong reason, and the reasoning that led there, all of which continues to influence what comes next.
A fresh session with a better prompt — incorporating what you just learned about how the request was misread — is frequently faster and produces cleaner work. The heuristic I use: if the correction is a fact, redirect; if the correction is the whole approach, restart.
The sunk cost trap is real here
Forty minutes of work exists. It is wrong, and it is also substantial, and there is a strong pull toward salvaging it: keep the parts that look fine, adjust the rest, avoid throwing away something that took time.
That instinct is usually wrong with agent output specifically, because the time was not yours. Forty minutes of agent work took forty minutes of wall clock and perhaps five of your attention. Regenerating it correctly costs another forty minutes of wall clock, which you can spend doing something else. The economics that make salvage rational for human work do not transfer.
Sometimes let it fail
Not every wrong turn should be interrupted. If the agent is heading toward something you believe will not work but are not certain about, letting it arrive at the failure produces information — both for you and in the session's context, where the failed attempt becomes a reason not to try it again.
This is especially true when your objection is intuitive rather than articulable. An interrupt based on a feeling transfers no knowledge, and you may be wrong. Letting it run to a concrete failure converts your intuition into evidence, at the cost of a few minutes of compute.
Every interruption is feedback about your prompt
The most valuable thing to do after stopping an agent is to ask why it went that way, because the answer is nearly always in your request rather than in the model.
An ambiguous noun. A location left unstated. A constraint you knew and did not write. A term your codebase uses differently from the rest of the world. Each interruption points at one of these, and fixing the pattern removes a whole class of future interruptions rather than one instance.
Teams that track this informally end up with much better prompts within a few weeks, and the improvement shows up as fewer interruptions, which is the outcome you actually wanted.
Interrupting is not the same as course-correcting a person
Worth saying because the social instinct interferes. Stopping a colleague mid-sentence is rude, and that reluctance transfers: people let an agent finish out of a vestigial politeness, then correct the finished work.
There is nothing to be tactful about. An interrupt at second thirty is strictly better for everyone than a rewrite at minute forty, and the only cost of a wrong interrupt is a few seconds. If you notice yourself waiting for a natural pause, that is a habit worth discarding deliberately.
What to do when you cannot watch
The whole practice assumes you are present for the opening. When you are not — because the task is running unattended — the equivalent control is the plan: ask for the approach and the file list before any work happens, and read that instead of the opening moves.
It is the same information in a different form, delivered at the same cheap moment, and it is why the two practices pair well. Watching the first minute and reading a plan are both ways of buying a veto before the expensive part, which is the argument in plan mode as a cheap veto.
Interruption is a design affordance, not a safety net
A closing distinction. Being able to stop an agent is not a substitute for constraining what it can do — an interrupt requires you to be watching, and anything that depends on human attention is not a control, for the reasons set out in approval fatigue.
Its actual role is to make cheap correction possible during work you have chosen to supervise. That is a productivity mechanism rather than a safety one, and treating it as safety leads to supervising work that should have been constrained instead.
The habit, in one line
Watch the first minute. Check the files it opens against the files you would have opened. If they match, stop watching and do something else. If they do not, interrupt immediately and say what it missed.
That is thirty seconds of attention per task, it catches the majority of wrong turns at the point where correction is free, and it is compatible with not supervising the rest. The alternative — watching everything, or watching nothing — is either expensive or blind, and the first minute is where nearly all of the recoverable information is.
A note on the pause you cannot take back
One asymmetry worth keeping in mind: some actions cannot be interrupted usefully because they complete faster than you can react. A command that pushes, deploys, migrates or deletes is finished before the keystroke lands.
For that class, the interrupt is not the control and never was — the control is the denial rule that stops it being attempted. Interruption governs the slow, visible, multi-step work where you have seconds to react, which is most of what an agent does and is emphatically not all of it.
Finally, notice that this whole practice only pays off if you actually leave. Watching the first minute and then continuing to watch is just supervision with extra steps, and it is the easy thing to do because the stream is right there and mildly interesting. The discipline is the second half: having checked the opening moves, close the window and go and do something that needs you.
An interrupt at thirty seconds costs nothing and saves an hour; at forty
minutes it costs the forty minutes. The recognisable signals are almost all in
the opening moves — which files it opens, what terms it searches for,
whether it reads too little or far too much — so watch the first minute
and then leave. Correct by naming what it missed rather than saying stop,
check git status before redirecting mid-task, restart rather than
salvage when the whole approach was wrong, and treat every interruption as
information about your prompt.