Give a coding agent a small, well-scoped fix and it's reliable — reads the relevant files, makes the change, checks it, done. Give the same agent a three-hour, forty-file migration and somewhere past the halfway point it starts reintroducing a bug it already fixed, or forgets a constraint you gave it at the start, or loses track of which files it's already visited and skips one.
This isn't the agent getting tired. It's what happens to a fixed-size context window carrying an ever-growing amount of the task's actual history.
Where the degradation actually comes from
Compaction compresses the middle first. Claude Code's own documentation on memory is specific about what survives a long session and what doesn't: a project's root CLAUDE.md survives compaction and gets re-read from disk, but nested CLAUDE.md files and path-scoped rules only reload "as Claude reads files they apply to" — meaning a constraint that isn't tied to a file the agent happens to revisit can simply not come back. That's not a bug in Claude Code; it's what has to happen when a session's history keeps growing and the context that holds it doesn't.
Attention over long context isn't uniform. It's a well-documented pattern in language models generally: information placed in the middle of a long context gets attended to less reliably than information at the start or the end. A constraint given at turn one and still relevant at turn forty is, structurally, exactly the kind of thing most likely to get under-weighted by the time it matters.
Errors compound instead of resetting. Every turn's context includes everything generated so far, mistakes included. An early wrong assumption isn't corrected by later turns — it's built on, because nothing forces a checkpoint where the task's actual state gets checked against what the agent believes it is. The homepage puts this plainly: when the job grows, errors grow significantly. That's not a coincidence of longer tasks having more surface area for mistakes; it's a description of what happens when nothing bounds how far one mistake propagates.
"Done" itself can drift. On a short task, the definition of done was stated once and is still fresh when the agent checks it. On a long one, the agent's own running account of what "done" means has been through however many rounds of implicit restatement — and each restatement is a chance for scope to loosen.
What actually bounds it
The fix isn't a bigger context window — a bigger window reduces how much gets truncated, but it doesn't change whether anything checks what actually happened against what the agent believes happened. Holding more information and verifying it against ground truth are different properties.
What bounds long-task degradation is decomposition enforced from outside the agent's own running account of the task: a workflow that breaks the procedure into discrete, engine-tracked steps, where each step's completion is checked at that step rather than trusted as part of an accumulating narrative. An approval gate at a natural checkpoint — before the next phase of a migration starts, say — re-anchors the run to what a person actually confirmed, not to what forty turns of self-narration have drifted into. Claude Code's own dynamic workflows get a real piece of this right: subagents spawned by a workflow script start with fresh, isolated context rather than inheriting the whole conversation, which genuinely limits how far "lost in the middle" reaches into a decomposed sub-task. What's still missing is a verified handoff between those steps — the orchestrating script's intermediate results live in variables it wrote itself, with no re-checkable contract on a step's output and no documented way to put a person in the loop mid-run.
CodyCody's engine draws the boundary at every step, not just at the sub-task level: it enforces which step is next, holds what "done" means for that step independent of the agent's own account, and a shell step's output is hashed to a file a later step can re-check rather than trusted from a summary written under context pressure.
Worth asking before you take this on faith
Doesn't a larger context window solve this as models improve? It reduces truncation. It doesn't add verification — a model that can hold the whole task in context can still misreport a step within it, since holding information and checking it against reality are different things.
Does breaking the task into smaller prompts myself help? Partially, and it's worth doing. It relies on you remembering to draw the boundary every time, and on the agent not drifting across the boundary you drew — which is the same enforcement gap covered in why agents skip steps.
Is this the same problem as fabricated test results? Related, not identical. Fabricated results are about a single report not matching what happened; long-task drift is about the working state itself degrading across many turns, which makes any single report — honest or not — more likely to be wrong.
See the case for keeping a run self-hosted and reproducible from end to end in self-hosted, air-gapped agent workflows, or how to actually verify what an agent did at any single step. CodyCody has a free Starter tier — see pricing.