Why Agents Lose 15-30% of Long-Running Tasks

Context Window Exhaustion

The most common failure mode is running out of context window capacity. A complex agent task involves dozens of tool calls, each adding hundreds or thousands of tokens to the conversation. A file read returns 2,000 tokens. An API response returns 500 tokens. The agent's own reasoning adds 200 to 500 tokens per step. After 30 to 40 tool calls, a 200,000-token context is half full, and the agent starts losing access to information from early in the conversation.

The failure manifests as the agent re-investigating something it already checked, making a decision that contradicts an earlier decision (because it cannot see the earlier one), or asking the user a question it already asked. These are not reasoning failures; the LLM would make the right decision if it could see the relevant earlier context. They are memory failures: the information fell off the accessible portion of the context window.

The fix is offloading important findings to persistent memory as they are discovered. Instead of relying on the conversation to hold all context, the agent stores key facts, decisions, and results in a memory store and retrieves them when needed. This keeps the conversation focused on the current step while ensuring that earlier findings are available on demand.

State Drift

State drift occurs when the agent's internal model of the task gradually diverges from reality. The agent decides on step 5 that it will use approach A. By step 15, the context has shifted, and the agent begins following approach B without recognizing the contradiction. The final output is a Frankenstein of approaches A and B that is internally inconsistent.

This happens because LLMs do not maintain explicit state; their "state" is the conversation context, which is reinterpreted at every step. If the conversation is long enough that the original decision (approach A) has scrolled far up in the context, the LLM at step 15 may not attend to it strongly enough to maintain consistency. It effectively makes a fresh decision based on the local context around step 15, which may favor a different approach.

The fix is explicit state tracking. The agent maintains a structured state document (the plan, current step, key decisions with rationale) that is injected into every LLM call. This ensures that the plan and all decisions are always visible, regardless of how long the conversation has become. Persistent memory supports this by storing the plan and decisions durably, so even if the agent crashes and restarts, it resumes with the same plan rather than generating a new one.

Cascade Errors

Agent execution is sequential: each step depends on the results of previous steps. If step 3 produces an incorrect result (misidentifying a root cause, using the wrong metric, reading the wrong file), every subsequent step builds on that error. By step 15, the error has compounded through 12 steps of reasoning and the final output is deeply wrong in a way that is hard to diagnose because the root cause is far from the symptom.

This is worse for agents than for human workflows because humans naturally double-check intermediate results while agents proceed with confidence from whatever their last tool call returned. An agent that reads a file and misinterprets the content treats its interpretation as fact for all subsequent reasoning, never revisiting or questioning it.

The fix involves verification checkpoints at critical stages. After the agent produces an intermediate result that future steps depend on, inject a verification step that checks the result's plausibility. Memory supports this by providing a reference for "what is normal." If the agent stores past observations about the system, it can compare the current finding against historical baselines. An API latency of 8 seconds should trigger a sanity check if past observations show typical latency of 50ms.

Interruptions Without Persistence

Long-running agents encounter interruptions: API rate limits, service timeouts, LLM provider errors, process restarts from deployments, and container evictions. Without state persistence, each interruption terminates the agent and all progress is lost. The task restarts from zero, which means the agent does the same work again, hits the same interruption point, and enters a failure loop.

The fix is checkpointing. The agent writes its progress to durable storage at regular intervals. When it restarts after an interruption, it resumes from the last checkpoint rather than starting over. Combined with persistent memory for knowledge and explicit state for plan tracking, checkpointing makes agents resilient to the interruptions that are inevitable in production environments.

The Compound Effect

These four failure modes interact. Context exhaustion makes state drift more likely because the agent cannot see its earlier decisions. State drift makes cascade errors more likely because the agent changes approach mid-task without recognizing the inconsistency. Cascade errors make interruptions more damaging because the agent may have done significant work based on an incorrect intermediate result, and that work cannot be reused after a restart.

The compound effect is why long-running task failure rates are so high. A 5% chance of context exhaustion, a 10% chance of state drift, a 5% chance of cascade error, and a 10% chance of interruption do not add to a 30% failure rate. They multiply: each failure mode enables the others, and the combined probability is higher than the sum of individual probabilities for tasks that run long enough to encounter multiple risk factors.

Persistent memory addresses all four failure modes simultaneously. It offloads context to prevent exhaustion. It stores decisions to prevent drift. It records historical baselines that catch cascade errors. And it persists progress to survive interruptions. This is why adding a memory layer to an agent system typically reduces long-running task failure rates by 50 to 70%, even when no other changes are made to the agent logic.