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

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.

What to do when it trips

When you hit the limit, 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 a reframe.

Start here: see the field note on relearning, compaction, or read the method.