Most agent projects are designed for short tasks such as running a query, summarizing a document or generating a pull request. At those timescales, the model carries the load and most failures are shallow enough to catch and retry. But the frontier for autonomous agents has moved, and teams are now running agents for hours across fragmented data systems under significant production constraints. And at that timescale, organizations are discovering that a different class of failure takes over. It’s a particularly acute problem as the industry works towards enabling recursive self-improvement (RSI), where AI builds better models largely autonomously.
Earlier this year, for example, Anthropic published a rare post-mortem on Claude Code degradation, tracing quality complaints across weeks to a sequence of compounding changes. The sequence included a reasoning effort downgrade, a caching bug that made Claude forget its own prior reasoning mid-session and a verbosity prompt that broke coding quality. In another development, GitHub is moving Copilot to usage-based billing because agentic workloads are burning compute in ways that flat subscriptions can’t absorb. They are early signals of a structural problem the industry is only beginning to address.
Where Long-Running Agents Break Down
One of the main causes of long-horizon failure is that agents are unreliable judges of their own work. When an agent can decide whether a task is complete, it will often declare success on partial runs and unvalidated outcomes. We saw this directly in our own systems. The agent would claim a successful submission, but nothing had been validated against the actual evaluator. Anthropic has reported the same pattern in their own experiments with long-running agents. The problem is not one of reasoning, but rather architecture. The agent that writes the code should not be the agent that grades it. Evaluation cannot live inside the same process that produced the work.
Agents also overcommit to failing strategies. In one of our runs, the execution agent spent roughly 14 hours on a multi-stage training approach with cross-validation and stochastic weight averaging. A separate run on the same task reached the same performance tier in under three hours by trying 19 simpler alternatives. The first agent was not confused, just committed to the wrong path with no supervisor forcing a change of course. The opposite failure is just as costly, where an agent that treats a task as infeasible because its current strategy is failing instead of trying a different strategy. Both failures share the same root cause. The execution agent is judging its own trajectory from the inside.
The Amnesiac Agent Issue
Another persistent failure mode in long-running agents is that they have no durable institutional memory. If an agent uncovered a hidden dependency yesterday, or an engineer corrected a bad assumption last week, that knowledge dies when the session ends. The next agent starts from scratch, repeats the same exploratory loops, hits the same dead ends and has no way to know any of it happened before.
The instinct is to solve this by storing everything, but raw memory without context produces noise with timestamps. Records that were accurate when written become stale, duplicated or framed in ways that can destructively bias future runs. In one of our own classification runs, for instance, the agent retrieved 10 accurate memories about prior environmental constraints which included GPU memory limits, multi-worker errors and training-time estimates near 140 hours. The agent concluded the environment was hostile and stayed inactive for 12 hours. The actual fix, disabling multi-worker , took about 10 minutes to rediscover. The memories were factually correct, but the framing made the task look impossible.
This is the trap of append-only memory. Every failure gets logged, and every constraint gets preserved, but no process decides whether a record is still true, relevant or accurately framed. What agents actually need is a curation policy built into the memory layer itself, which requires actively removing records that are outdated, duplicated or misleadingly framed, and preserving failure modes only when they include a root cause and a path forward. Additionally, human corrections and confirmed resolutions should be weighted more than anything an agent wrote about itself mid-run.
The Fix Is Architectural
What long-running agents actually need is a harness that provides supervision, along with a context graph that preserves institutional memory within its proper context. Trajectory control, which is the decision to continue, pivot or stop, should sit in a supervisor with a view across the full run. Memory should be actively curated inside a context graph that links prior decisions, failed experiments and resolved constraints back to the surrounding data, code and execution records that give them meaning. In this way, the agent inherits structured, searchable precedent rather than a flat log of things that went wrong.
The industry will not solve this by waiting for better models. A stronger model running inside a poorly designed harness still declares success on unvalidated work, still overcommits to failing strategies and still inherits bad memory. The model is one component of the system, not the whole system. The enterprises and engineering teams that understand this distinction now will be running agents reliably at scale and best positioned to automate AI model development through RSI. The ones that don’t will keep paying for compute that runs in circles without producing results.