Long-Context Management · Agent Architecture

The prompt is not
working memory.

First surfaced in Tandemly Briefing — 2026-08-21.

Lin, Ang, Zhu, Ding and Zhou asked a pointed question: why does an agent's context have to be a growing block of text? Their answer is a system called Scroll, which turns the session into a sandboxed Python environment. Intermediate state binds to named variables. The model queries and transforms it with code. Evicted spans stay addressable through a compact index rather than being discarded. On a long-horizon agent benchmark, the system reaches 86.7 percent, compared to 49.3 percent for the best prior long-horizon agent result.

Core framing
Context management as a coding task: as the model's ability to write concise retrieval code improves, the cost and quality of context management improve along with it, without any changes to the system's design.
scroll to explore
01The problem

Compression heuristics
do not get better on their own.

Long-horizon agents hit a ceiling not because models run out of knowledge, but because they run out of room to hold what they've already done.

Every time a long-horizon agent calls a tool, retrieves a document, or computes an intermediate result, that information gets appended to the prompt. The working context grows with every step. Eventually the context window fills up, and something has to give. The standard answer is compression: summarize the older material, prune low-relevance chunks, or rewrite the whole history into a shorter form. Several systems now train this compression step directly into the policy.

The problem is structural, not incidental. A compression heuristic decides what is safe to drop based on some scoring rule applied at a moment in time. That rule must be explicitly maintained as models and tasks change. If the model gets better at reasoning, the heuristic does not benefit from that improvement. You have a separate maintenance problem running in parallel with your primary agent development.

There is a deeper issue too. The prompt is a flat text sequence. To find something the agent computed three hundred steps ago, the model must either re-read the whole history or rely on whatever the compression step preserved. There is no address. There is no index. Evicted material is simply gone, and the agent has no path back to it.

The question this paper asks

What if the agent's context were a programmable environment rather than a text buffer? What if intermediate state lived in named variables the model could query with code, and evicted material remained addressable through a compact index rather than being discarded permanently?

02The experiment

A sandboxed kernel
as working memory.

Scroll has three components working together: a persistent Python namespace, an Event Log, and an eviction index. Together they change what the agent's context actually is.

The central idea is that intermediate state should live in a Python namespace, not serialized into the prompt as text. When the agent calls a tool, the output binds to a named variable. When the agent retrieves a document, it binds to a variable. When the agent computes something, the result binds to a variable. To access any of these later, the model writes a short code expression that reads the variable, transforms it, or queries it with a filter. The result of that query is what gets injected into the working view, not the original object.

This means the model's active context at any moment is only what it has explicitly printed or requested, not the accumulated pile of everything the run has touched. The namespace holds the full state, but the prompt holds only what the model asked to see. The distinction matters because it hands the model control over what it looks at, and control over what something costs to look at.

The second component is an append-only Event Log: a complete, sequential record of every event in the run. The Event Log is not the working context. It is the ground truth the system can fall back to. Nothing in the Event Log is ever overwritten or removed.

The third component is the eviction index. When a span of context is too large to keep in the active view, it is evicted. But instead of being discarded, the system writes a compact landmark into the index: a short pointer tied to the exact address in the Event Log where that span lives. To retrieve evicted material, the model writes code that navigates to the address and reads what it needs. This means long-horizon agents can manage very large runs without paying full re-read cost, and without permanently losing access to older work.

Standard approach
Compress the prompt. Summarize, prune, or rewrite the accumulated history. The compression rule must be designed, maintained, and improved independently of the model's reasoning capability. Evicted material is gone.
Scroll's approach
Make state queryable. Bind intermediate results to variables in a persistent Python namespace. The model writes code to retrieve exactly what it needs. Evicted spans stay addressable through a landmark index. No separate compression heuristic to maintain.
Why the coding framing matters

A compression heuristic must be redesigned when models change. A code-writing interface inherits improvements automatically. If the model gets better at writing concise retrieval expressions, the context management becomes cheaper and more precise without any change to the system. The improvement path for context management is now aligned with the improvement path for coding ability, which is a lane receiving substantial investment.

03Findings

Large numbers on three
long-context benchmarks.

Results use Qwen3.8-Max as the backbone. The margins are large enough to deserve careful reading before they are cited in a system comparison.

LOCA_256K
86.7%
Compared to 49.3% for the best published long-horizon agent, a gap of 37.4 percentage points. LOCA_256K is a long-horizon task benchmark with a 256K-token budget.
BEAM_10M
73.1%
Compared to 68.0% for the best prior memory system, a gain of 5.1 points. BEAM_10M is a large-scale memory benchmark operating at the ten-million-token range.
LongMemEval_S
94.8%
A conversational long-term memory evaluation. The paper reports this result without a comparative baseline in the same table, so it is best treated as an upper-bound reference point.
Backbone coverage
1
All results are with Qwen3.8-Max. No multi-backbone comparison is reported. Whether results transfer across model families is an open question.
On the 37.4-point margin

A 37.4-percentage-point gain over the prior best is an unusual result in this literature. The comparison is against long-horizon agents running under standard context management, not under a matched tuning budget. The gap almost certainly reflects a genuine architectural difference, but the size of it warrants checking the baseline configuration before treating it as a clean head-to-head comparison. What context management approach was the prior best agent using? Was it run with a comparable backbone? These are questions worth asking before citing the number in a broader comparison.

Deployment prerequisite

Scroll requires that the agent can execute arbitrary Python code in a sandboxed environment. That is not a universal assumption. Production deployments with constrained tool surfaces, API-only execution environments, or security policies that restrict code execution cannot adopt this approach directly. The eviction index and Event Log are meaningful only if the execution environment can actually run the retrieval code the model writes.

04Practical takeaways

What this means
for building with long-horizon agents.

The practical case is strongest for teams building agents that already run into context window limits and already have access to a sandboxed execution environment.

1
For teams building long-horizon agents with code execution
If your deployment permits sandboxed code execution, consider replacing prompt-level context serialization with a queryable namespace. The key trade is replacing a compression problem with a programming problem. The compression problem requires explicit heuristic maintenance. The programming problem inherits whatever improvements the model's coding ability accumulates. The trade looks better the longer you expect to run the agent.
2
For platform and infrastructure teams
The eviction model here is different from standard truncation. Evicted spans remain addressable through landmark indices rather than being permanently discarded. Before choosing an eviction strategy for a long-horizon agent platform, check whether your storage layer can support addressable references. Permanent eviction forecloses a retrieval option that this architecture relies on. The append-only Event Log is the foundation; the landmark index is cheap to build on top of it.
3
For teams without sandboxed execution environments
The full Scroll design requires exec capability. Constrained environments can apply a narrower version of the principle: expose intermediate state as structured data the model can query through typed retrieval calls, rather than serializing everything back into the prompt. The interface is more limited than a full Python kernel, but the directionality is the same: give the model a handle on state rather than forcing it to re-read a growing text block.
4
For AI researchers working on long-context benchmarks
Before citing the LOCA_256K number in a comparison, confirm the baseline was run under the same backbone and with the same context management approach as the system being compared. A 37.4-point gap is large enough that baseline configuration choices matter substantially to how it should be interpreted. This is a general point about any result this far outside the typical range for a benchmark: the comparison conditions deserve explicit documentation.
5
For anyone tracking context management over time
The core hypothesis in this paper is testable and worth tracking: if context management becomes a coding task, then context management quality should improve as coding ability improves, without explicit changes to the system. Instrument this. Measure context management cost and retrieval accuracy across model generations on a fixed task. If the hypothesis holds, the improvement should appear without any changes to the eviction index or Event Log design.
05Further exploration

Where to go
from here.

Concrete steps for applying or evaluating this work.

1
Read the paper
Lin, Y., Ang, E., Zhu, E., Ding, B., & Zhou, J. (2026). Context as an Environment: Programmatic Context Management for Long-Horizon Agents. arXiv:2608.21690.
2
Check your deployment's execution capability
The approach requires the agent to exec Python in a sandboxed environment. Before evaluating whether this architecture fits your use case, confirm whether your deployment environment supports arbitrary code execution. If it does not, assess whether typed retrieval calls over structured state give you a partial version of the same benefit.
3
Pilot on a single long-horizon task where context overflow is the identified bottleneck
Build a minimal namespace covering two or three variable types (retrieved documents, tool outputs, computed results). Compare cost and retrieval accuracy against your current approach on the same task, holding backbone and task success threshold constant. The pilot establishes whether the trade from compression to code-writing works in your domain before you redesign the full system.
4
Instrument eviction and re-access rates
Whatever approach you use for long-context management, track how often evicted material gets re-accessed later in the same run. That rate tells you whether your eviction policy is discarding information the model still needs. High re-access rate means your eviction heuristic is wrong; low rate means evictions are safe. This is a cheap diagnostic that applies to any context management approach, not just Scroll.
5
Audit baseline configuration before citing benchmark comparisons
The 37.4-point improvement on LOCA_256K deserves explicit scrutiny of the baseline configuration before it informs a product decision. What backbone did the prior best use? What context management approach? What was the prompt structure? Confirm those details from the original source before treating the margin as a clean architectural comparison.