ArticlesMethod

The 30-minute debug limit: when to stop the agent

An agent stuck on a bug will burn an hour going in circles. The pilot's move is a time limit and an escalation.

Stuart LeoJune 8, 20264 min read

Watch an AI agent debug a stubborn problem and you'll see something unsettling: it doesn't get tired, doesn't get frustrated, and doesn't know when to stop. It will try the same kind of fix twenty times, each with total confidence, burning time and tokens, going nowhere. A human would have stepped back after the third try. The agent won't, unless you make it.

The pilot's tool for this is a simple rule — a debug limit — and the discipline to act when it trips. Here's how to use it.

How agents get stuck in loops

An agent debugging a hard problem tends to explore a narrow neighbourhood of solutions. It forms a theory, tries it, fails, tweaks slightly, tries again. When the theory is wrong, "slightly tweaked" versions of it are all wrong too — so it loops, generating variations on a doomed approach.

What it almost never does on its own is the thing a good developer does: stop, zoom out, and question the framing. The agent lacks the instinct to say "I've been at this too long, the whole approach is probably wrong."

Why more attempts make it worse

Here's the part that's counterintuitive. With a stuck agent, more attempts actively make things worse — not just wasteful, worse.

Every failed attempt piles more text into the context window: the broken code, the error, the reasoning that didn't pan out. The window fills with the history of failure, which both crowds out the original problem and nudges the agent to keep reasoning along the same failed lines. It rots its own context with its own dead ends — a failure mode familiar to anyone building long-running agents. By attempt fifteen it's not just stuck — it's confused, on top of stuck.

Stuart Leo

Letting a stuck agent keep trying isn't patience. You're feeding it its own failures until it can't see the problem anymore.

The 30-minute limit as a rule

So set a limit. Thirty minutes of wall-clock grinding on a single bug is plenty — past that, the odds of the next attempt succeeding have dropped, not risen. The exact number matters less than having one. The point is to convert "the agent is still trying" from a comfort into a trigger.

When the limit trips, the rule is firm: the answer is not another attempt. It's a change of strategy.

Name the layer before you escalate

There's one step before the escalation, and skipping it is how a 5-minute fix becomes a 40-minute one.

The limit says stop. It doesn't say stop and look at what, so the default is to reach for whatever you touched most recently — which is nearly always the instructions. I've rewritten a prompt for 20 minutes when the real problem was an expired token.

So before you do anything, name the layer that owns the failure:

What you're seeingThe layer that owns it
Cannot operate — missing tool, stale state, bad permissions, no visibilityThe environment
Almost works but unreliable — close-but-weak output, inconsistent success, no proof it finishedThe loop and its stop rule
The process itself is complex — several specialisms, approvals, branching, work that keeps getting droppedThe topology

Cheapest first, rarest last. Check whether it could physically do the job before you assume it couldn't think — an agent that can't reach something doesn't stop, it writes a plausible sentence about what would probably be there. Only the middle row is a prompt problem, which is why the reflex to rewrite instructions gets it right about a third of the time. The full triage is here.

What to do when it trips

Once you know the layer, three moves, roughly in order:

  1. Fresh context. Start a new session. The failed attempts stop polluting the window, and the agent meets the problem clean. This alone fixes a surprising amount — half the time the agent was drowning in its own dead ends.
  2. Reframe. Restate the problem yourself, plainly. Often the agent was solving the wrong version of it. A sharper framing points it somewhere new.
  3. Escalate. Try a different approach, a stronger model, or your own eyes. Some bugs want a human or a bigger brain, and that's fine — knowing when is the skill.

This is the Pilot model in miniature: a crew member grinds for three hours, a pilot calls the limit and changes course.

Capturing the fix as a gotcha

When you do crack it, don't let the cost vanish. Write the bug and its fix into your contextbase as a gotcha — what it looked like, why it was hard, what actually worked. A bug that cost you forty minutes today should cost the next session zero. That's the whole compounding bet: pay once.

When the agent's been stuck 30 minutes, the answer isn't another attempt — it's naming the layer, then a reframe.

Start here: see which layer broke your agent, the field note on relearning, or read the method.

FAQ

Why do AI agents get stuck debugging?
Because they keep trying variations of the same approach without stepping back. Each attempt adds more failed context to the window, which makes the agent more confused, not less — so it spirals. More attempts often make it worse, not better.
What is the 30-minute debug limit?
A rule that caps how long an agent grinds on one bug before you intervene. When it trips, you don't ask for another attempt — you reframe the problem, give the agent fresh context, or escalate to a different approach or model. The limit forces a change of strategy instead of more of the same.
What should I do when an agent is stuck on a bug?
Stop the loop, then name the layer that owns the failure before you touch anything. Could it physically operate — tools, credentials, permissions? Did it know what finished looks like? Or was the job the wrong shape for one pass? Then escalate into that layer: fresh session, a clear restatement, a different angle or a stronger model. Capture the eventual fix as a gotcha so it never costs you that time again.