Why AI Agents Fail on Long Tasks: 4 Production Fixes

METR's time-horizon data and the four fixes production teams ship to keep long-running agents alive

Published 10 October 2026 Updated 10 October 2026

Why AI agents fail on long tasks is now a measured pattern rather than a hunch: the same models that finish short jobs almost perfectly succeed under 10% of the time on work that takes a human more than about 4 hours. Run agents for hours and a stall costs you compute, data and time. This article covers the four fixes production systems ship against that (hard deadlines with partial results, process cleanup, idempotent retries and isolated durable queues), and it ends with which one to ship first.

The 4-hour wall

AI agents ace 4-minute human tasks and collapse on 4-hour ones. The gap comes from METR, a research group that measures how long a task an agent can finish. Their March 2025 paper, Measuring AI Ability to Complete Long Tasks, found models near 100% successful on tasks that take humans under about 4 minutes, while success fell under 10% on tasks that take humans more than about 4 hours. These are METR's own measurements, not a vendor's claim.

The horizon also keeps moving. METR found the length of task agents can finish half the time doubling roughly every 7 months since 2019. In February 2026, Claude Opus 4.6 reached a time horizon of about 14.5 hours on METR's benchmark. That is more than a full human workday.

Here is the trap. Better models get handed longer jobs, and longer jobs are exactly where agents stall. The stronger your agent gets, the more your infrastructure has to catch it when it fails.

Why AI agents fail on long tasks: small risks compound

Start with simple arithmetic from a write-up on timeout-aware agent design. Give a task a 99% chance of surviving each minute. Over a 60-minute job, its chance of finishing without interruption drops to about 55%. Nothing dramatic has to go wrong; small risks just pile up.

Time also leaks before the work begins. A reference on agent time limits describes agents burning 75 seconds of a 300-second budget on initialization, and puts bootstrap overhead at 30 to 40% of the total budget in production systems. That is the guide's own figure, not a controlled benchmark.

Teams react with blunt caps. Production LangChain agents commonly stop at 5 to 8 iterations, and Cox Automotive halts its agents at roughly 20 conversation turns, finished or not. Caps stop runaway loops, but they also cut off honest work.

Then there is the clock outside the agent. Long sessions can outlive access tokens, idempotency windows, deploy cycles and retry budgets. That is why guidance for the Claude Agent SDK says durable execution, retries and coordination must be built outside the SDK. The four fixes below are that outside layer.

Fix one: hard deadlines with partial results

The first fix is a deadline the agent knows about. The timeout-aware design guide recommends a soft signal before the hard cut: at the timeout minus a buffer, you tell the agent how many seconds remain. It then consolidates its best current answer instead of being cancelled mid-thought.

The second half is a partial-result schema. Fields are optional, and a status envelope says the status is partial, lists completed steps and missing steps, and gives the reason as timeout. A timeout now produces something usable instead of silence.

There is a line you cannot cross. Reads, like research or summaries, can degrade to partial results. Writes, like payments, migrations or notifications, need complete-or-nothing rules, enforced before execution begins. A half-sent payment is not a partial result; it is an incident.

This fix costs nothing but design time. The catch is that it only works if the agent is still responsive enough to hear the signal. When it is not, you need the next fix.

Fix two: killing what the agent spawned

When you kill an agent, you do not necessarily kill what it started. Its child processes can keep running. Sandbox guidance for agents converges on one rule: run each job in an ephemeral, isolated container with hard CPU, RAM and time limits. If an agent loops, kill it.

For the kill itself there is Corral, an open-source command-line tool on GitHub under Cardinal44. It runs a command under a wall-clock limit, and before returning control it verifies that every process the command started has actually exited. Corral is MIT licensed and free, and nothing in the project ties it to a paid service.

It needs Linux. The enforced mode uses cgroup v2 controls on kernel 5.14 or newer; without cgroups it falls back to scanning proc and using pidfds on Linux 5.11 or newer. Between the polite stop signal and the forced kill it waits 2 seconds by default.

The exit codes are the useful part. Corral returns 124 on timeout and 120 when process verification fails. That second code exists to catch daemons that call setsid to escape their process group, or that ignore termination signals. This behavior comes from the project's own documentation, not an independent test.

The catch: everything here is a Linux kernel feature, and the project describes no macOS or Windows path. The material does not describe an install step beyond the repository either. Use it instead of the plain timeout command when a stray child process would poison the next run. Do not use it if your jobs already run in throwaway containers that die whole.

Fix three: retries that don't charge twice

An agent that retries a payment after a crash can pay twice. Production guidance for agentic systems requires every mutating tool call to carry three things: an idempotency key that stays stable across retries, an operation hash of the normalized arguments, and a request time-to-live that sets the replay window.

The rule is simple. Same key and same hash returns the cached result. Same key and a different hash is rejected as a conflict. The agent can retry blindly and the side effect still happens once.

Retry only what can heal. Transient failures qualify: HTTP 429, 5xx errors, network resets and lock timeouts, handled with exponential backoff and jitter. Validation errors, 401 and 403, and schema violations never get an automatic retry.

When a later step fails, undo the earlier ones. The guidance's worked example is an order: reserve inventory, charge the card, create the shipment. A failed charge releases the inventory. A failed shipment triggers a refund plus the release. A failed refund goes to a human.

Long runs stretch all of this. API design advice for 18-hour Claude agent sessions says to extend idempotency windows beyond one day, to bind jobs to principals rather than token instances so they survive credential rotation, and to send a Retry-After header on every 429 response.

Fix four: queues that survive a crash

The fourth fix separates accepting work from doing it. Slow operations go to a job queue that hands back a job ID immediately, and the agent polls the status later instead of holding a request open indefinitely.

Durable execution goes further. Temporal is an open-source platform that records every workflow step as an immutable event in an append-only history. If a process crashes mid-task, Temporal replays that log and resumes from the last completed step. Temporal's own write-up contrasts this with single-process agent frameworks, where a crash means rebuilding context from scratch.

The receipts here are vendor material. Temporal reports 99.999% trailing 30-day uptime for Temporal Cloud and names OpenAI among its users, for ChatGPT image generation and Codex. In a Temporal case study, the agent company Lindy says it replaced its in-house BullMQ queue system and now runs roughly 2.5 million Temporal actions a day. Its Head of Engineering, Luiz Scheidegger, said of the old setup: "We rolled out a complex in-house system just to deal with execution failure. But it wasn't durable, reliable, or observable."

On cost, Temporal is open source and Temporal Cloud is the hosted service. The material gives no Cloud pricing and does not list hardware requirements for running it yourself. The main catch is migration: Lindy had to replace a whole execution system to adopt it. Use it instead of a homegrown queue when a crash must resume, not restart. Do not use it if your tasks finish in minutes and a retry from zero is cheap.

Which fix to ship first

If your agent hangs silently, start with deadlines and a partial-result schema. It is the cheapest fix, and it turns silence into an answer. If killed runs leave processes behind that break the next run, add process-tree cleanup, with Corral on Linux or a disposable container per run.

If your agent writes to anything with money or users behind it, add idempotency keys and compensating actions before you add more retries. If jobs run for hours and a crash means starting over, move them to a durable queue. With METR measuring 14.5-hour horizons, that last case is where agents are heading.

Sources