Ask a modern coding agent to fix a bug and it will usually do fine. Ask it to build or migrate something that takes hours, spanning more context than fits in a single window, and the failure mode changes shape. It is no longer "the model was not smart enough." It is "the model lost the thread." That distinction matters, because the fix is not a better model. It is a better harness.
We build agentic delivery pipelines, so this is the difference we watch closely: the same model produces production-quality work or expensive drift depending entirely on the scaffolding around it. If you are evaluating a vendor's agentic delivery, or standing up internal agents that have to run longer than one sitting, the scaffolding is what you should be interrogating.
The two ways long-horizon agents come apart
Anthropic published a useful field report on this in effective harnesses for long-running agents. Even a frontier model running in a loop, they found, falls short of building a real application from a high-level prompt, and it fails in two specific ways.
The first is one-shotting. The agent tries to do everything at once, runs out of context in the middle of an implementation, and leaves the next session to inherit a feature that is half-built and undocumented. The next agent then burns time guessing what its predecessor was doing and trying to get back to a working state.
The second shows up later in a project. An agent starts a fresh session, looks around, sees that real progress has been made, and declares the job done. There was no plan it was checking against, so "looks finished" became "is finished."
Neither of these is an intelligence failure. Both are memory failures. Each session starts with no recollection of the ones before it. Anthropic's own analogy is a project staffed by engineers working in shifts, where every new engineer arrives with no memory of the last shift. The problem to solve is not making each engineer smarter. It is making the shift change not lose information.
What a working harness actually does
The pattern that held up in their experiments is worth knowing, because it tells you what to look for in any serious agentic setup.
A specialized initializer runs once and sets up the environment for all the work to come. Critically, it writes down the full scope up front as a structured list of concrete, testable features, each marked as not-yet-passing. That list is what stops a later agent from declaring victory early, because "done" now has a definition it can check against rather than a vibe.
Every session after that is told to make incremental progress on one feature at a time, then leave the environment in a clean state: work committed with a clear message, and a progress file updated so the next session can get its bearings from the git log and the notes instead of guessing. Anthropic found the model was even less likely to corrupt a structured JSON feature file than a Markdown one, which is the kind of detail you only learn by running these things at length.
The last piece is self-verification. Left alone, an agent will mark a feature complete after a unit test or a curl command, without confirming it works end to end the way a user would touch it. Giving the agent real testing tools, browser automation in their web-app case, and explicitly requiring it to verify as a user closed most of that gap. The recurring theme: the intelligence was already there. What was missing was the discipline to decompose the work, checkpoint it, and prove it, and that discipline lives in the harness.
State continuity is a design problem, not a bigger window
The instinct when an agent runs out of room is to wait for a larger context window. That is the wrong bet. Anthropic's companion piece on context engineering makes the case plainly: recall degrades as a window fills, an effect they call context rot, so every model has an attention budget that longer context quietly depletes. Bigger windows push the wall back; they do not remove it.
The durable techniques all treat context as something to manage rather than something to grow. Compaction summarizes a nearly-full window and reinitializes a fresh one with the distilled state. Structured note-taking persists progress outside the window and pulls it back when needed, which is exactly what the progress file in the harness is doing. Sub-agent architectures hand focused work to specialists with clean context and return only a condensed summary to the coordinator. These are engineering choices about where state lives and how it moves, and they are the choices that determine whether an agent can work for hours without drifting.
Why this is a different failure than the ones you have read about
Two related problems get discussed a lot, and it is worth keeping them separate. One is review discipline: whether an agent's output gets checked before it ships, which is the subject of agentic coding in production. Another is operational visibility: whether you can see and constrain what a deployed agent is doing, which is why AI agents stall in production. Both are real. Neither is what breaks a long-running agent mid-task.
The long-horizon failure is upstream of both. It is about whether the agent can carry its own intent and state across the boundary between one context window and the next. Get that wrong and review discipline and observability have nothing coherent to operate on, because the work itself is drifting.
The buyer's version
You do not need to build a harness to evaluate one. When someone proposes running agents on work that takes longer than a single session, ask three things. 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 actually done, not just plausibly done?
Credible answers sound like feature lists, checkpoints, progress logs, and end-to-end verification. Vague answers sound like "the model is really capable now." The model probably is. That was never the part that failed. Designing the harness that carries work across sessions is the substance of an AI implementation, and it is where a serious automation effort earns its result or quietly loses it.