Long-Horizon Agents Need a Map, Not a Bigger Context Window
An agent on a long task usually loses its way well before it runs out of context. The window still has room. The transcript holds everything it has done, in order, at full length. What it no longer holds, in any usable form, is where the work stands.
That distinction matters because the fix most teams reach for is size. Give the model a larger window, feed it more history, let it carry the whole job in its head. Size helps with one problem: information that was dropped entirely. Most long-horizon failures are a different problem. The information is present. It is buried under tool output, dead ends and superseded attempts, and the model has to reconstruct its own position from that pile on every step.
The trend line makes this urgent rather than academic. METR's measurements put the length of tasks agents can finish at 50% reliability as doubling roughly every seven months, and the same work found success falling below 10% on tasks that take a person more than about four hours. Tasks are getting longer faster than raw memory is getting more reliable. So the question for a deployment is not how much an agent can hold. It is how the agent knows where it is.
A transcript is not a map
A transcript records a journey the way a dashcam does: complete, sequential, and almost impossible to navigate by. Ask it a simple question mid-task (what have we already ruled out?) and the answer has to be mined from hundreds of turns, some of which contradict later turns.
Worse, a long transcript actively degrades the reasoning done over it. Chroma's Context Rot study tested 18 production models and found performance getting less reliable as input length grew, in uneven ways, even on simple retrieval and copying tasks. Similar but irrelevant material hurt more than plain filler. A long agent transcript is exactly that material at scale: near-miss attempts, stale intermediate results, and tool output that was useful for one step and noise ever after.
A map solves a different problem than memory does. It does not try to keep everything. It keeps position: the goal, what is done, what was decided and why, what is still open, and where the underlying detail lives if it is needed again. A driver crossing a continent does not memorise every mile driven. They carry a map, a current location, and a route — and they can re-orient in seconds after any detour.
What goes on the map
Keep it small enough to read at a glance, and structured enough that updating it is a habit rather than a chore. In our view five entries earn their place.
The goal, stated once, in the terms the work will be judged by. Then current position: the last verified state of the work, not the last thing attempted. Decisions belong here too, with the reason attached, because a decision without its reason gets relitigated three hours later by an agent that cannot tell it was settled. Open ends come next: the questions still live, the branches not yet taken, the failures already ruled out. Finally, pointers. File paths, document links, query names: lightweight references the agent can follow to reload detail on demand, instead of carrying that detail in context the whole way.
That last entry does quiet, important work. Anthropic's writing on effective context engineering describes the same pattern from the other side: keep identifiers in context, load the underlying data just in time through tools, and treat context as a finite attention budget rather than a storage bin. Their long-horizon toolkit — summarising history when it grows unwieldy, keeping structured notes outside the window, and letting focused sub-agents return short distilled summaries instead of raw workings — is, in effect, map maintenance described three ways. We agree with the toolkit. Our argument is about priority: build the map first, deliberately, as a designed artifact. The rest follows from it.
A map also changes what a fresh start costs. When a run is compacted, restarted, or handed to another agent, the newcomer does not need the saga. It needs the map and a few pointers. Anthropic's later work on harnesses for long-running agents makes a parallel point in software work: durable progress files and a structured list of what is done and what is not let a new session orient itself and make incremental progress instead of declaring victory early or redoing finished work. Orientation, in both accounts, is a file — not a memory.
Keep the map honest
A map that is written once and never updated is worse than none, because the agent trusts it. So the working rule is simple: no step counts until the map reflects it, and verification is what updates position. An agent that has attempted a fix has moved its transcript forward. It has only moved its position when a check (a test, a query result, a human confirmation) says the fix holds.
That rule also gives long runs a natural rhythm. Work in increments small enough to verify. Record the outcome, including the failures, since a ruled-out branch written on the map never gets explored twice. When the map and the territory disagree, believe the territory, fix the map, and note the disagreement. It usually marks the spot where the task was misunderstood.
Where a map does not help
Short tasks do not need one. If a job finishes in a handful of steps inside one context, map-keeping is ceremony, and the transcript is the record. Maps also decay. On a fast-changing task the maintenance cost is real, and a stale map misleads with confidence, which is why the verification rule above is not optional decoration.
There is a harder limit underneath. A map fixes orientation; it does not fix judgment. An agent that misreads its goal, or verifies its work against the wrong check, will maintain an excellent map of the wrong journey. And summarising a long history into map form always discards something whose importance only shows up later. Every team that compacts context learns to tune what gets kept, starting generous and tightening with experience. The map is a discipline, not a guarantee.
Still, the direction is clear. Windows will keep growing, and long tasks will keep degrading inside them for the reasons the context-rot results describe. The teams whose agents finish four-hour, eight-hour, day-long work reliably will not be the ones who waited for a window big enough to hold the whole job. They will be the ones who taught their agents to carry a map, keep it current, and check their position against the territory as they go.
Work with us
If your team is stretching agents from ten-minute demos toward work that runs for hours, the bottleneck is probably orientation rather than model size — and it is fixable with structure, verification and honest state-keeping. Tell us where your long runs lose their way through Trida AI's intake, and we will map out what it takes to keep them on course.