A task that outlives one context window is the moment your agent stops being a demo. It's also the moment two different failures start hunting it — and because they look identical from the outside (the loop just… stops being useful), most teams misdiagnose both and apply the same wrong fix: a bigger context window.

Here's the whole idea up front. A long-running loop dies two unrelated deaths. It can go dumb — the window fills with stale tool output until the model can't find the thread. Or it can go dead — the process crashes at hour three and takes every uncommitted step with it. Context size is the cure for neither. Going dumb needs context management; going dead needs durability. They are different axes, and an hours-long agent needs both.

Going dumb: the window fills with junk#

A long loop rarely fails because the model got weak. It fails because the context fills with re-fetchable tool results, search dumps, and exploration scraps until the signal is buried. The fix isn't a larger window — a larger window fills too, later and more expensively per turn. The fix is keeping the live window small and legible.

Anthropic ships three server-side levers for exactly this, and the trap is treating them as competitors instead of a division of labor. Context editing evicts old tool results — the cheapest thing to lose, because you can just re-call the tool (Anthropic). Compaction summarizes the transcript — lossy, but it reclaims a lot. The memory tool writes facts to a file outside the window, the only one of the three that makes a fact survive a reset (memory tool docs). Anthropic reports the payoff climbs from 29% improvement with editing alone to 39% with editing plus memory on a long-horizon task. We broke down how to assign each loss to the cheapest mechanism in Context Editing vs Compaction vs the Memory Tool.

Notice what none of this does: it does not keep your work alive across a crash. Context management is entirely a story about what the model can see right now.

Going dead: the process crashes and takes your work#

Now the other axis. Your loop has run flawlessly for three hours and fifty minutes, its context beautifully managed — and then the host is preempted. A naive retry restarts from zero, and you've bought nothing from all that context hygiene. Durability is the property that a crash resumes from the last good step instead of the beginning.

The subtle trap here is that a state checkpoint is not durable execution. A checkpointer saves state at step boundaries so you can resume a thread. But if a step crashes mid-flight, most checkpointers re-enter that step from the top on resume — re-running the LLM call, the tool write, the charge it had already issued. Durable-execution engines close that gap by journaling what happened inside each step and replaying it, so resume lands exactly where the crash did. That's the real line between a checkpointer and a Temporal-style engine, and we mapped it precisely in LangGraph Checkpointing vs Temporal (Temporal).

Notice, again, what durability does not do: it will faithfully preserve and resume a loop whose window is already full of garbage. A durable dumb agent is still a dumb agent.

Ask two questions before you scale a loop: is my window filling with junk, or did my process just die? They have different answers, and a bigger context window is not either of them.

Wire them independently#

Because the axes are orthogonal, you size them separately:

Most hours-long agents answer yes to both. That's not redundancy — it's two holes in the hull, and you patch each with the tool built for it. The teams that ship reliable long-horizon agents in 2026 aren't the ones with the biggest context window. They're the ones who stopped treating "my agent got worse over time" and "my agent lost four hours to a crash" as the same bug.