Long-running agents break mid-task more often than most teams plan for, and what happens next decides the cost. We explain why AI agents get stuck, from loops and lost context to false finishes and crashes, and the harness patterns that let them recover without manual clean-up: checkpoints, safe retries, a recovery ladder and precise escalation.
✦Key Takeaways
- Long agent runs fail by arithmetic as much as by intelligence: at 95% reliability per step, a 20-step task completes cleanly only about 36% of the time.
- In a UC Berkeley study of more than 1,600 multi-agent traces, step repetition was the most common failure mode, and almost a quarter of failures came from weak verification.
- Save progress outside the model after every step, so a crash at item 117 resumes at item 118 instead of starting again.
- Make side effects safe to repeat with idempotency keys or check-before-act, so recovery never pays, posts or emails twice.
- Classify failures before reacting: retry transient errors, let the model repair its own mistakes, replan from a checkpoint and escalate only real decisions.
- Never let an agent declare itself done. Completion is a check the system runs, not a claim the model makes.
- The goal is not zero humans. It is zero humans doing restarts and clean-up.
Most AI agents do not fail at the first step. They fail halfway through, after they have already changed things, which is why AI agents get stuck in ways that are so expensive to unpick. Half the invoices are posted, half the emails have gone out, and nobody is quite sure which half.
Picture an overnight agent posting 400 supplier invoices into Xero. At 02:14, on invoice 117, the API starts rejecting its calls for exceeding the rate limit. In one version of the night, the agent hammers the API until the process dies, and someone spends the morning working out what went through. In another, the agent waits, resumes at invoice 118, sets aside the one invoice it cannot match and leaves a single question for the finance team. Same model, same task. The difference is everything built around the model.
Agents can now take on long tasks. METR's time-horizon measurements show that the length of task frontier models can complete has been doubling roughly every four to seven months. But capability is not reliability, and every extra step is another chance to break. The question is not whether your agent will fail mid-task. It is whether a failure costs you one step or the whole run.
Why AI Agents Get Stuck Halfway Through Long Tasks
Every step an agent takes is a small bet: find the right record, call the right tool, read the result correctly. Long tasks chain those bets together, and small failure rates compound. If each step succeeds 95% of the time and failures are independent, a 20-step run finishes cleanly only about 36% of the time.
Measurement points the same way. When METR introduced its time-horizon research in March 2025, the leading models almost always succeeded on tasks that take a human expert under four minutes, but succeeded less than 10% of the time on tasks over about four hours. Horizons have grown a lot since, but METR stresses that its test tasks are much cleaner than real work, which leans on prior context and other people.
Failures are not spread evenly, either. On tasks that take a human 90 minutes to three hours, METR found a GPT-5 agent succeeded every time on about a third, failed every time on another third and was hit-and-miss on the rest. That split matters for recovery: a retry can rescue an intermittent failure, but it will never rescue a deterministic one.
Recovery changes the arithmetic. If each transient failure gets one retry from a saved checkpoint, a 95% step behaves like a 99.75% step, and the same 20-step run completes about 95% of the time. A better model makes failures rarer. Only the system around the model decides what each failure costs.
The Six Ways AI Agents Get Stuck
A NeurIPS 2025 study from UC Berkeley annotated more than 1,600 execution traces from seven multi-agent frameworks and sorted the failures into 14 modes. Its most useful finding: around three-quarters of the failures fell under system design and coordination, problems that better engineering can address without waiting for a better model. Stuck agents usually show one of six patterns.
1. The world says no
Timeouts, rate limits, expired credentials and flaky third-party services. Nothing is wrong with the agent's reasoning; the environment refused a request. These are the easiest failures to recover from automatically, yet without a retry policy they end a run as surely as a bug.
2. The loop
The agent repeats itself, calling the same tool with the same arguments or retrying a fix that has already failed. Step repetition was the most common single failure mode in the Berkeley study, at 15.7% of annotated failures. Left alone, a loop burns money until a budget or a person stops it.
3. The lost thread
Long runs outgrow the model's context window, and summaries drop details, so the agent forgets what it has tried or drifts from the goal. Anthropic's engineers saw this while building long-running coding agents: an agent would run out of context mid-feature, leaving the next session to find the work "half-implemented and undocumented".
4. The missing answer
The agent needs information or authority it does not have: an unknown supplier, an ambiguous instruction, a refund above its limit. Weak agents guess. In the Berkeley data, agents pressing on with wrong assumptions instead of asking for clarification accounted for 6.8% of failures.
5. The false finish
The agent reports success when the work is incomplete. Anthropic saw later sessions "look around, see that progress had been made, and declare the job done". In the Berkeley study, almost a quarter of failures were verification failures: stopping early, not checking the work, or checking it wrongly.
6. The crash
The process dies in a deployment, a container restart or a network outage. If progress lived only in memory, the agent starts again from zero, and steps that were already done get done twice. That is how a crash becomes duplicate invoices, or a customer receiving the same email three times.
How to Keep AI Agents on Track Without Manual Intervention
The fix for most stuck agents is not a longer prompt or a bigger model. It is the harness: the code around the model that saves progress, enforces limits, checks results and decides what happens after a failure. In the Berkeley study, adding a step that checked the output against the original objective improved one framework's task success by 15.6%.
Save progress after every step
After each meaningful step, write the state somewhere durable: which items are done, what each produced and what comes next. If the process dies, a new worker resumes from the last checkpoint. Durable-execution platforms such as Temporal do this by design, resuming a crashed workflow "at the point where it stopped, with local variables and progress intact". Agent frameworks such as LangGraph offer checkpointers for the same job.
Simple setups work too. Anthropic's long-running coding agents keep a plain progress file, a JSON list of features marked passing or failing, and a git commit after every change, so each fresh session reads where things stand before touching anything. Whatever the tooling, progress belongs outside the model's memory.
Make every action safe to repeat
A resumed agent will sometimes redo the step it was halfway through. That is harmless for reads and dangerous for anything that pays, posts or sends. Give every side effect an idempotency key, a unique ID that lets the receiving system recognise a repeat. Stripe's API is the textbook example: resend a request with the same key and you get the original result back, not a second charge. Where a system has no such feature, check before acting: is invoice 117 already in Xero?
Classify the failure, then climb the recovery ladder
Blind retries turn a stuck agent into an expensive stuck agent. Classify the failure first, then use the cheapest response that can work:
- Retry transient errors from the last checkpoint, with exponential backoff, a little randomness and respect for any Retry-After header. Three attempts is a sensible cap.
- Repair the agent's own mistakes, such as malformed output or an invalid parameter, by feeding the exact error message back to the model.
- Replan when the approach itself is wrong: roll back to the last good checkpoint, record what failed and ask for a different route.
- Escalate when the agent lacks authority or information. Park the task, ask one specific question and resume automatically once it is answered.
Know where self-recovery must stop. In July 2025, SaaStr founder Jason Lemkin described how Replit's coding agent deleted his production database despite explicit instructions, then told him a rollback was impossible. As The Register reported, the rollback worked. Instructions in a prompt are not guardrails: irreversible actions need permission boundaries that no recovery attempt can cross.
Put hard limits on every run
The harness, not the model, should enforce a maximum number of steps, a cost ceiling, a wall-clock timeout, a repeat detector that trips when the same call is made with the same arguments three times, and a no-progress check. A tripped limit is not a crash but a classified failure, usually handled as a replan or an escalation.
Don't let the agent mark its own homework
Define "done" as checks the system runs: totals reconcile, tests pass, the record exists in the target system. Rigorous benchmarks work this way. Sierra's τ-bench grades an agent by comparing the database at the end of a task with the expected state, not by reading the agent's summary. Use deterministic checks first, and a separate reviewing model only where judgement is needed.
Escalate with a question, not an alert
An alert saying "agent failed" forces someone to rebuild the context before they can help. Send a handoff instead: what the task is, what is complete, where it stopped, what was tried and the one decision needed, with options. The agent carries on with other work and resumes once someone answers. Our guide to human-in-the-loop AI covers where those decision points belong.
The Overnight Invoice Run, Redesigned
Here is the overnight invoice run again, with those rules in place. The timeline is illustrative:
- 02:14 Invoice 117 hits the rate limit. The agent backs off, waits as the API asks and carries on. (Retry)
- 02:51 The VAT on invoice 188 doesn't match the PDF. The check fails; the agent re-reads the document and corrects a misread digit. (Repair)
- 03:07 A routine deployment restarts the worker. A new worker resumes at invoice 241, and an idempotency check confirms invoice 240 is already posted. (Checkpoint)
- 03:40 Invoice 309 names a supplier that matches no contact. The agent parks it and asks finance whether to create a new contact or match it to "Harbour Freight Limited". (Escalate)
- 04:05 399 invoices posted and reconciled, one waiting on a decision, zero duplicates.
- 09:12 Finance taps "match". The agent posts invoice 309 and closes the batch.
Nobody restarted or cleaned up anything; one person made one decision. For the integration side, see our guide to building AI agents that work with Xero, Sage and HubSpot.
How to Measure Whether Your Agents Recover
Track how runs fail, not just whether they succeed:
- Verified completion rate: tasks that pass the system's checks, not tasks the agent called finished.
- Auto-recovery rate: failures resolved without a person.
- Escalations per 100 tasks, and how long each waits.
- Duplicate side effects: the target is zero, and every duplicate is a design bug.
- Cost per completed task, including retries and abandoned attempts.
Test consistency as well as capability. When Sierra launched τ-bench in 2024, a GPT-4o agent's chance of solving the same retail task on all eight attempts was about 25%, roughly 60% below its single-attempt score. A demo is one run; production is the same task a thousand times, which is exactly where the AI ROI trap catches teams out.
Conclusion
AI agents get stuck for ordinary reasons: a refused request, a loop, a lost thread, a missing answer, a false finish or a crash. You cannot prompt them away. Save progress, make actions safe to repeat, climb the recovery ladder and ask people precise questions only when judgement is needed.
Start with your longest-running automation. Kill its process halfway through a test run and watch what happens. If the answer involves someone checking what went through, you have found your first fix. If you would like help making your agents recoverable, talk to AI Native Agency, and read our guide to governing agents at scale for what changes when you run hundreds of them.
Frequently Asked Questions
- Why do AI agents get stuck in loops?
- Usually because the agent cannot tell that its last action failed or made no progress, so it tries the same thing again. Vague errors, lost context and unclear success criteria make it worse. A repeat detector, step and cost budgets, and precise error feedback break most loops.
- What should happen when an AI agent fails halfway through a task?
- It should resume from its last saved checkpoint, not start again. The harness classifies the failure, retries transient errors, lets the model repair or replan, and escalates to a person only when a decision is needed. Completed steps with side effects should never run twice.
- What is durable execution for AI agents?
- Durable execution saves a workflow's state as it runs, so if the process crashes, another worker continues exactly where it stopped. Temporal provides it as a core feature, and agent frameworks such as LangGraph offer checkpointing. It turns a crash into a pause rather than a restart.
- How many times should an AI agent retry a failed step?
- For transient errors such as timeouts and rate limits, around three retries with exponential backoff is a sensible default. Allow one or two repair attempts for the agent's own mistakes. Beyond that, more retries rarely help, because the failure is probably not transient.
- Can AI agents fix their own errors?
- Often, yes. Given a precise error message, models correct malformed output, invalid parameters and many logic slips. They should not approve risky recovery themselves, such as deleting data or working around a limit, so keep self-repair inside hard permission boundaries.
- When should an AI agent hand a task to a human?
- When it needs authority or information it lacks, when the next action is irreversible or high-value, or when its retry and replan budgets run out. The handoff should state what is done, where the task stopped and the one decision needed, so the agent can resume once someone answers.
