When to Kill an Agent Run vs Let It Keep Going

There's a specific moment every team running autonomous agents eventually hits: a run is still going, well past when it should have finished, and nobody's sure whether it's working through something legitimately hard or spinning in a loop that's about to produce something expensive and wrong. The instinct, especially for anyone who's watched a smart junior colleague push through a hard problem, is to give it a bit more time — maybe it's close, maybe interrupting now wastes the progress it's already made. That instinct is usually the wrong one, and it's wrong for a specific, structural reason: an agent that's behaving unpredictably has already told you the one thing you needed to know, which is that its behavior is currently unpredictable. Waiting to see what it does next is not caution. It's exposure, extended.

Why "let it finish" feels safer than it is

The appeal of letting a run continue is that killing it feels like an admission that something's broken and an acceptance of wasted work. But that framing gets the risk backwards. A run that's already outside its expected pattern — taking far longer than normal, retrying the same failed action repeatedly, escalating into a category of action it doesn't usually take — is a run whose next action you have reduced ability to predict. The cost of letting it continue isn't "we might waste the progress so far." It's "we don't actually know what it does next, and we've chosen not to find out until after it's already happened."

This is the direct extension of blast-radius gate design: a gate caps what a single action can do. A kill switch is the same logic applied to an entire run — capping what an entire sequence of actions, compounding on each other, is allowed to do before someone intervenes. The two work together. A well-designed gate limits the damage of any one step; a well-designed kill decision limits how many uncertain steps get taken in a row before a human re-enters the loop.

The signals worth watching for, specifically

Vague unease ("this feels like it's taking a while") isn't a trigger, it's a prompt to go look at something concrete. What's actually worth wiring as a hard signal: duration significantly outside the historical norm for this task type — not an absolute number, but a multiple of what's typical, because "long" means something different for a data pipeline than a chat response. Repeated failed attempts at the same action — an agent retrying a tool call that keeps failing is often not making progress, it's stuck, and stuck agents sometimes escalate into trying alternative, riskier actions to get unstuck rather than stopping to ask. A shift into a higher-risk action category than the task should require — a customer-support agent that starts calling account-modification tools mid-conversation about a billing question has moved outside its expected behavioral envelope regardless of how confident its reasoning sounds at that point.

Any one of these, on its own, might be nothing — a genuinely hard case that's taking longer because it's genuinely hard. The point of tracking them isn't to auto-kill on the first signal, it's to have a specific, pre-agreed trigger for escalating to a decision, rather than relying on someone happening to notice a run looks off and having to make the call from scratch, under time pressure, with no criteria to lean on.

Designing the kill switch, not just having one

A kill switch that exists conceptually — "we could stop it if we needed to" — but has no defined trigger and no defined owner isn't a kill switch, it's a hypothetical. The teams that handle this well have answered three questions in advance, in writing, before the first incident forces the answer to be improvised: what specific conditions trigger a stop, expressed as measurable thresholds rather than vibes; who has the authority to pull the trigger, ideally a role or an automated system rather than "whoever happens to be watching," because waiting for the right person to notice and feel confident enough to act is exactly the delay that turns a contained situation into an incident; and what "stopped" actually means for this specific agent — does it finish the current tool call and then halt, or does it hard-stop mid-action, and which of those is actually safer given what the agent might be mid-way through doing.

That last question matters more than it initially seems. Hard-stopping an agent mid-write to a database can leave things in a worse, half-completed state than letting the current atomic action finish and then blocking the next one. Good kill-switch design has to be specific to what the agent's tools actually do, not a generic "stop everything" button applied uniformly regardless of what "everything" means for a given task.

Automating the decision where you can, not just the trigger

The hardest version of this problem is when the trigger fires and a human still has to decide, live, whether to actually kill the run — because the human, under the same time pressure and incomplete information as the agent, is prone to the same "let's give it a bit more time" instinct that got the run into a questionable state in the first place. The more robust pattern is to pre-commit the decision as much as possible: define the threshold, define the action that happens automatically when it's crossed — pause and route to human review, not silently continue — and reserve human judgment for what happens after the pause, not for whether the pause happens at all.

This mirrors the logic in the five-step incident-response playbook: containment needs to happen fast, and fast containment depends on levers that are already built and pre-authorized, not decisions that require assembling context and getting sign-off in the moment. A kill switch you have to convene a meeting to use is a kill switch that will, in practice, get used too late.

The cost of over-killing is real, but it's the cheaper mistake

It's worth being honest about the trade-off in the other direction: a kill switch tuned too aggressively interrupts genuinely fine runs, generates unnecessary human-review load, and erodes trust in the automation to the point where people start ignoring or disabling it — which defeats the purpose entirely. That's a real cost, not a hypothetical one, and it's the reason thresholds need to be set from actual historical data about what normal looks like for a given task, not picked arbitrarily out of caution.

But between the two failure modes — killing a run that would have finished fine, versus letting a run continue that goes on to do real, hard-to-reverse damage — the first is annoying and the second is the kind of thing that ends up in an audit log a regulator eventually asks about. Calibrate the threshold carefully, absolutely. But when the calibration is uncertain, the asymmetry in what each mistake actually costs should settle which direction to err.

Part of the "Running Agents in Production" series on aiskill.market.