Long-Running Agents Perform Better with Selective Context

Scope note: This review covers seven recent approaches to managing context during long agent tasks. It addresses what an agent sees during execution, not the broader questions of model training data or organizational access policy.

An agent can have a very large context window and still receive the wrong context.

The problem becomes obvious during long work. Tool output accumulates. Search results repeat. Earlier instructions remain important, but the transcript places them beside temporary errors, rejected ideas, and obsolete state. More tokens preserve more material, yet preservation alone does not tell the agent which material should affect the next decision.

Seven recent preprints test context as an active system concern. Their methods differ, but their shared result is clear: long-running agents perform better when context can be inspected, compressed, archived, recovered, and evaluated.

Models need information about their own context

LLM Agents Are Latent Context Managers argues that capable models already make useful keep-or-remove decisions when they can see the relevant system state. Its VISTA interface exposes typed context blocks, token use, age, and access history. It also archives removed blocks as full records that can be recovered later.

The interface required no additional model training. On LOCA-Bench, it raised Gemini 3 Flash from 22.7 to 50.7 percent, with gains across four model backbones. The improvement increased as context pressure increased.

This finding corrects a basic design problem. We often ask the model to manage a resource that the interface does not describe. The model sees text, but it does not know which sections are expensive, old, frequently used, or safely recoverable. A context dashboard turns those hidden conditions into available evidence.

Compression must preserve decisions and sources

Context as a Tool gives software-engineering agents a callable context-management operation. The working area separates stable task requirements, condensed long-term material, and recent high-detail interactions. A trained compressor decides when to summarize prior work. On SWE-bench Verified, the authors report a 57.6 percent solve rate and more stable performance under a fixed context budget.

ACON also optimizes compression, but it learns natural-language compression rules from failures. When an agent succeeds with full context and fails after compression, a stronger model identifies what the compressed version omitted. Smaller compressors can then learn the revised rule.

Both approaches treat summarization as a task-specific operation. That matters. A useful software summary preserves file paths, acceptance conditions, failing tests, and unresolved decisions. A useful research summary preserves claims, sources, and uncertainty. Generic shortening can remove the one detail that makes later verification possible.

ECHO keeps source indices attached to compressed turn records. Those indices let the agent reconstruct selected evidence and let reinforcement learning assign credit to the observations that supported a successful answer. On BrowseComp-Plus, ECHO reached 43.4 percent held-out accuracy, compared with 28.9 percent for GRPO and 36.1 percent for a rolling-summary baseline.

The source index is not a minor implementation detail. A compressed statement without a route to its source limits checking, correction, and learning.

Files provide durable, inspectable state

FS-Researcher divides deep research between a context-building agent and a report-writing agent. The first agent browses, writes structured notes, and saves raw sources in a file hierarchy. The second writes from that collection one section at a time. The authors report state-of-the-art results on two open-ended research benchmarks and a positive relationship between research effort and final report quality.

Everything Is Context proposes a file-system abstraction for prompts, memory, tools, human input, metadata, and access controls. The aim is consistent handling and auditability rather than a new retrieval method.

ContextWeaver addresses selection during multi-turn work. It chooses and assembles relevant evidence from long histories so the model receives a bounded working set rather than an append-only transcript.

I do not read these papers as an argument that every agent should literally store everything as local files. I read them as evidence for four properties: durable state, explicit structure, source addressability, and recoverable detail. A database, object store, or knowledge graph can provide the same properties if the agent can inspect and use them.

Complete history and complete context are different

A complete history is valuable for audit. A complete history is often poor input for the next action.

This distinction resolves a common disagreement in agent design. One group wants aggressive compression because long prompts cost money and reduce attention. Another group wants full records because summaries lose evidence. The papers suggest that both requirements can be met: retain the full record outside the immediate prompt, select a small working set, and preserve exact routes back to the source.

The evaluation must also change. A single successful run does not show whether the context process works. I would test whether the agent can recover an early constraint after many tool calls, distinguish a current state from an obsolete one, cite the exact observation behind a decision, and repeat the task without large variation.

My practical view is that context engineering should be reviewed like any other production subsystem. It needs a data model, access rules, observability, failure tests, and a defined recovery path. A larger window can reduce immediate pressure. It cannot decide what the agent should keep, remove, or verify.