Ask a coding agent to fix a bug and it usually does fine. Ask it to build or migrate something that takes hours, across more context than fits in one window, and the failure changes shape. The model did not get less capable. It lost the thread.
Long-running AI agents fail mostly because each new session starts with no memory of the last one, so work is left half-finished or declared done too early. The fix is a better harness, not a better model. A harness is the code and conventions around the model that decide what it sees, what it writes down between sessions, and how it proves a piece of work is finished. We build agentic delivery pipelines, and we watch the same model produce production-quality work or expensive drift depending on that harness.
Why do long-running AI agents fail?
Long-running agents fail at the handoff between context windows, in two predictable ways. Anthropic documented both in its November 26, 2025 engineering post on effective harnesses for long-running agents. Even a frontier model, Claude Opus 4.5 running in a loop across multiple context windows, fell short of building a production-quality web app from a high-level prompt.
Doing too much at once. The agent tried to build the whole app in one pass. It ran out of context mid-implementation and left the next session a half-built, undocumented feature. That session had to guess what happened and spend time getting the app working again.
Declaring victory early. Later in the project, a fresh session looked around, saw real progress, and declared the job done. It had no plan to check against, so "looks finished" became "is finished."
Neither is an intelligence failure. Both are memory failures. Anthropic's analogy is a project staffed by engineers working in shifts, where each new engineer arrives with no memory of the previous shift. The job is not a smarter engineer. It is a shift change that does not lose information.
What a working agent harness does
A working harness writes the scope down once, makes every session leave a clean handoff, and makes the agent prove its work. In Anthropic's experiments, three pieces did that.
An initializer that writes the scope. An initializer agent runs once and sets up the environment. It writes a feature list file with every feature marked as failing, so later sessions can tell finished from unfinished. Sessions change only each feature's pass status. Anthropic chose JSON over Markdown for that file because the model was less likely to overwrite JSON inappropriately.
One feature per session, then a clean handoff. Each session works on one feature. It commits to git with a descriptive message and updates a progress file. The next session reads the git log and the notes instead of guessing.
Verification as a user would do it. Left alone, the agent made changes, ran unit tests or curl commands, and still missed that a feature did not work end to end. With browser automation tools and an explicit instruction to test as a human user would, it mostly verified features correctly.
The capability was already in the model. What was missing was discipline: decompose, checkpoint, prove. That discipline lives in the harness.
Will a bigger context window fix it?
A bigger context window pushes the wall back but does not remove it. Anthropic's companion post on context engineering for AI agents, published September 29, 2025, describes context rot: as the number of tokens in the window grows, the model's ability to recall information from it falls. Every model has an attention budget, and each new token spends some of it.
The durable techniques manage context instead of growing it. Compaction summarizes a nearly full window and starts a fresh one with the summary. Structured note-taking stores progress outside the window and pulls it back when needed, which is what the progress file does. Sub-agents take focused tasks with clean context and return only a condensed summary to the coordinator. These are design choices about where state lives and how it moves.
Two other agent problems are separate. Review discipline decides whether agent output gets checked before it ships, which we cover in what holds up with AI coding agents in production. Operational visibility decides whether you can see and constrain a deployed agent, the subject of why AI agents stall in production. State continuity sits upstream of both. If the work drifts between sessions, review and observability have nothing coherent to act on.
What to ask before you run agents on multi-hour work
Three questions separate a real harness from a demo. Ask them of any vendor or internal team that proposes agents on work longer than one session.
- How is scope written down before the agent starts, and can a later session tell finished from unfinished against it?
- How does each session hand off to the next, and what happens when one dies mid-task?
- How does the agent prove a piece of work is done, not just plausibly done?
Credible answers sound like feature lists, checkpoints, progress logs, and end-to-end verification. Weak answers sound like "the model is really capable now." It probably is. That was never the part that failed. Harness design is core to our AI implementation framework, and it is where an agent project earns its result or quietly loses it.