Longer Context Windows Won't Fix Long-Horizon Tasks

Every context window increase gets received as a solution to long-running agent tasks. The reasoning is intuitive: the agent loses track over long runs because things fall out of context, so a bigger window means less falls out.

The premise is right and the conclusion doesn't follow, because the failures in long-horizon work mostly aren't caused by information leaving the window.

The three distinct failures

Capacity failure. Genuinely doesn't fit. A bigger window fixes this, and it's the least common of the three past a certain size.

Attention failure. It fits, and the model doesn't reliably use what's buried in the middle of a large context. Effective context has lagged nominal context consistently, and a larger window makes this worse if you fill it — more material, same difficulty finding the relevant part.

Structural failure. The information is present, attended to, and the run still goes wrong: the agent revisits settled decisions, follows a stale plan, loses track of what's done versus pending, or contradicts a conclusion it reached earlier. This is about the organization of the run, not the storage of the conversation.

→ Only the first is a capacity problem. The other two are why a longer window doesn't produce proportionally longer coherent runs.

Why more room can hurt

⚠️ A larger window removes the forcing function. When context was scarce, you had to decide what mattered — and that discipline produced better runs than the constraint cost you.

Given room for everything, the default becomes putting everything in: every tool result in full, every turn, every retrieved document. The result is a large context where the constraint from turn one competes with forty thousand tokens of accumulated material, and the model has to locate it every turn.

The related cost is economic. Input tokens dominate agent spend, and they're re-sent every turn. Filling a large window because it's available multiplies the cost of every subsequent call in the run.

What actually extends coherent runs

Structured state the loop owns. The work ledger — what was requested, done, remaining, decided — held outside the message array and regenerated each turn. This is what stops the agent losing track, and it works regardless of window size because it doesn't depend on the model recalling anything.

An external scratchpad. Findings written to addressable notes rather than left in conversation. Survives compaction, keeps context small, and gives you a readable record.

Explicit re-injection of constraints. Standing rules restated at the end of the context, immediately before the model acts. Cheap, and it fixes the most common long-run failure — a rule obeyed for twenty turns and then dropped.

Deliberate compaction, not accumulation. Distilling a large tool result into what matters and dropping the raw version, rather than carrying it because there's room.

Plan revision as an explicit act. A stale plan sitting in a large context outweighs new evidence more strongly, not less, because it's the most structured thing there. Making revision a recorded action addresses this; more room doesn't.

✅ What a bigger window is genuinely good for

Not nothing — just different things than the intuition suggests:

• Single-shot tasks over large inputs. Analyzing a long document in one pass is straightforwardly better with more room.
• Fewer compaction events, which means fewer places to lose something.
• More retrieved material when you genuinely need breadth in one turn.
• Reduced engineering effort on context management for medium-length runs — real, and it's a convenience rather than a capability change.

🔍 Diagnosing which failure you have

When a long run goes wrong, find the first wrong turn and check:

• Was the needed information in the array? No → capacity or over-aggressive compaction.
• Present but buried in the middle? → attention. Move it, don't add room.
• Present, well-positioned, still ignored? → structural. The agent has lost track of the run's state, and that's a ledger problem.

In practice the third is the most common cause of long-horizon failure, and it's the one no window size addresses.

The takeaway

Long-horizon coherence is a run-organization problem more than a storage problem. Structured state the loop owns, an external scratchpad, constraints re-injected at the end, and deliberate compaction extend coherent runs; a larger window mostly removes the discipline that was helping. Use the extra room for large single-shot inputs and fewer compaction events — and keep the context small on purpose anyway.