Supervising AgentsJuly 14, 2026·5 min read

When to Stop an Agent Mid-Run

Watching an agent work produces a specific reluctance to interrupt it, and that reluctance is expensive. Here are the four signals worth stopping on, and why the sunk cost is smaller than it feels.

By Forge Team · Examples are illustrative composites

There's a particular reluctance that comes from watching an agent work. It's been running for eleven minutes, it's clearly doing something, and stopping it feels like throwing that away.

So people don't stop. They watch a run go somewhere unhelpful and wait to see whether it comes back, and then they review the result and find it was decided at minute three.

The reluctance is sunk-cost reasoning with a progress bar attached, and it's worth naming because agents are unusually good at triggering it. A run that produces visible activity feels like progress in a way that a person quietly thinking does not.

The sunk cost is smaller than it looks

An agent run that has gone wrong isn't costing you the eleven minutes. It's costing you the eleven minutes plus the review time on a bad output plus the rerun. Stopping at minute three costs three minutes and a rewritten brief.

This is different from interrupting a colleague, which has a real social and cognitive cost. It has no such cost here, and the intuition that it does is borrowed from a situation that doesn't apply.

The four signals

It's answering a different question. The most common failure and the earliest visible one. Somewhere in the first few steps the agent settles on an interpretation, and everything after that is competent work on the wrong task. If the interpretation is wrong, nothing downstream repairs it.

It's looping. Searching variations of the same query, rewriting the same section, retrying a failing call. A loop means it's stuck and has no way to tell you, because "I can't do this" is not an output most agents reach for. Loops don't resolve themselves.

It's about to do something irreversible on unverified ground. If the run is heading toward a send, a spend, a delete, or a write to a shared system, and you haven't verified the reasoning that got it there — stop before, not after. The asymmetry is the whole point.

It's substituting. It couldn't get the thing you asked for, so it found something adjacent and is proceeding as though it were the same. This is the hardest to spot and the most expensive, because the output will be coherent and about the wrong data.

The signal that isn't one

It's taking longer than expected. On its own this means nothing — some tasks are genuinely deeper than they looked, and an agent that spends longer gathering is often producing better work.

Duration only becomes a signal in combination with one of the four above. Stopping on time alone trains you to interrupt exactly the runs that were about to be thorough.

Budget the run before it starts

The version of this that actually works is decided in advance, not in the moment. A budget — steps, minutes, or money — turns "should I stop this?" from a judgement call under mild sunk-cost pressure into a threshold that already passed.

Set it deliberately low the first few times you run a new kind of task. The information from a run that hit its ceiling is more useful than a run that finished, because you learn where the work actually is.

What to do after you stop

Don't restart with the same brief and hope. A stopped run is a diagnosis, and the fix is nearly always upstream of the agent:

  • Answering a different question → the brief was ambiguous, and you now know exactly where.
  • Looping → it lacks access to something, or the task can't be done with the tools it has.
  • Substituting → say explicitly what to do when the real source is unavailable, which is almost always stop and tell me.

Three of the four failures are brief problems. That's the useful thing about stopping early: you find that out while it's still cheap to act on.

Tomás — the run he let finish

Tomás is a market analyst at an investment firm. He gave an agent a competitor pricing task and noticed at around minute four that it was analysing the wrong product line — the names are similar and it had picked the adjacent one.

He let it run. His own account: it was already halfway, and he wanted to see whether it would catch itself.

It didn't, and it never had any way to. Forty minutes of well-structured analysis of a product line he didn't care about, then a rerun. His rule now is that a wrong interpretation gets stopped in the first minute it's visible, because interpretation errors don't self-correct — they compound with every subsequent step.

Reem — the ceiling that taught her something

Reem leads operations at a healthcare provider. She sets every new agent task a hard ceiling — a fixed number of steps — for its first few runs, and treats hitting the ceiling as information rather than failure.

The first run of a records-reconciliation task hit the ceiling in a place she found surprising: it had spent nearly all of it on a formatting inconsistency she hadn't known existed in the source data.

Without the ceiling that would have been an expensive run with a mediocre output. With it, she found a data problem in twenty minutes and fixed the actual cause.

The one thing

Stop when the agent is answering a different question, looping, substituting, or about to do something irreversible on unverified ground. Don't stop on duration alone.

The eleven minutes are already gone either way. The only question is whether you spend more on top of them.

Reading about it only gets you so far

Forge turns this into five-minute drills that score what you write and tell you why. It's in closed beta — join the waitlist and we'll email you when your cohort opens.

Just want the writing? .