Why AI agents get stuck on long-running tasks is a plumbing problem, not a mystery about intelligence. An agent here is an LLM-driven loop that calls tools, APIs and other models in a chain of steps, and teams increasingly run those loops as long-lived background jobs instead of quick request/response calls — a single task can run for minutes or hours and chain dozens of steps. Every step can fail, hang or time out. A naive implementation then does one of two bad things: it waits forever, which is the agent that looks "stuck", or it retries blindly and causes duplicate side effects — a double charge, a duplicate email. The repair kit is standard distributed-systems plumbing borrowed from job queues and workflow engines: hard deadlines, cleanup of orphaned processes, idempotent retries with backoff, and isolated queues so one runaway agent cannot take down the others.
Why AI agents get stuck: the arithmetic of long chains
The failure looks alarming because it is silent. The agent stops mid-task — no crash, no error message, nothing that says "done" or "failed". It is a step that never returns, and a loop with no deadline waiting on it.
The video frames the cause as arithmetic rather than a bug: at 95% reliability per step, a 20-step plan fails 40% of the time. Treat that as the illustration it is — a claim made in the script to show how per-step reliability compounds across a chain, not a measured benchmark of any product. The direction is what matters: reliability that is fine for one API call becomes unacceptable once you multiply it by the number of steps in a plan, and long-running agents keep making that number bigger.
AWS treats this as a first-class reliability risk, not an edge case. Its Well-Architected Generative AI Lens carries a dedicated best practice, GENREL03-BP02, "Implement timeout mechanisms on agentic workflows," and rates it High risk if not established.
What do hard deadlines and process cleanup mean in practice?
GENREL03-BP02 is specific about what to build. It recommends timeout controls at two levels — the individual function or tool call, and the workflow as a whole — so one hanging call cannot consume the entire run, and a run that exceeds its budget ends on purpose instead of hanging indefinitely. It recommends routing timed-out processes to dead-letter queues, so a killed task is a recorded, inspectable item rather than a disappearance. And it recommends automated cleanup and retry procedures, because a timeout that leaves orphaned processes, open connections and half-finished work behind has moved the problem rather than solved it.
If you have run background jobs before, this is familiar territory: the same reliability problem as a Sidekiq- or Celery-style worker queue, and the same question as the classic "will my HTTP request time out at the load balancer". The difference is what sits inside the job. A background job is usually a deterministic function, so a fixed timeout fits it well. An agent step is an unpredictable LLM loop whose honest duration varies run to run, so one fixed number fits badly: set it low and you kill work that was progressing, set it high and a stuck agent sits there for an hour.
Do retries repeat work, and how do idempotency keys stop it?
Retrying is the obvious response to a dead step, and it is exactly where naive implementations do real damage. A timeout tells you that you did not receive a response. It does not tell you that the call failed. If the request actually succeeded and only the answer was lost, retrying does the work twice — a double charge, an email sent twice.
The standard defence is an idempotency key attached to every external write and tied to the task ID, so a repeat of the same logical operation is recognised and collapsed instead of performed again. Combined with backoff between attempts, that is what makes a retry safe to run automatically rather than something a human has to adjudicate.
The other half is not repeating the work you already did. The materials point at durable-execution engines — Temporal is the named example — which checkpoint a run so a recovered agent resumes from where it stopped instead of restarting the whole plan from scratch. That is the difference between a stuck agent costing you a few seconds and costing you the entire chain of model calls again.
What does this cost, what does it need, and where does it stop?
Be clear about what is free here. The AWS best practice is documentation — free to read, and it prescribes patterns rather than shipping software. Everything it prescribes runs on infrastructure you pay for: workers, queues, dead-letter queues, and whichever durable-execution engine you pick. The agent itself is never free either, because the intelligence has to come from somewhere: a paid model API key, or a model you run on your own hardware. Nothing in this material is a way to avoid paying for the model.
The material names no operating system, chip, memory or VRAM figures and no prices, so treat hardware and licensing as unlisted rather than assuming this runs anywhere. There is also no repository to clone: the starting point is the AWS Well-Architected Generative AI Lens page where GENREL03-BP02 lives, and Temporal appears only as an example of the durable-execution category.
The main catch is the one named above: because an agent step is an unpredictable LLM loop, the usual fixed timeout does not fit it well, so your deadlines need tuning against real runs and will sometimes cut off work that was fine. The second limit is scope — deadlines, cleanup, retries and isolation make a stuck run recoverable; they do not make a bad plan good, and they do not help if your steps were never designed to be resumable.
Use this instead of just asking Claude in a chat window when the work is a multi-step background job with real side effects — payments, emails, writes to production systems. Don't use it if your agent call finishes in seconds inside one request/response cycle; a plain timeout is enough and the queue machinery is overhead.
Verdict: who should wire this up, and who should skip it?
If you are running agents as background jobs today, start with the cheap half: a workflow-level deadline, a per-call timeout, a dead-letter queue for what times out, and idempotency keys on every external write keyed to the task ID. That is a short list, it is what AWS rates High risk to skip, and most of it is infrastructure your team already knows how to operate.
Reach for a durable-execution engine when losing a long run is expensive — when a plan is dozens of model calls deep, or when restarting from the beginning means paying for all of it again. Checkpoint-and-resume is the feature you are buying; the price is designing steps that can be replayed.
If your agents are short, synchronous and side-effect-free, do none of this yet. The whole apparatus exists to make one outcome true: a stuck agent is killed, cleaned up, retried safely, and resumes.
FAQ
Why does a stuck agent show no error?
Because nothing has failed in a way anyone reported. A step is waiting on a call that never returns, and a loop without a deadline waits with it. No crash, no error — which is precisely why the deadline has to come from your side.
Is a fixed timeout enough?
It beats nothing, and AWS asks for timeouts at both the function and the workflow level. But a fixed number fits a deterministic job better than an unpredictable LLM loop, so expect to tune it: too low kills healthy work, too high leaves a hung run sitting there.
Will retries double-charge my users?
They can, if you retry a call that actually succeeded and only lost its response. The fix in the material is an idempotency key attached to each external write and tied to the task ID, so the duplicate is recognised and collapsed instead of executed a second time.
Is the 40% failure figure measured?
No. It is the video's illustration of how per-step reliability compounds — 95% per step across a 20-step plan — not a benchmark of a product, and not a measurement by this channel. Its point is that chain length, not step quality alone, drives how often long runs fail.
What hardware do I need for this?
The material does not list hardware requirements, prices or operating systems. What it does imply is unavoidable: you pay for the infrastructure that runs the queues and workers, and you pay for the model either through an API key or by running one on your own machine.
Sources
- GENREL03-BP02 Implement timeout mechanisms on agentic workflows — AWS Well-Architected Generative AI Lens
- Why Long-Running AI Agents Break in Production (And the Infrastructure to Fix It)
- AI Agents Don't Have a Timeout Problem, They Have a Waiting Problem
- Pydantic AI — Durable Execution with Temporal
- Fly.io — Agent Sandboxes: Isolated Runtimes for Testing AI Agent Behavior