Context as an Environment: Programmatic Context Management for Long-Horizon Agents

# Context as an Environment:Programmatic Context Management for Long-Horizon Agents
Source: [https://arxiv.org/html/2608.21690](https://arxiv.org/html/2608.21690)
Yin Lin†yin\.lin@alibaba\-inc\.comAlibaba GroupElaine Ang†§\{\}^\{\\dagger\\,\\lx@sectionsign\}ra3448@columbia\.eduColumbia UniversityErkang Zhuerkang\.zhu@alibaba\-inc\.comAlibaba Group Bolin Dingbolin\.ding@alibaba\-inc\.comAlibaba GroupJingren Zhoujingren\.zhou@alibaba\-inc\.comAlibaba Group

###### Abstract

LLM agents increasingly take on long\-running tasks whose history grows far beyond a single model context window\. Existing approaches compress earlier interactions or extract selected information into fixed memory representations, committing to what to preserve before future needs are known\. We present*Scroll*, a context manager that treats each agent session as an executable*Session Environment*\. The environment is backed by an append\-only Event Log and a sandboxed, persistent Python kernel\. The kernel maintains a typed namespace across model calls, allowing tool outputs, retrieved history, and derived state to be bound to variables rather than serialized into the prompt at each call\. Model\-written code searches, materializes, and transforms session state throughexec; only explicitly printed projections enter the model’s working view for the next call\. Context management thus becomes a programming task that inherits the improving coding abilities of LLMs, while the Event Log preserves lossless historical ground truth\. As the working view approaches its budget, stale spans are evicted but remain recoverable: an eviction index keeps compact landmarks tied to exact Event Log addresses, so that the agent navigates directly to evicted regions instead of searching the full log\. With Qwen3\.8\-Max as the backbone, Scroll achieves94\.8%on LongMemEvalS;73\.1%on BEAM10M, surpassing the best published memory system by 5\.1 points; and86\.7%on LOCA256K, exceeding the best published long\-horizon agent by 37\.4 points\.

††footnotetext:†Equal contribution\.††footnotetext:§Work done during an internship at Alibaba Group\.## 1Introduction

LLM agents are increasingly used for long\-running tasks such as repository\-level software engineering\([11](https://arxiv.org/html/2608.21690#bib.bib21);[32](https://arxiv.org/html/2608.21690#bib.bib14)\)and deep research over the open web\([40](https://arxiv.org/html/2608.21690#bib.bib22);[30](https://arxiv.org/html/2608.21690#bib.bib23)\)\. Unlike single\-turn generation, these tasks unfold over extended trajectories of model calls, tool executions, observations, failures, and revisions\. As trajectories grow, a central challenge for the*agent harness*is context management: session history accumulates continuously, while each model invocation operates over a bounded context window\. Moreover, the effective context a model can reliably exploit is far smaller than its nominal window, as long\-input retrieval and reasoning degrade with input length\([21](https://arxiv.org/html/2608.21690#bib.bib8);[35](https://arxiv.org/html/2608.21690#bib.bib1)\)\.

Current systems largely address this problem through*context compression*or*external memory*\. Compression is the dominant approach in practice: existing methods truncate stale spans, discard tool outputs, or replace earlier trajectory segments with summaries\([12](https://arxiv.org/html/2608.21690#bib.bib2);[34](https://arxiv.org/html/2608.21690#bib.bib10)\), and production agents such as Claude Code, Codex CLI, and Cursor reportedly employ similar compaction mechanisms as the context window approaches its limit\. External memory systems extract selected facts or episodes into a separate store and later retrieve them through semantic or structured interfaces\([23](https://arxiv.org/html/2608.21690#bib.bib9);[31](https://arxiv.org/html/2608.21690#bib.bib7);cao2026remember\)\. Both are fundamentally lossy in the same way: the agent sees history only through the summary or the memory store, so any detail they fail to keep is out of reach—even if the raw log still exists on disk\. Long\-horizon tasks, however, may require exact historical evidence or nontrivial computation over past events, such as comparing tool outputs produced far apart in the trajectory\. Neither the relevant information nor the required operation is known in advance, so no summary produced at observation time can be guaranteed to preserve what is later needed\.

We present*Scroll*, which keeps the agent’s history outside the model context\([38](https://arxiv.org/html/2608.21690#bib.bib4)\)and represents it as an executable*Session Environment*\. An append\-only Event Log preserves the interaction trajectory with stable addresses and provenance, while a sandboxed, persistent Python kernel survives across model calls and maintains a typed namespace of resident variables\. Any of this state can therefore be materialized as Python objects and reused across reasoning steps without being serialized into the prompt\.

This turns context management into*writing programs*—something current models are already highly proficient at\. The model issuesexecactions to search and expand the Event Log, access permitted resources, invoke tools\([3](https://arxiv.org/html/2608.21690#bib.bib33)\), and compute over resident variables\. Retrieved records, tool outputs, and intermediate computations remain in the kernel unless explicitly emitted throughprint, which the harness inserts as an observation into the next model context\. Thus,execdetermines how the environment is accessed and transformed, whileprintdetermines which projection enters the model’s*working view*over the Session Environment\.

As the working view approaches its budget, the harness evicts stale spans\. Unlike compaction, eviction changes only the view, never the underlying record: evicted events remain verbatim in the Event Log under their stable addresses, where the model’s programs can search for and materialize them on demand\. Scroll additionally keeps an*eviction index*in the view: a compact map of what has left it\. Where search recovers only what the agent thinks to ask for, the index keeps the agent aware of history it can no longer see; each entry anchors the exact addresses of the evicted events, from which the originals are materialized on demand\.

Our contributions are threefold:

- •We formulate long\-horizon context management as choosing, at each step, a working view over a persistent Session Environment\. Existing approaches fix this choice before future needs are known; Scroll defers it to query time as a program the model writes\.
- •We implement an executable context substrate combining an append\-only Event Log, durable storage, and a sandboxed persistent Python kernel\. The model operates on the environment throughexec; within it, only explicitprintoutput crosses into the model\-visible context\.
- •We introduce an algorithm that keeps the working view within budget without losing history: evicted spans remain intact in the Event Log, indexed by compact address\-anchored entries the agent can navigate directly\.

## 2Scroll Context Manager

![Refer to caption](https://arxiv.org/html/2608.21690v1/scroll_system_image.png)Figure 1:Overview of Scroll\. Scroll keeps the full session in a persistent, executable Session Environment; model\-written code retrieves and computes over it viaexec, andprintselects the working view exposed to the next model call\.We introduce Scroll, a context manager for long\-horizon LLM agents\. The key insight is that an agent’s accumulated history should not be serialized into the model’s prompt but should instead be treated as*an environment that the model programmatically interacts with*\. The prompt then carries only a working view, while the session lives outside the context window without loss\. We first formalize the problem this design addresses \(§[2\.1](https://arxiv.org/html/2608.21690#S2.SS1)\), then describe the Session Environment \(§[2\.2](https://arxiv.org/html/2608.21690#S2.SS2)\), the programmatic interface through which the model constructs its own context \(§[2\.3](https://arxiv.org/html/2608.21690#S2.SS3)\), and the eviction mechanism that keeps the working view bounded while preserving recoverability \(§[2\.4](https://arxiv.org/html/2608.21690#S2.SS4)\)\.

### 2\.1Problem Formulation

#### Session state and working view\.

An agent session produces a growing sequence of*events*e1,e2,…e\_\{1\},e\_\{2\},\\ldots\(user messages, model responses, tool calls, tool results\), each with an associated*payload*\(its raw content, e\.g\., a full tool output\)\. We write the session state afterttagent steps as

St=\(Lt,Pt,Vt\),S\_\{t\}=\(L\_\{t\},\\;P\_\{t\},\\;V\_\{t\}\),\(1\)whereLtL\_\{t\}is the event sequence with per\-event metadata,PtP\_\{t\}the payloads referenced byLtL\_\{t\}, andVtV\_\{t\}auxiliary derived state \(in Scroll, a variable namespace; in other systems, a memory store or summary buffer\)\. Each model call, however, consumes a*working view*ctc\_\{t\}with\|ct\|≤C\|c\_\{t\}\|\\leq Ctokens, whereCCis the model’s nominal context window\. The*context\-management problem*is to choose, at every step, the next view: the mapSt↦ct\+1S\_\{t\}\\mapsto c\_\{t\+1\}\.

#### When the selection is made\.

Existing approaches fix the mapSt↦ct\+1S\_\{t\}\\mapsto c\_\{t\+1\}before future needs are known: compression applies a lossy operatorϕ\\phias the trajectory grows,ct\+1=ϕ⁡\(ct,et\)c\_\{t\+1\}=\\phi\(c\_\{t\},\\,e\_\{t\}\), deciding which information survives when each segment is compacted; external memory applies an extraction operatorψ\\psiat ingestion,Vt=ψ⁡\(Vt−1,et\)V\_\{t\}=\\psi\(V\_\{t\-1\},e\_\{t\}\), fixing what is stored and how it can later be retrieved\. Either way, the reduced representation replaces the history it summarizes, so anything it omits is unrecoverable\.

Scroll instead defers selection to query time\. The full stateStS\_\{t\}persists losslessly outside the context, and the mapSt↦ct\+1S\_\{t\}\\mapsto c\_\{t\+1\}is a*program*πt\\pi\_\{t\}the model writes at steptt: the program executes onStS\_\{t\}, updatesVtV\_\{t\}, and emits a bounded observation for the next call\. The model decides what to recall, compute, and expose; the harness makes those decisions safe via durable storage, stable addressing, and sandboxed execution\. Because the policy is expressed as code, it inherits the full generality of programs and improves with the backbone’s coding ability, at no change to the harness\.

Table 1:The model\-facing interface factorizes context construction into location, materialization, computation, and exposure\.

### 2\.2Persistent Session Environment

Scroll realizesStS\_\{t\}as a*Session Environment*\(Figure[1](https://arxiv.org/html/2608.21690#S2.F1), right\), with three components corresponding toLtL\_\{t\},PtP\_\{t\}, andVtV\_\{t\}\.

#### Append\-only Event Log \(LtL\_\{t\}\)\.

The Event Log is the durable, ground\-truth record of an agent’s sessions: a single append\-only log that spans session boundaries\. Every interaction appends a typed event carrying the metadata future queries need—role, session and agent identifiers, timestamps, and tool state—and receives its immutable, monotonically increasingseq\. Our implementation stores events in SQLite\. Search defaults to BM25 rather than embeddings: it is deterministic and requires no index\-time model calls\.

#### Durable storage \(PtP\_\{t\}\)\.

A payload is the raw content an interaction produced, such as a full tool result or a generated artifact\. The log records that the interaction occurred but need not store every byte of it in the event row: small payloads remain inline in SQLite, while large ones are moved into JSON or artifact storage on the filesystem, with the row retaining a bounded preview and a recovery pointer\. Externalized payloads are accessed through lazy handles \(ToolResultRef,ArtifactRef\)\.

#### Persistent runtime and resident namespace \(VtV\_\{t\}\)\.

A sandboxed Python kernel persists across model calls throughout the session; its namespace holds*environment objects*: resident Python values and lazy handles, each carrying type, size, and provenance metadata identifying the events it derives from\. Tool invocations issued through the programmatic tool interface\([3](https://arxiv.org/html/2608.21690#bib.bib33)\)return Python objects that later programs can operate on\. The harness prepends to every call a*namespace digest*: a short listing of each resident variable’s name, type, and shape, with small scalar values shown inline\. Model\-authored code runs in a fail\-closed sandbox: the Event Log is read\-only from the kernel, and database, filesystem, network, and tool access are limited to capabilities the harness explicitly declares\.

Figure 2:Programmatic context construction\. Threeexecturns compute over resident state in the kernel; onlyprintoutput crosses into the next model context/working view\.

### 2\.3Programmatic Context Construction

Scroll uses a CodeAct\-style interface\([29](https://arxiv.org/html/2608.21690#bib.bib36)\)for both task execution and context construction\. A controlled capability object,ms, forms the model\-facing*memory surface*over durable history, abstracting the physical backend behind four operations \(Table[1](https://arxiv.org/html/2608.21690#S2.T1)\)\.

Figure[2](https://arxiv.org/html/2608.21690#S2.F2)traces the trip\-planning task of Figure[1](https://arxiv.org/html/2608.21690#S2.F1)through threeexeccells\. Cell 1 binds full tool results to the resident variablesflightsandroutesin the Python kernel, printing only a few rows\. Cell 2 searches the Event Log for stated preferences; the matching previews andseqaddresses enter the working view, revealing the user’s preference for economy cabins and toll\-free routes\. Cell 3 expands the two events for the verbatim record, filters and ranks the resident variables accordingly, and prints the two preference turns alongside the cheapest economy flight and the fastest toll\-free route\. The bulk tool results never enter the working view; every call is appended to the Event Log with its full result, addressable byseq\.

### 2\.4Eviction and Off\-Context Navigation

The working view must stay bounded as the session grows\. Scroll bounds it with an eviction procedure \(Algorithm[1](https://arxiv.org/html/2608.21690#alg1)\) that triggers whenever the working view exceeds a budgetρ​C\\rho C\. The procedure first persists any live turns to the Event Log and protects the active turn, the recent tail, and the newest tool results\. The remainder is evicted in increasing order of recovery cost: completed tool payloads are folded first, since a singleseqpointer suffices to recover them; whole spans are removed only if the view remains over budget\. What leaves the view is not lost: it stays verbatim in the Event Log, and the procedure’s one invariant is that everything it removes stays addressable\.

Algorithm 1Recoverable context eviction1:working view

cc, Event Log

ℒ\\mathcal\{L\}, eviction index

ℐ\\mathcal\{I\}, budget

ρ​C\\rho C, tier width

kk
2:bounded

ccand updated

ℐ\\mathcal\{I\}; removed spans stay recoverable from

ℒ\\mathcal\{L\}
3:if

\|c\|\>ρ​C\|c\|\>\\rho Cthen

4:

ℒ←Persist​\(c,ℒ\)\\mathcal\{L\}\\leftarrow\\textsc\{Persist\}\(c,\\mathcal\{L\}\)⊳\\trianglerightlive turns become durable

5:

R←Protected​\(c\)R\\leftarrow\\textsc\{Protected\}\(c\)⊳\\trianglerightactive turn, recent tail, newest tool results

6:

c←R∪FoldPayloads​\(c∖R\)c\\leftarrow R\\,\\cup\\,\\textsc\{FoldPayloads\}\(c\\setminus R\)⊳\\trianglerightpayloads→\\toseqpointers

7:

E←SelectSpan​\(c∖R,\|c\|−ρ​C\)E\\leftarrow\\textsc\{SelectSpan\}\(c\\setminus R,\\;\|c\|\-\\rho C\)⊳\\trianglerightoldest completed span above budget

8:

c,ℐ←EvictToIndex​\(c,E,ℋ⁡\[E\]\)c,\\ \\mathcal\{I\}\\leftarrow\\textsc\{EvictToIndex\}\(c,\\;E,\\;\\mathcal\{H\}\[E\]\)⊳\\trianglerightEEleaves the view; its headlines enterℐ\\mathcal\{I\}, shown in place

9:

ℐ←RollUp​\(ℐ,k\)\\mathcal\{I\}\\leftarrow\\textsc\{RollUp\}\(\\mathcal\{I\},\\,k\)
10:endif

11:return

\(c,ℐ\)\(c,\\mathcal\{I\}\)

#### Headlines as navigation anchors\.

Lexical search recovers an evicted span only when the agent recalls its wording; Scroll therefore also maintains*landmarks*for position\-based navigation\. As part of each response, the model writes a short*headline*—task, verified state, next action, and a status—which Scroll binds at append time to theseqassigned by the Event Log, yielding a mapℋ\\mathcal\{H\}from address to headline\. When a span is evicted, its headlines enter a tiered index \(Figure[1](https://arxiv.org/html/2608.21690#S2.F1)\)\. A flat index would grow linearly with the session, so Scroll rolls it up: each tier holds at mostkkblocks; when a tier fills, the newest block retains full detail while thek−1k\-1older ones collapse to one line each and merge into the next tier\. Afternnevictions, the index occupiesO⁡\(k​logk​n\)O\(k\\log\_\{k\}n\)blocks, providing fine anchors for recent history, coarse ranges for distant history, each backed by aseqspan\.

## 3Experimental Setup

### 3\.1Benchmarks

We evaluate Scroll in two long\-horizon settings: \(1\) retrieving and reasoning over interaction histories that exceed the live context, and \(2\) reasoning and acting in an agentic environment whose state grows over time\.

#### Long\-term memory retrieval and reasoning\.

LongMemEval\([31](https://arxiv.org/html/2608.21690#bib.bib7)\)poses questions over a history of prior user–assistant conversations\. Answering may require locating evidence scattered across sessions, resolving temporal dependencies and knowledge updates, and reasoning over the retrieved evidence\. The benchmark provides three settings with increasing amounts of distractor history:Oracle, where the history contains only the evidence sessions; andSandM, where each question is paired with roughly 50 and 500 sessions \(∼115\{\\sim\}115K and∼1\.5\{\\sim\}1\.5M tokens\) of history, respectively\.

BEAM\([27](https://arxiv.org/html/2608.21690#bib.bib24)\)extends this evaluation to substantially longer coherent histories\. Its questions may require collecting non\-adjacent evidence, tracking changes over time, deduplicating repeated information, or aggregating facts distributed throughout the history\. The benchmark spans four history scales \(128K, 500K, 1M, and 10M tokens\); at the largest scale, BEAM10M, histories cannot be consumed directly within current model context windows\.

#### Long\-context reasoning and acting\.

LOCA\([35](https://arxiv.org/html/2608.21690#bib.bib1)\)evaluates agents that must reason, invoke tools, and modify an environment as the available environment state accumulates\. LOCA measures whether an agent can continue to reason and act throughout a growing tool\-use trajectory\. The benchmark scales the*environment description length*\(the token count of the full environment state as seen through tool outputs\) across seven regimes from 8K to 256K tokens; we evaluate on the two largest regimes \(128K and 256K\)\.

### 3\.2Agent Configuration

Our main experiments use Qwen3\.8\-Max as the agent backbone\. All context management methods are implemented and evaluated on top of QwenPaw\([1](https://arxiv.org/html/2608.21690#bib.bib39)\), an agent operating system providing tool invocation and execution infrastructure, and orchestrated with Harbor\([10](https://arxiv.org/html/2608.21690#bib.bib35)\)in the benchmark\-provided environments\. Our implementation to reproduce all reported results is available at[https://github\.com/niceIrene/QwenPaw/tree/scroll\-research](https://github.com/niceIrene/QwenPaw/tree/scroll-research)\.

Scroll exposes its functionality to the agent through a set of tools, of which the following two implement theexecaction of Section[2](https://arxiv.org/html/2608.21690#S2)\.

- •repl\_execexecutes a model\-generated Python cell in the persistent kernel\. Environment tools are exposed as Python functions forwarded to the underlying services, enabling programmatic tool calling; all intermediate computation stays in the kernel, and only explicit, budgetedprintoutput enters the model’s working window\.
- •recall\_history\_pythonexecutes a cell with the memory surfacemsbound:ms\.searchlocates evicted records andms\.expandmaterializes them as Python objects, which the model filters, combines, or aggregates in the kernel before printing a distilled result\.

We use a single system prompt and one set of context\-management rules across all benchmarks, with no few\-shot demonstrations\. Each memory benchmark contributes only a short rubric specifying its data layout, memory\-surface usage, evidence\-selection conventions, and answer format \(see detailed prompts in Appendix[C](https://arxiv.org/html/2608.21690#A3)\)\. For LOCA, we use the benchmark’s official task instructions unmodified, adding only environment metadata \(available APIs and workspace paths\)\.

To test generality across backbones, we additionally evaluate Qwen3\.7\-Max, Deepseek\-v4\-pro, GLM\-5\.2, Kimi\-K2\.7, and Qwen3\.6\-35B\-A3B \(an open\-weight model with a smaller active\-parameter footprint\), changing only the foundation model\.

### 3\.3Evaluation Protocol

For the two memory benchmarks, we ingest each conversation history into Scroll session by session, in chronological order\. At each session boundary, the raw context is cleared, and only Scroll’s internal state \(the eviction index and the Event Log\) is carried forward to subsequent sessions\. For LOCA, each task starts from the benchmark\-provided initial environment state\. The agent explores and acts on the environment directly, with Scroll managing its context as the trajectory grows\.

LongMemEval and BEAM are scored with their benchmark\-provided LLM\-as\-a\-judge prompts, using Qwen3\.6\-flash at temperature00as the judge; we report accuracy for LongMemEval and the judge score for BEAM\. LOCA is scored with its native rule\-based verifier, which checks the final environment state, and we report accuracy\. Unless otherwise noted, each task is evaluated once in the benchmark\-provided container with a random seed; we also record model\-facing input and output tokens and the number of interaction turns for each task\.

## 4Results

### 4\.1Comparison with Existing Systems

#### Retrieval accuracy comparison with long\-term memory systems \(Table[2](https://arxiv.org/html/2608.21690#S4.T2)\)\.

Agents do not natively retain information across sessions, so answering questions over prior interactions requires an external memory system\. We compare Scroll against dedicated long\-term memory systems\. For each system, we report the best publicly available result under its own preferred configuration \(backbone model, retrieval budget, and judge\) as of August 15, 2026\.111We do not reproduce the baselines ourselves, as independent reproductions in this area have repeatedly led to disagreement over evaluation setup\([36](https://arxiv.org/html/2608.21690#bib.bib37);[18](https://arxiv.org/html/2608.21690#bib.bib38)\)\.Appendix[A](https://arxiv.org/html/2608.21690#A1)provides per\-category breakdowns of Scroll on theSandMsplits of LongMemEval and on BEAM10M\.

Table 2:Comparison with existing long\-term memory systems\. For each baseline, we report the best publicly available result under that system’s own setup as of August 15, 2026; “–” denotes no publicly reported result\. These are reference points from the literature rather than a controlled comparison: reader models differ across rows and can substantially affect scores—EmergenceMem \(GPT\-4o\), Zep \(GPT\-5\.4\), Mastra OM \(GPT\-5 mini\), Mem0 \(GPT\-5\), Hindsight \(Gemini 3 Pro\), Exabase M\-1 \(Gemini 3 Flash\), RAG and LIGHT \(Llama\-4\-Maverick\); Honcho uses a multi\-model pipeline and Cognee does not report its reader\.As shown in Table[2](https://arxiv.org/html/2608.21690#S4.T2), Scroll is competitive with the strongest reported systems on LongMemEvalSand beats the best\-performing system by 5\.1 points on BEAM10M\. Existing memory systems follow a three\-stage paradigm: at ingestion, an LLM processes the history into a derived store through fact extraction, summarization, or knowledge\-graph construction; at query time, a retrieval pipeline selects candidate memories from that store; and a reader model then reasons over the returned snippets to produce the answer\. Scroll instead ingests the raw history as\-is, composes retrieval code per question, and needs no separate reader: the agent that writes and executes the queries also produces the final answer directly\.

Table 3:LOCA accuracy \(%\) of different context\-management strategies at the two largest environment description lengths\. All agent loops use Qwen3\.8\-Max as the backbone;Δ\\Deltadenotes the absolute drop from 128K to 256K\.
#### Comparison of context\-management strategies on LOCA \(Table[3](https://arxiv.org/html/2608.21690#S4.T3)\)\.

On LOCA, we compare four agents that share the same backbone \(Qwen3\.8\-Max\) and toolset, and differ only in how they manage a growing context: \(i\) a*summarization agent*, a ReAct agent\([33](https://arxiv.org/html/2608.21690#bib.bib32)\)that periodically compacts its interaction history into a summary; \(ii\) a*retrieval agent*, a ReAct agent whose overflowing history is evicted and made accessible through a recall tool; \(iii\) a*CodeAct agent*\([29](https://arxiv.org/html/2608.21690#bib.bib36)\)that interacts with the environment through programmatic tool calling; and \(iv\) Scroll\. A comparison against the best published numbers from the LOCA paper\([35](https://arxiv.org/html/2608.21690#bib.bib1)\)and its leaderboard is in Appendix[B](https://arxiv.org/html/2608.21690#A2)\.

Table[3](https://arxiv.org/html/2608.21690#S4.T3)reports accuracy at the two largest environment description lengths\. The CodeAct agent and the agent with Scroll, which bind intermediate results to environment objects instead of carrying raw text in context, achieve the best performance and the smallest decrease as context grows\.

### 4\.2Can Different Backbone Models Use Scroll Effectively?

Scroll provides an environment for managing context but does not dictate its use: what state to keep where, and what code to write, are left to the model\. A natural question is*whether the ability to use Scroll effectively is specific to one backbone or shared across models of varying capability*\. We rerun both regimes across six backbones with the harness, tools, prompts, and context\-management rules held fixed \(Table[4](https://arxiv.org/html/2608.21690#S4.T4)\)\.

Every backbone can use Scroll, but stronger models benefit more\. On LongMemEvalS, where the model queries the history database with short programs, all backbones benefit similarly—even the 35B model reaches88\.888\.8, within six points of the best \(94\.894\.8\)\. On BEAM10Mthe gap stays within1515points\. On LOCA, however, tasks demand longer trajectories and more complex program synthesis, so the spread widens to6464points at 256K \(86\.786\.7vs\.22\.722\.7\)\. Failures are not protocol\-level: all backbones adhere to the CodeAct interface, but weaker models commit more execution errors or terminate prematurely on aggregation\-heavy tasks\. Scroll’s ceiling on such tasks thus rises with multi\-step query planning and the ability to decide when evidence suffices, suggesting room for post\-training on frontier model traces\.

Table 4:Scroll across backbones\. Only the foundation model changes; harness, tools, prompts, and context\-management rules are identical\.
### 4\.3Ablation Study

Figure 3:Ablating Scroll’s components on BEAM10M\{\}\_\{\\text\{10M\}\}\(judge scores; hatched bars are Scroll variants; Qwen3\.8\-Max, thinking on\)\. Lossy summarization: summaries replace the originals at ingestion\. Scroll w/o REPL:msexposed as ordinary tool calls, with no persistent kernel\. Scroll w/o index: the eviction index is removed, leaving keyword search only\. Scroll: the full system\.We ablate the core components of Scroll on BEAM10M\. Figure[3](https://arxiv.org/html/2608.21690#S4.F3)reports judge scores per category and overall\. First, to assess the utility of the Event Log, we compare Scroll against a lossy variant whose history is summarized at ingestion, with the originals discarded\. Second, to evaluate the programmatic interface, we compare against*Scroll w/o REPL*, which exposessearch,expand, andsql\_queryas ordinary tool calls, with no persistent kernel\. Third, to assess index\-guided navigation, we remove the eviction index, leaving the agent to locate history through keyword search alone rather than index ranges\.

Discarding the original records is the most damaging ablation: the lossy variant falls to 19\.9 overall, with near\-zero scores wherever the answer must preserve exact values from the history, such as information extraction, temporal reasoning, and knowledge update\. Scroll w/o REPL underperforms full Scroll by 7\.3 points, since serialized tool results cannot be filtered, joined, or aggregated in the kernel; the difference is concentrated in abilities that require composing evidence from many records, such as knowledge update \(92\.5 vs\. 82\.5\) and instruction following \(97\.5 vs\. 76\.3\), while single\-lookup abilities are unaffected\. Removing the eviction index costs 1\.8 points overall, but the effect concentrates where evidence is scattered across the history and must otherwise be collected by keyword search: preference following \(89\.1 vs\. 74\.9\), summarization \(70\.5 vs\. 62\.6\), and event ordering \(64\.1 vs\. 58\.1\)\.

### 4\.4Cost and Efficiency

Scroll exposes only a small fraction of the corpus to the model\. Ingestion involves no additional LLM calls, and at query time records are filtered inside the Python kernel, so only printed output enters the context\. Figure[4](https://arxiv.org/html/2608.21690#S4.F4)shows the per\-task distribution of input tokens, output tokens, and agent turns: median input on BEAM10Mis105105K tokens, about1%1\\%of the corpus, and output is an order of magnitude smaller than input across all three benchmarks\. Note that for LongMemEvalSand BEAM10Mwe measure retrieval alone, whereas for LOCA we measure full task completion, hence its longer trajectories\. We report token counts rather than latency or dollar cost, as both depend on serving configuration\.

Figure 4:Per\-task cost of Scroll \(backbone: Qwen3\.8\-Max\): \(a\) input tokens, \(b\) output tokens, \(c\) agent turns\. Boxes span the IQR with the median marked; red diamonds are means\. Log scale in \(a\) and \(b\)\.

## 5Related Work

#### Context compression and external memory\.

Most context\-management systems either compress the active trajectory or store selected information externally\. Compression methods summarize, clear, or fold earlier interactions into shorter representations\([12](https://arxiv.org/html/2608.21690#bib.bib2);[34](https://arxiv.org/html/2608.21690#bib.bib10);[41](https://arxiv.org/html/2608.21690#bib.bib3);[13](https://arxiv.org/html/2608.21690#bib.bib20)\)\. External\-memory systems instead extract facts, episodes, or notes into a separate store and retrieve them when relevant\([23](https://arxiv.org/html/2608.21690#bib.bib9);[26](https://arxiv.org/html/2608.21690#bib.bib12);[14](https://arxiv.org/html/2608.21690#bib.bib19)\)\. Both approaches reduce the history the model sees by deciding, before future needs are known, which information survives, in what form, and through which interface it can later be reached\. Scroll instead retains the original interaction events and referenced payloads; summaries and indexes provide compact working views without becoming the sole representation of historical evidence\.

#### Code as the agent–environment interface\.

CodeAct introduced executable Python as a general action interface for LLM agents\([29](https://arxiv.org/html/2608.21690#bib.bib36)\), while programmatic tool\-calling and code\-execution systems allow tool results to remain in sandbox variables and enter context only through selected projections\([3](https://arxiv.org/html/2608.21690#bib.bib33);[2](https://arxiv.org/html/2608.21690#bib.bib6)\)\. Related work has also explored programmatic access to externalized long input prompts\([38](https://arxiv.org/html/2608.21690#bib.bib4)\)and structured working state\([15](https://arxiv.org/html/2608.21690#bib.bib16);[28](https://arxiv.org/html/2608.21690#bib.bib18)\)\. Scroll applies this principle to the continuously evolving state of an agent session\. Its persistent Python kernel retains typed variables across model calls:execretrieves and transforms session state, while only explicitprintoutputs cross the observation boundary\.

#### Lossless session history and navigation\.

Prior systems have explored verbatim recall storage, event\-sourced interaction logs, lossless pointers, and provenance\-linked memory\([23](https://arxiv.org/html/2608.21690#bib.bib9);[22](https://arxiv.org/html/2608.21690#bib.bib17);[7](https://arxiv.org/html/2608.21690#bib.bib5);[39](https://arxiv.org/html/2608.21690#bib.bib11)\)\. Scroll combines a queryable append\-only Event Log with external payload references and an executable resident namespace\. Its within\-session eviction index is a navigation layer over this retained state: recent history is represented by fine\-grained, sequence\-addressed headlines, while older history is represented by coarser ranges\. Once a relevant region is located, the original events and payloads are recovered programmatically\. In the terminology of CoALA\([25](https://arxiv.org/html/2608.21690#bib.bib13)\)and context\-engineering surveys\([17](https://arxiv.org/html/2608.21690#bib.bib15)\), Scroll connects executable working state with verbatim episodic history through a persistent Session Environment\.

## 6Conclusion

In this report, we present Scroll, a context manager that makes context management an explicit model policy over a persistent Session Environment: the model usesexecto retrieve and compute over externalized state, and usesprintto decide what enters the next context, while the harness provides deterministic storage, execution, and recovery\. This policy can in turn be distilled from frontier models into smaller ones\. Successful trajectories supervise two decisions:*context retrieval*\(when and how to write retrieval code over the agent history\) and*context injection*\(which computed results should be printed back into the working window\)\. We plan to use frontier\-model traces for supervised fine\-tuning or policy distillation, keeping the underlying context mechanisms fixed\.

## References

- Agentscope TeamQwenPaw\.Note:[https://qwenpaw\.agentscope\.io/](https://qwenpaw.agentscope.io/)Cited by:[§3\.2](https://arxiv.org/html/2608.21690#S3.SS2.p1.1)\.
- Anthropic \(2025a\)AnthropicCode execution with MCP: building more efficient agents\.Note:[https://www\.anthropic\.com/engineering/code\-execution\-with\-mcp](https://www.anthropic.com/engineering/code-execution-with-mcp)Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Anthropic \(2025b\)AnthropicProgrammatic tool calling\.Note:[https://platform\.claude\.com/docs/en/agents\-and\-tools/tool\-use/programmatic\-tool\-calling](https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling)Cited by:[Table 7](https://arxiv.org/html/2608.21690#A2.T7.2.3.1.1),[§1](https://arxiv.org/html/2608.21690#S1.p4.1),[§2\.2](https://arxiv.org/html/2608.21690#S2.SS2.SSS0.Px3.p1.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Barnes \(2026\)T\. BarnesObservational memory: 95% on LongMemEval\.Note:[https://mastra\.ai/research/observational\-memory](https://mastra.ai/research/observational-memory)Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.9.1.1)\.
- Bartholomew \(2026\)B\. BartholomewHindsight is \#1 on BEAM — the benchmark that tests memory at 10M tokens\.Note:[https://hindsight\.vectorize\.io/blog/2026/04/02/beam\-sota](https://hindsight.vectorize.io/blog/2026/04/02/beam-sota)Cited by:[§A\.2](https://arxiv.org/html/2608.21690#A1.SS2.p1.1),[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.6.1.1)\.
- Chhikaraet al\.\(2025\)P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. YadavMem0: building production\-ready AI agents with scalable long\-term memory\.arXiv preprint arXiv:2504\.19413\.Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.5.1.1)\.
- Ehrlich and Blackman \(2026\)C\. Ehrlich and T\. BlackmanLCM: lossless context management\.Voltropy PBC technical report\.Note:[https://papers\.voltropy\.com/LCM](https://papers.voltropy.com/LCM)Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Emergence AI \(2026\)Emergence AISOTA on LongMemEval with RAG\.Note:[https://www\.emergence\.ai/blog/sota\-on\-longmemeval\-with\-rag](https://www.emergence.ai/blog/sota-on-longmemeval-with-rag)Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.7.1.1)\.
- Exabase \(2026\)ExabaseExabase reports state\-of\-the\-art results on BEAM memory benchmark\.Note:[https://www\.hpcwire\.com/aiwire/2026/07/28/exabase\-reports\-state\-of\-the\-art\-results\-on\-beam\-memory\-benchmark/](https://www.hpcwire.com/aiwire/2026/07/28/exabase-reports-state-of-the-art-results-on-beam-memory-benchmark/)Cited by:[§A\.2](https://arxiv.org/html/2608.21690#A1.SS2.p1.1),[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.11.1.1)\.
- Harbor Framework Team \(2026\)Harbor Framework TeamHarbor: a framework for building and running agent evaluations at scale\.Note:[https://github\.com/laude\-institute/harbor](https://github.com/laude-institute/harbor)Cited by:[§3\.2](https://arxiv.org/html/2608.21690#S3.SS2.p1.1)\.
- Jimenezet al\.\(2024\)C\. E\. Jimenez, J\. Yang, A\. Wettig, S\. Yao, K\. Pei, O\. Press, and K\. R\. NarasimhanSWE\-bench: can language models resolve real\-world github issues?\.InInternational Conference on Learning Representations,Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p1.1)\.
- Kanget al\.\(2025\)M\. Kang, W\. Chen, D\. Han, H\. A\. Inan, L\. Wutschitz, Y\. Chen, R\. Sim, and S\. RajmohanAcon: optimizing context compression for long\-horizon llm agents\.arXiv preprint arXiv:2510\.00615\.Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p2.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.
- Kontoniset al\.\(2026\)V\. Kontonis, Y\. Zeng, S\. Garg, L\. Chen, H\. Tang, Z\. Wang, A\. Awadallah, E\. Horvitz, J\. Langford, and D\. PapailiopoulosMemento: teaching llms to manage their own context\.arXiv preprint arXiv:2604\.09852\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.
- Letta \(2026\)LettaContext repositories: version\-controlled memory for agents\.Note:Letta Blog[https://www\.letta\.com/blog/context\-repositories/](https://www.letta.com/blog/context-repositories/)Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.
- Li \(2026\)B\. LiUser as code: executable memory for personalized agents\.arXiv preprint arXiv:2606\.16707\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Marković \(2026\)V\. MarkovićCognee on BEAM: SOTA results without a benchmark\-specific memory system\.Note:[https://www\.cognee\.ai/blog/deep\-dives/benchmarking\-cognee\-on\-beam](https://www.cognee.ai/blog/deep-dives/benchmarking-cognee-on-beam)Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.10.1.1)\.
- Meiet al\.\(2025\)L\. Mei, J\. Yao, Y\. Ge, Y\. Wang, B\. Bi, Y\. Cai, J\. Liu, M\. Li, Z\. Li, D\. Zhang, C\. Zhou, J\. Mao, T\. Xia, J\. Guo, and S\. LiuA survey of context engineering for large language models\.External Links:2507\.13334,[Link](https://arxiv.org/abs/2507.13334)Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Mem0 \(2025\)Mem0Revisiting Zep’s 84% LoCoMo claim: corrected evaluation & 58\.44% accuracy\.Note:[https://github\.com/getzep/zep\-papers/issues/5](https://github.com/getzep/zep-papers/issues/5)Cited by:[footnote 1](https://arxiv.org/html/2608.21690#footnote1)\.
- Mem0 \(2026\)Mem0Memory evaluation\.Note:[https://docs\.mem0\.ai/core\-concepts/memory\-evaluation](https://docs.mem0.ai/core-concepts/memory-evaluation)Cited by:[§A\.2](https://arxiv.org/html/2608.21690#A1.SS2.p1.1),[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.5.1.1)\.
- MiniMax \(2026\)MiniMaxMiniMax M3: frontier coding, 1M context, native multimodality — all in one model\.Note:[https://www\.minimax\.io/blog/minimax\-m3](https://www.minimax.io/blog/minimax-m3)Cited by:[Table 7](https://arxiv.org/html/2608.21690#A2.T7.2.5.1.1)\.
- Modarressiet al\.\(2025\)A\. Modarressi, H\. Deilamsalehy, F\. Dernoncourt, T\. Bui, R\. A\. Rossi, S\. Yoon, and H\. SchützeNoLiMa: long\-context evaluation beyond literal matching\.InInternational Conference on Machine Learning \(ICML\),Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p1.1)\.
- Nakajima \(2026\)Y\. NakajimaThe log is the agent: event\-sourced reactive graphs for auditable, forkable agentic systems\.arXiv preprint arXiv:2605\.21997\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Packeret al\.\(2023\)C\. Packer, V\. Fang, S\. G\. Patil, K\. Lin, S\. Wooders, and J\. E\. GonzalezMemGPT: towards LLMs as operating systems\.arXiv preprint arXiv:2310\.08560\.Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p2.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Plastic Labs \(2026\)Plastic LabsHoncho: memory infrastructure for stateful agents\.Note:[https://github\.com/plastic\-labs/honcho](https://github.com/plastic-labs/honcho)Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.8.1.1)\.
- Sumerset al\.\(2024\)T\. R\. Sumers, S\. Yao, K\. Narasimhan, and T\. L\. GriffithsCognitive architectures for language agents\.Transactions on Machine Learning Research \(TMLR\)\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Tanet al\.\(2026\)J\. Tan, L\. Yang, W\. Zhao, J\. Qiu, M\. Zhu, R\. Murthy, S\. Savarese, H\. Wang, S\. Heinecke, and C\. XiongA lightweight, domain\-adaptive memory system for LLM agents\.InInternational Conference on Learning Representations \(ICLR\),Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.
- Tavakoliet al\.\(2025\)M\. Tavakoli, A\. Salemi, C\. Ye, M\. Abdalla, H\. Zamani, and J\. R\. MitchellBeyond a million tokens: benchmarking and enhancing long\-term memory in LLMs\.arXiv preprint arXiv:2510\.27246\.Cited by:[Table 6](https://arxiv.org/html/2608.21690#A1.T6),[§3\.1](https://arxiv.org/html/2608.21690#S3.SS1.SSS0.Px1.p2.1),[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.2.1.1),[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.3.1.1)\.
- VISTA \(2026\)VISTALLM agents are latent context managers: typed working memory and state proprioception\.arXiv preprint arXiv:2606\.30005\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Wanget al\.\(2024\)X\. Wang, Y\. Chen, L\. Yuan, Y\. Zhang, Y\. Li, H\. Peng, and H\. JiExecutable code actions elicit better llm agents\.External Links:2402\.01030,[Link](https://arxiv.org/abs/2402.01030)Cited by:[§2\.3](https://arxiv.org/html/2608.21690#S2.SS3.p1.1),[§4\.1](https://arxiv.org/html/2608.21690#S4.SS1.SSS0.Px2.p1.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Weiet al\.\(2025\)J\. Wei, Z\. Sun, S\. Papay, S\. McKinney, J\. Han, I\. Fulford, H\. W\. Chung, A\. T\. Passos, W\. Fedus, and A\. GlaeseBrowseComp: a simple yet challenging benchmark for browsing agents\.External Links:2504\.12516,[Link](https://arxiv.org/abs/2504.12516)Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p1.1)\.
- Wuet al\.\(2025\)D\. Wu, H\. Wang, W\. Yu, Y\. Zhang, K\. Chang, and D\. YuLongMemEval: benchmarking chat assistants on long\-term interactive memory\.InInternational Conference on Learning Representations \(ICLR\),Cited by:[Table 5](https://arxiv.org/html/2608.21690#A1.T5),[§1](https://arxiv.org/html/2608.21690#S1.p2.1),[§3\.1](https://arxiv.org/html/2608.21690#S3.SS1.SSS0.Px1.p1.1)\.
- Yanget al\.\(2024\)J\. Yang, C\. E\. Jimenez, A\. Wettig, K\. Lieret, S\. Yao, K\. Narasimhan, and O\. PressSWE\-agent: agent\-computer interfaces enable automated software engineering\.InAdvances in Neural Information Processing Systems \(NeurIPS\),Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p1.1)\.
- Yaoet al\.\(2023\)S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. CaoReAct: synergizing reasoning and acting in language models\.InInternational Conference on Learning Representations \(ICLR\),Cited by:[Table 7](https://arxiv.org/html/2608.21690#A2.T7.2.2.1.1),[§4\.1](https://arxiv.org/html/2608.21690#S4.SS1.SSS0.Px2.p1.1)\.
- Yeet al\.\(2025\)R\. Ye, Z\. Zhang, K\. Li, H\. Yin, Z\. Tao, Y\. Zhao, L\. Su, L\. Zhang, Z\. Qiao, X\. Wang,et al\.Agentfold: long\-horizon web agents with proactive context management\.arXiv preprint arXiv:2510\.24699\.Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p2.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.
- Zenget al\.\(2026\)W\. Zeng, Y\. Huang, and J\. HeLoca\-bench: benchmarking language agents under controllable and extreme context growth\.arXiv preprint arXiv:2602\.07962\.Cited by:[Appendix B](https://arxiv.org/html/2608.21690#A2.SS0.SSS0.Px1.p1.1),[Table 7](https://arxiv.org/html/2608.21690#A2.T7),[Table 7](https://arxiv.org/html/2608.21690#A2.T7.2.4.1.1),[§1](https://arxiv.org/html/2608.21690#S1.p1.1),[§3\.1](https://arxiv.org/html/2608.21690#S3.SS1.SSS0.Px2.p1.1),[§4\.1](https://arxiv.org/html/2608.21690#S4.SS1.SSS0.Px2.p1.1)\.
- Zep \(2025\)ZepLies, damn lies, and statistics: is mem0 really SOTA in agent memory?\.Note:[https://blog\.getzep\.com/lies\-damn\-lies\-statistics\-is\-mem0\-really\-sota\-in\-agent\-memory/](https://blog.getzep.com/lies-damn-lies-statistics-is-mem0-really-sota-in-agent-memory/)Cited by:[footnote 1](https://arxiv.org/html/2608.21690#footnote1)\.
- Zep \(2026\)ZepResearch: Zep benchmark results\.Note:[https://www\.getzep\.com/research/](https://www.getzep.com/research/)Cited by:[Table 2](https://arxiv.org/html/2608.21690#S4.T2.2.4.1.1)\.
- Zhanget al\.\(2025\)A\. L\. Zhang, T\. Kraska, and O\. KhattabRecursive language models\.arXiv preprint arXiv:2512\.24601\.Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p3.1),[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px2.p1.1)\.
- Zhanget al\.\(2026\)Y\. Zhang, Z\. Guo, Z\. Zeng, W\. Wang, W\. Wu, and L\. XuMandol: an agglomerative agent memory system for long\-term conversations\.arXiv preprint arXiv:2606\.29778\.Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px3.p1.1)\.
- Zhenget al\.\(2025\)Y\. Zheng, D\. Fu, X\. Hu, X\. Cai, L\. Ye, P\. Lu, and P\. LiuDeepResearcher: scaling deep research via reinforcement learning in real\-world environments\.arXiv preprint arXiv:2504\.03160\.Cited by:[§1](https://arxiv.org/html/2608.21690#S1.p1.1)\.
- Zhouet al\.\(2026\)Z\. Zhou, A\. Qu, Z\. Wu, S\. Kim, A\. Prakash, D\. Rus, B\. K\. H\. Low, and P\. P\. LiangMEM1: learning to synergize memory and reasoning for efficient long\-horizon agents\.InInternational Conference on Learning Representations \(ICLR\),Cited by:[§5](https://arxiv.org/html/2608.21690#S5.SS0.SSS0.Px1.p1.1)\.

## Appendix ADetailed Breakdowns of Benchmark Results

### A\.1Per\-Question\-Type Results on LongMemEval

Table[5](https://arxiv.org/html/2608.21690#A1.T5)reports Scroll’s per\-question\-type accuracy on theSandMsplits of LongMemEval under the protocol of Section[3\.3](https://arxiv.org/html/2608.21690#S3.SS3)\. The degradation fromStoMis concentrated in question types that require aggregating evidence across many sessions: multi\-session accuracy drops from 88\.0% to 81\.2% and single\-session \(preference\) from 100\.0% to 83\.3%\. With more irrelevant sessions, the agent\-written code reliably locates a single supporting session but often misses part of the evidence\.

Table 5:Per\-question\-type accuracy \(%\) of Scroll on LongMemEvalSand LongMemEvalM\(backbone: Qwen3\.8\-Max\)\. Question types follow the benchmark taxonomy\[[31](https://arxiv.org/html/2608.21690#bib.bib7)\]\.
### A\.2Per\-Category Results on BEAM

Table[6](https://arxiv.org/html/2608.21690#A1.T6)breaks BEAM10Mdown by memory ability\. We compare against Mem0, Hindsight, and Exabase M\-1, the baselines for which per\-category BEAM10Mresults are publicly available as of August 15, 2026\[[19](https://arxiv.org/html/2608.21690#bib.bib28),[5](https://arxiv.org/html/2608.21690#bib.bib25),[9](https://arxiv.org/html/2608.21690#bib.bib41)\]; Cognee and Honcho report only overall scores\. Mem0, as a representative of the ingestion\-heavy, fixed\-pipeline paradigm, makes the contrast with Scroll’s query\-time approach most visible at the category level\.

Table 6:Per\-category judge scores on BEAM10M\. Categories follow the benchmark’s ten memory abilities\[[27](https://arxiv.org/html/2608.21690#bib.bib24)\]\. Scroll uses Qwen3\.8\-Max with thinking on; baseline breakdowns are taken from their published evaluations and use different configurations, so cross\-system comparison is indicative rather than controlled\.Scroll leads by the widest margins where the answer hinges on a few exact records that must be located in the raw history and then ordered or reconciled: knowledge update \(92\.5 vs\. 45\.0–75\.0\), contradiction resolution \(88\.1 vs\. 32\.5–58\.8\), and information extraction \(75\.0 vs\. 51\.2–66\.3\)\. These categories punish write\-time compression: resolving an update or a contradiction needs both sides of the value timeline, in order, with provenance, whereas retrieval over an ingested store typically surfaces the current state of a fact without its ordered history\. The degree varies by system \(Mem0’s add\-only extraction preserves old facts and holds up on knowledge update at 75\.0\), but none matches recovering the evidence by address from the verbatim Event Log\.

Conversely, Scroll underperforms the strongest baselines where the graded artifact is itself a condensed view over many records: summarization \(70\.5 vs\. 91\.9 for Exabase M\-1\), preference following \(89\.1 vs\. 97\.5 for Hindsight\), and temporal reasoning \(47\.5 vs\. 58\.8 for Exabase M\-1\)\. Ingestion\-heavy pipelines build digests and preference profiles at write time, so the condensed view already exists when the question arrives; Scroll must reconstruct it from raw events per query, and its residual failures there are errors of query formulation rather than retrieval \(Appendix[D](https://arxiv.org/html/2608.21690#A4)\)\.

Multi\-session reasoning remains the weakest category for every system \(9\.6–26\.1\); Scroll’s misses stem from over\-precise filters that undercount the evidence set rather than from unreachable records\. This profile is consistent across our repeated runs: contradiction resolution and knowledge update are among Scroll’s strongest categories in every run, multi\-session reasoning and summarization among its weakest\.

## Appendix BAdditional LOCA Results

#### Comparison with published results\.

Table[7](https://arxiv.org/html/2608.21690#A2.T7)places Scroll alongside the best publicly reported results from the LOCA paper\[[35](https://arxiv.org/html/2608.21690#bib.bib1)\]and its leaderboard\. These systems use different backbone models, so the comparison is system\-level rather than controlled\.

Table 7:System\-level comparison on LOCA\. Results for prior systems are taken from the LOCA paper\[[35](https://arxiv.org/html/2608.21690#bib.bib1)\]or its public leaderboard and use different backbone models; “–” denotes no publicly reported result\.

## Appendix CFull Prompts and Rubrics

Beyond the shared system prompt and context\-management rules of Section 3\.2, each memory benchmark contributes one rubric, reproduced below\. For LOCA we use the benchmark’s official task instructions unmodified, adding only environment metadata \(available APIs and workspace paths\)\.

BEAM rubric The user's benchmark conversation history is stored in your durable history as rows with kind='beam\_chat\_turn'\. Rows are chronologically ordered by seq; each session has a distinct session\_id; rows carry an ISO created\_at\.Recall it with the recall\_history\_python tool: pass a Python cell that uses the pre\-bound ms surface\. Search with concise keyword or synonym queries, e\.g\. ms\.search\(QUERY, all\_agents=True, kind='beam\_chat\_turn', k=10\)\. Uppercase OR passes through as a boolean operator; otherwise terms are AND\-combined\. Start with k=5 or k=10 and increase it only when the evidence is insufficient\. If a question combines multiple named systems, efforts, or entities, search each one separately instead of putting every name into one AND query\. Extract one directly relevant value for each part, preserve its unit, and only then calculate\. Each hit already includes the full turn text together with its seq, session\_id, role, and metadata; do not call ms\.expand merely to pair a user message with its assistant reply\. If you must reread a returned turn, call ms\.expand only with that hit's exact seq neighbours \(lo, hi\)\. For a question about one source date or an inclusive date range, filter on the created\_at column \(ISO\-8601 text, lexically sortable\) with ms\.sql\_query, e\.g\. "SELECT seq, session\_id, role, created\_at, content FROM hist\.conversation\_history WHERE kind='beam\_chat\_turn' AND substr\(created\_at,1,10\) BETWEEN '2024\-07\-01' AND '2024\-07\-31' ORDER BY seq LIMIT 50"\. For elapsed calendar days between two dates, use ms\.days\_between\(d1, d2\)\.Treat role='user' rows as evidence of the user's facts, actions, and preferences; an assistant suggestion is not evidence that the user adopted it\. Preserve exact numbers, units, and version labels from the most directly relevant user evidence; do not replace them with illustrative values\. Do not add repeated historical mentions as separate quantities unless the question explicitly asks for that\. When a fact changed, use the latest user evidence only after confirming that the rows describe the same project and the same fact, not merely similarly named work\. Base your answer only on recalled conversation evidence\. Do not use information from other history kinds\. Follow any output\-count or formatting constraint in the question exactly\. If the requested fact is absent, say so clearly\.Grounding rule \(strict\): every concrete claim \-\-\- each fact, number, name, date, quantity, or event \-\-\- must come verbatim in meaning from a turn you retrieved\. Never invent specifics to make an answer sound complete\.Decide between answering and saying "not enough information" by what you actually retrieved, not by how hard you searched: if a turn directly states the asked\-for fact, give it; if none does, say there is not enough information in the conversation\. A turn on a merely related topic is not the fact, and "not enough information" is itself a correct, expected answer\.Always finish with submit\_answer and a non\-empty, natural\-language answer\. Once more searching stops improving your answer, commit it rather than continuing until you run out\. Never end without one\.

LongMemEval rubric The user's benchmark conversation history is stored in your durable history as rows with kind='context\_msg' \(user turns\) or kind='model\_turn' \(assistant turns\)\. Every turn's content opens with a \[Session N \| YYYY\-MM\-DD\] role: tag\. Rows are chronologically ordered by seq; each session has a distinct session\_id; rows carry an ISO created\_at\.Recall it with the recall\_history\_python tool: pass a Python cell that uses the pre\-bound ms surface\. Search with concise keyword or synonym queries, e\.g\. ms\.search\(QUERY, all\_agents=True, kind='context\_msg', k=10\)\. Uppercase OR passes through as a boolean operator; otherwise terms are AND\-combined\. Start with k=5 or k=10 and increase it only when the evidence is insufficient\. If a question combines multiple named systems, efforts, or entities, search each one separately instead of putting every name into one AND query\. Extract one directly relevant value for each part, preserve its unit, and only then calculate\. Each hit already includes the full turn text together with its seq, session\_id, role, and metadata; do not call ms\.expand merely to pair a user message with its assistant reply\. If you must reread a returned turn, call ms\.expand only with that hit's exact seq neighbours \(lo, hi\)\. For a question about one source date or an inclusive date range, filter on the created\_at column \(ISO\-8601 text, lexically sortable\) with ms\.sql\_query, e\.g\. "SELECT seq, session\_id, role, created\_at, content FROM hist\.conversation\_history WHERE kind='context\_msg' AND substr\(created\_at,1,10\) BETWEEN '2023\-04\-01' AND '2023\-04\-30' ORDER BY seq LIMIT 50"\. For elapsed calendar days between two dates, use ms\.days\_between\(d1, d2\)\.Treat role='user' rows as evidence of the user's facts, actions, and preferences; an assistant suggestion is not evidence that the user adopted it\. Preserve exact numbers, units, and version labels from the most directly relevant user evidence; do not replace them with illustrative values\. Do not add repeated historical mentions as separate quantities unless the question explicitly asks for that\. When a fact changed, use the latest user evidence only after confirming that the rows describe the same project and the same fact, not merely similarly named work\. Base your answer only on recalled conversation evidence\. Do not use information from other history kinds\. Follow any output\-count or formatting constraint in the question exactly\. If the requested fact is absent, say so clearly\.GROUNDING \(strict\): every concrete claim \-\- each fact, number, name, date, quantity, or event \-\- must come verbatim in meaning from a turn you retrieved\. Never invent specifics to make an answer sound complete\.Decide between answering and abstaining by what you actually retrieved, not by how hard you searched: if a turn directly states the asked\-for fact, give it; if none does, abstain with the exact phrase "I don't have that information from our conversations\." A turn on a merely related topic is not the fact, and abstaining is itself a correct, expected answer when the fact is truly absent\.Always finish with submit\_answer and a non\-empty, natural\-language answer\. Once more searching stops improving your answer, commit it rather than continuing until you run out\. Never end without one\.

## Appendix DExample Trajectories

This appendix reproduces four trajectories from the BEAM10Mrun reported in Table[6](https://arxiv.org/html/2608.21690#A1.T6)\(Scroll with Qwen3\.8\-Max, extended reasoning enabled\): two successes from the categories where Scroll scores highest \(knowledge update, 92\.5; contradiction resolution, 88\.1\) and two failures from the categories where it trails the best published systems \(preference following, 89\.1 vs\. 97\.5 for Hindsight; summarization, 70\.5 vs\. 91\.9 for Exabase M\-1\)\.

Each trajectory is shown in its logged JSON format \(task\_id,metrics,steps\), abridged as follows\. Model\-authored code is moved from each step’s"source"field into the referenced code block and is otherwise unedited, including the model’s own comments\."reasoning"\(the model’s thinking before the action\) and"observation"strings are excerpted, with elisions marked\[\.\.\.\]; newlines inside strings are rendered literally , and non\-ASCII punctuation is normalized\. Gray//lines are our annotations, not part of the log; the steps our trajectory analysis identifies as decisive for the probe’s outcome are flagged in bold color \(// \>\>steps that drive the success,// \>\>steps where the failure is decided\)\.seqdenotes an event’s immutable Event Log address;\[Session n \| date\]prefixes are part of the stored events\. Judge scores are those of the benchmark\-provided LLM judge\.

### D\.1Success \(knowledge update\): resolving a superseded value by Event Log order

Probe\(task10M\-1, category*knowledge update*; judge score 1\.0 on all four rubric criteria\): *“How many tasks have I logged in Jira for the sprint on 2024\-11\-05, and what is my sprint completion target percentage?”*

The queried values are updated*within*the relevant session \(Session 42; 14→\\to17 tasks, 85%→\\to88%\), amid decoy sprints in Sessions 4, 22, and 47\. The trajectory resolves the update by Event Log order: one search, one SQL materialization, then in\-kernel filters over the cached variable\.

\{"task\_id":"beam/10M\-1",

"metrics":\{"tokens\_in":51224,"tokens\_out":1471,"wall\_time\_s":36\.62,"step\_count":5\},

"steps":\[

// \>\> Success: One coarse search pins the right session \(42\) among the

// \>\> decoy sprints \(Sessions 4, 22, 47\), and both competing values already surface

// \>\> in the hits

\{"step\_index":0,

"reasoning":"IneedtofindthementionsofJiratasksforthesprinton2024\-11\-05,andthesprintcompletiontargetpercentage\.Letmesearchforthese\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[1](https://arxiv.org/html/2608.21690#LST1)\}\},

"observation":"

stdout:

834942\[Session42\|2024\-11\-05\]user:I’mtryingtoupdatethetaskcountinJiratoreflectthenewtotalof17tasks,andIwanttomakesureI’mdoingitcorrectlytomeetoursprintcompletiontargetof

\[\.\.\.\]

812342\[Session42\|2024\-11\-05\]user:I’mtryingtoplanmysprintandI’veadded14tasksfordynamicresizing,aimingfor85%sprintcompletion\.I’musingJira9

\[\.\.\.\]

835042\[Session42\|2024\-11\-05\]assistant:Great\!Let’supdatethetaskcountinJiratoreflectthenewtotalof17tasksandensureyou’reontracktomeetyoursprintcompletiontargetof88%\.

\[\.\.\.\]

5654\[Session4\|2024\-07\-05\]user:I’veadded10feasibilitytaskstomyJiraboard,targeting85%completionwithint

\[\.\.\.\]

428322\[Session22\|2024\-08\-05\]user:I’musingJira9\.5\.0tomanagemyproject,andI’veadded18tasksforingestionstrateg

\[\.\.\.\]"\},

\{"step\_index":1,

"reasoning":"ThesearchresultsshowSession42\(2024\-11\-05\)whichistherelevantsession\.\[\.\.\.\]thevalueCHANGEDovertime\.Letmelookatthefullsession42tofindthemostrecentvaluesmentioned\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[2](https://arxiv.org/html/2608.21690#LST2)\}\},

"observation":"

stdout:

seq=8047role=user:\[Session42\|2024\-11\-05\]user:I’mworkingonenhancingtheRAGsystem’scontextwindowmanagement,specificallyfocusingondynamicresizingbasedonquerycomplexity,an

\[\.\.\.\]

\[outputtoolong:96806charsprinted,overthe32000\-charlimit\-\-therestishiddentoprotectyourcontextwindow\.Yourvariablespersist,sore\-runprintingLESS:acountorlistofseqs,snippet=Trueforaboundedtriageview,oraggregateinavariableandprintonlytheresult\-\-notwholerows\.\]"\},

\{"step\_index":2,

"reasoning":"Theresultwastoolong\.Letmeprintless\-justtheuserturnsandkeysnippetsabouttaskcountsandsprintcompletionpercentagesfromSession42\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[3](https://arxiv.org/html/2608.21690#LST3)\}\},

"observation":"

\[\.\.\.\]

seq=8047:\[Session42\|2024\-11\-05\]user:I’mworkingonenhancingtheRAGsystem’scontextwindowmanagement,specificallyfocus

\[\.\.\.\]"\},

// \>\> Success: establishes intra\-session order by seq \-\- 8123 \(14 tasks,

// \>\> 85%\) precedes 8349 \(17 tasks, 88%\) \-\- exactly the evidence needed to ensure

// \>\> latest information holds

\{"step\_index":3,

"reasoning":"Ifoundkeyevidence:Session42on2024\-11\-05\.\[\.\.\.\]Ineedtocheckifthereareanylatermentionsinsession42thatupdatethesevaluesfurther\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[4](https://arxiv.org/html/2608.21690#LST4)\}\},

"observation":"

\[\.\.\.\]

seq=8123:\[Session42\|2024\-11\-05\]user:I’mtryingtoplanmysprintandI’veadded14tasksfordynamicresizing,aimingfor85%sprintcompletion\.I’musingJira9\.6\.0totrackmyprogress,butI’mnotsurehowtoprioritizemytasksandallocatemytimee

\[\.\.\.\]

seq=8349:\[Session42\|2024\-11\-05\]user:I’mtryingtoupdatethetaskcountinJiratoreflectthenewtotalof17tasks,andIwanttomakesureI’mdoingitcorrectlytomeetoursprintcompletiontargetof88%

\[\.\.\.\]"\},

\{"step\_index":4,

"reasoning":"\[\.\.\.\]1\.seq=8123:Usersays"I’veadded14tasksfordynamicresizing,aimingfor85%sprintcompletion"\[\.\.\.\]Thequestionasksspecificallyabout"thesprinton2024\-11\-05"\.Themostrecentmentionwithinthatsprintisseq=8349with17tasksand88%completiontarget\.\[\.\.\.\]",

"action":\{"tool":"submit\_answer",

"args":\{"answer":"

Forthesprinton2024\-11\-05,youlogged\*\*17tasks\*\*inJira\(updatedfromanearliercountof14\),andyoursprintcompletiontargetpercentageis\*\*88%\*\*\(updatedfromtheinitial85%\)\."\}\}\}

\]\}’

Code Block 1:Knowledge update: full\-text search; each hit returns its Event Log address \(seq\), session, and snippet\.hits=ms\.search\("sprint2024\-11\-05",scope=’task’,k=20\)

forhinhits:

print\(h\["seq"\],h\["step\_index"\],h\["snippet"\]\[:200\]\)

Code Block 2:SQL materialization of Session 42 in address order, bound to the kernel variablerows\.rows=ms\.sql\_query\(

"SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=42ORDERBYmsg\_index"

\)

forrinrows:

print\(f"seq=\{r\[’seq’\]\}role=\{r\[’role’\]\}:\{r\[’content’\]\[:300\]\}"\)

print\("\-\-\-"\)

Code Block 3:In\-kernel filter of the cachedrows\(user turns only\); no Event Log access\.forrinrows:

ifr\[’role’\]==’user’:

print\(f"seq=\{r\[’seq’\]\}:\{r\[’content’\]\[:200\]\}"\)

print\("\-\-\-"\)

Code Block 4:Second in\-kernel filter \(user turns,seq≥\{\\geq\}8100\), exposing the value progression\.forrinrows:

ifr\[’role’\]==’user’andr\[’seq’\]\>=8100:

content=r\[’content’\]

print\(f"seq=\{r\[’seq’\]\}:\{content\[:250\]\}"\)

print\("\-\-\-"\)

### D\.2Success \(contradiction resolution\): retrieving both sides of a conflict and ordering them

Probe\(task10M\-10, category*contradiction resolution; judge score 1\.0 on all four rubric criteria*\): *“Has Pamela ever helped coordinate with vendors or saved setup time during my events?”*

The rubric requires stating that the record is contradictory, citing the user’s correction, citing the earlier claim, and resolving which is correct\. The trajectory operationalizes this as a retrieval program: one query per side of the conflict, provenance checks on both, and an address\-bounded search that proves no later reversal\.

\{"task\_id":"beam/10M\-10",

"metrics":\{"tokens\_in":104160,"tokens\_out":5758,"wall\_time\_s":132\.78,"step\_count":10\},

"steps":\[

\{"step\_index":0,

"reasoning":"\[\.\.\.\]IneedtofindallmentionsofPamelaandvendorcoordination/setuptime,identifytheconflict,anddeterminewhichstatementisthelatestoracorrection\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[5](https://arxiv.org/html/2608.21690#LST5)\}\},

"observation":"

stdout:

1690073\.\.\.Certainly\!ItsoundslikePamelatookinitiativetogatherquickratingsfromthreevendors,whichhelpedstreamlinethefeedbackprocessandsaved

\[\.\.\.\]

843436\.\.\.1\.\*\*MorningSetup\*\*:

\-\*\*Pamela\*\*:Supervisethearrivalandsetupofvendorsanddecorators\.

\[\.\.\.\]

725431\.\.\.GreattohearthatPamelaisheretohelp\!Givenherexperienceandmaturity,shecanbeavaluableassetinmanagingt

\[\.\.\.\]"\},

// \>\> Success: the model authors an opposing, negation\-term query for the

// \>\> ’against’ side of the conflict; the user’s correction surfaces at seq 8867

\{"step\_index":1,

"reasoning":"ThesearchresultsareshowingthatPamelacoordinatedwithvendors\.NextIneedtofindthecontradictoryinformation\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[6](https://arxiv.org/html/2608.21690#LST6)\}\},

"observation":"

\[\.\.\.\]

886737\[Session37\|2023\-07\-15\]user:HowcanImakesurePamelaisawareshedidn’tactuallybriefanyentertainersorsavemecoordinationtime,asthat

\[\.\.\.\]"\},

\{"step\_index":2,

"reasoning":"Thesearchresultatseq8867\(Session37\)lookslikeithaskeyinformation\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[7](https://arxiv.org/html/2608.21690#LST7)\}\},

"observation":"

stdout:

8867user

\[Session37\|2023\-07\-15\]user:HowcanImakesurePamelaisawareshedidn’tactuallybriefanyentertainersorsavemecoordinationtime,asthatwasamisunderstanding?

\-\-\-"\},

\{"step\_index":3,

"reasoning":"\[\.\.\.\]NowIneedtocheckwhatwassaidearlieraboutPamelacoordinatingwithvendorsorsavingsetuptime\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[8](https://arxiv.org/html/2608.21690#LST8)\}\},

"observation":"

\[\.\.\.\]

seq8675\[user\]:\[Session37\|2023\-07\-15\]user:What’sthemostefficientwaytobriefthe5entertainers,asPamelahadtakenonthistaskearlier?

\[\.\.\.\]"\},

\{"step\_index":4,

"reasoning":"\[\.\.\.\]Letmelookattheseq16900and16902hitsfromSession73,whichseemtodiscussPamela’svendorratingsandsavedtime\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[9](https://arxiv.org/html/2608.21690#LST9)\}\},

"observation":"

\[\.\.\.\]

seq16902\[assistant\]:

\[Session73\|2023\-08\-22\]assistant:You’rewelcome\!I’mgladthatclarifyingPamela’sactionshelpedyouunderstandhowherquickcallssavedyoutimeandprovidedimmediateinsights\.

\[\.\.\.\]

2\.\*\*TimeSaved\*\*:Byhandlingthesecallsherself,Pamelasavedyouapproximately15minutesoffollow\-uptime\.

\[\.\.\.\]"\},

\{"step\_index":5,

"reasoning":"\[\.\.\.\]thisisassistant\-generatedtext,nottheuser’sownstatement\.Ineedtocheckwhethertheuserinsession73actuallysaidsomethingthatledtothisassistantresponse,orifthiswa\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[10](https://arxiv.org/html/2608.21690#LST10)\}\},

"observation":"

\[\.\.\.\]

seq16899\[user\]:\[Session73\|2023\-08\-22\]user:CanyouhelpmeunderstandwhyPamelacalled3vendorsforquickratings,andhowitsavedme15minutesoffollow\-up?

\[\.\.\.\]

seq16901\[user\]:\[Session73\|2023\-08\-22\]user:Yeah,thatmakessense\.Pamela’squickcallsdefinitelysavedmetime\.It’sgoodtogetthoseimmediateinsightswithouthavingtofollowupmyself\.Thanksforclarifying\!

\[\.\.\.\]"\},

\{"step\_index":6,

"reasoning":"\[\.\.\.\]ThecorrectioninSession37isaboutPamelaNOTbriefingentertainersorsavingcoordinationtime\(amisunderstanding\)\.\[\.\.\.\]InSession73,theuserconfirmsPamelacalled3vendorsforquickratingsandsaved15minutesoffollow\-uptime\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[11](https://arxiv.org/html/2608.21690#LST11)\}\},

"observation":"

\[\.\.\.\]

seq8868\[assistant\]:\[Session37\|2023\-07\-15\]assistant:ToclarifythemisunderstandingwithPamelaandensuresheisawarethatshedidnotactuallybriefanyentertainersorsavecoordinationtime,it’simportanttocommunicatethisinformation

\[\.\.\.\]"\},

\{"step\_index":7,

"reasoning":"\[\.\.\.\]\*\*Earlierclaims\(pre\-correction\):\*\*Multiplesessions\(31,36\)hadassistantsuggestionsaboutPamelasupervisingvendorarrival/setup,coordinatingwithvendors,etc\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[12](https://arxiv.org/html/2608.21690#LST12)\}\},

"observation":"

\[\.\.\.\]

seq7496\[assistant\]:\[Session31\|2023\-07\-10\]assistant:DelegatingtaskslikedecoroversighttosomeonelikePamelacanhaveasignificantpositiveimpactontheoveralltimeli

\[\.\.\.\]

seq8434\[assistant\]:\[Session36\|2023\-07\-15\]assistant:Thatsoundslikeanexcellentplan\!ByleveragingPamela’sskillsandexperience,youcanensurethattheguestcheck\-in

\[\.\.\.\]"\},

// \>\> Success: the disconfirming query \-\- an address\-bounded search proving

// \>\> nothing after Session 73 overturns the correction\.

// \>\> Across this run, successful trajectories issue such a query before

// \>\> submitting; but failed ones never do

\{"step\_index":8,

"reasoning":"\[\.\.\.\]Thelaterstatement\(Session73\)wouldnormallywin\.ButIneedtocheckifthere’salatercorrectionafterSession73aswell\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[13](https://arxiv.org/html/2608.21690#LST13)\}\},

"observation":"

stdout:

1807777\[Session77\|2023\-08\-24\]user:Yeah,itdefinitelycausedsomefrustration\.Those5guestsw

\[\.\.\.\]"\},

\{"step\_index":9,

"reasoning":"\[\.\.\.\]Sotheresolutionisnuanced:TheusercorrectedthatPameladidNOTbriefentertainersorsavecoordinationtimeduringsetup\(thatwasamisunderstanding\),butlaterconfirmedPamelaDIDhelpbycallingvendorsforquickratings,savingfollow\-uptime\[\.\.\.\]",

"action":\{"tool":"submit\_answer",

"args":\{"answer":"

Theconversationcontainsconflictinginformationaboutthis,andhere’showitresolves:

\*\*Theinitialclaim:\*\*Inearliersessions\(aroundSessions31\-36\),plansweremadeforPamelatocoordinatewithvendors,supervisevendorarrivals/setup,andbriefentertainers\-\-withtheexpectationthatthiswouldsaveyoucoordinationtimeduringtheevent\.

\*\*Yourcorrection\(Session37,July15,2023\):\*\*Youexplicitlyclarifiedthatthiswasamisunderstanding\-\-PameladidNOTactuallybriefanyentertainersorsaveyoucoordinationtimeduringsetup\.YouaskedhowtomakesurePamelawasawareofthiscorrection\.

\*\*Alater,narrowerconfirmation\(Session73,August22,2023\):\*\*YouconfirmedthatPameladidcall3vendorsforquickratingsaftertheevent,whichsavedyouabout15minutesoffollow\-uptime\.Yousaid:"Pamela’squickcallsdefinitelysavedmetime\."

\*\*Resolution:\*\*ThebroadclaimthatPamelacoordinatedvendorsandsavedsetuptimeduringyoureventswascorrectedbyyouasamisunderstanding\(Session37\)\.However,Pameladidhelpinamorelimited,post\-eventway\-\-gatheringquickvendorratingsthatsavedyou~15minutesoffollow\-up\(Session73\)\.Soshedidn’tsavesetuptimeorcoordinatevendorsduringtheeventitself,butshedidcontributeafterwardwithvendorfeedbackcalls\."\}\}\}

\]\}"

Code Block 5:Contradiction resolution: full\-text search on the claim side\.hits=ms\.search\("Pamelavendor",scope=’task’,k=20\)

forhinhits:

print\(h\["seq"\],h\["step\_index"\],h\["snippet"\]\[:150\]\)

Code Block 6:Negation\-term search for the correction side\.hits2=ms\.search\("Pameladidn’tORwasn’tORneverORnot",scope=’task’,k=20\)

forhinhits2:

print\(h\["seq"\],h\["step\_index"\],h\["snippet"\]\[:150\]\)

Code Block 7:Exact materialization of the correction \(ms\.expand\)\.rows=ms\.expand\(\[8867\]\)

forrinrows:

print\(r\["seq"\],r\["role"\]\)

print\(r\["content"\]\[:2000\]\)

print\("\-\-\-"\)

Code Block 8:Session\-scoped SQL over Session 37\.rows=ms\.sql\_query\("SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=37ORDERBYseqLIMIT30"\)

forrinrows:

print\(f"seq\{r\[’seq’\]\}\[\{r\[’role’\]\}\]:\{r\[’content’\]\[:200\]\}"\)

print\("\-\-\-"\)

Code Block 9:Expansion of the post\-correction mentions \(seq16900, 16902\)\.rows=ms\.expand\(\[16900,16902\]\)

forrinrows:

print\(f"seq\{r\[’seq’\]\}\[\{r\[’role’\]\}\]:"\)

print\(r\["content"\]\[:600\]\)

print\("\-\-\-"\)

Code Block 10:Provenance check—the user turns aroundseq16900\.rows=ms\.sql\_query\("SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=73ANDseqBETWEEN16890AND16910ORDERBYseq"\)

forrinrows:

print\(f"seq\{r\[’seq’\]\}\[\{r\[’role’\]\}\]:\{r\[’content’\]\[:300\]\}"\)

print\("\-\-\-"\)

Code Block 11:The assistant’s uptake of the correction \(seq8868\)\.rows=ms\.sql\_query\("SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=37ANDseqBETWEEN8867AND8870ORDERBYseq"\)

forrinrows:

print\(f"seq\{r\[’seq’\]\}\[\{r\[’role’\]\}\]:\{r\[’content’\]\[:500\]\}"\)

print\("\-\-\-"\)

Code Block 12:The original claim side \(Sessions 31 and 36\)\.rows=ms\.expand\(\[7496,8434\]\)

forrinrows:

print\(f"seq\{r\[’seq’\]\}\[\{r\[’role’\]\}\]:\{r\[’content’\]\[:400\]\}"\)

print\("\-\-\-"\)

Code Block 13:seq\_range\-bounded search over the remainder of the history, proving no later reversal\.hits3=ms\.search\("PamelamisunderstandingORcorrectionORdidn’tORwasn’t",scope=’task’,k=15,seq\_range=\(16900,23716\)\)

forhinhits3:

print\(h\["seq"\],h\["step\_index"\],h\["snippet"\]\[:200\]\)

### D\.3Failure \(preference following\): competent retrieval on the wrong axis

Probe\(task10M\-8, category*preference following*; judge score 0\.0 on all three rubric criteria\): *“I’m planning the route for our upcoming trip\. How would you suggest I map it out?”*

All three criteria concern one stated preference: avoiding tolls\. The retrieval patterns that succeed elsewhere all execute correctly here—the failure is upstream, in query formulation: the model frames the probe as*which tool*the user prefers and never queries the*route\-constraint*axis\. The graded preference is abundant in the Event Log, in the user’s own words \(seq 805: “which route would you say is better for someone who wants to avoid tolls as much as possible?”; seq 807; Session 3, seq 617–631, where the hybrid route is adopted because it saves $15 in tolls\)\.

\{"task\_id":"beam/10M\-8",

"metrics":\{"tokens\_in":82830,"tokens\_out":2471,"wall\_time\_s":69\.19,"step\_count":7\},

"steps":\[

// \>\> Failure: the outcome is decided here, before any retrieval runs \-\-

// \>\> the probe is framed as ’which mapping tool’, all six queries name tools, and

// \>\> none of the trajectory’s 14 queries contains toll, fee, avoid, or cost,

// \>\> which is the axis all three rubric criteria grade

\{"step\_index":0,

"reasoning":"\[\.\.\.\]Ineedtofindapreferencetheyestablishedearlier\-\-achosentool,version,style,orconstraint\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[14](https://arxiv.org/html/2608.21690#LST14)\}\},

"observation":"

stdout:

1001643\.\.\.Draganddroptheroutelinestoadjustthepathaccordingtothedetour\.

\[\.\.\.\]

814834\.\.\.Comparetheroutestoseewhichoneavoidstolls\.

\[\.\.\.\]

6623\.\.\.SyncwithGoogleMaps

WhileyoucannotdirectlysyncGoogleMapswithGasBuddy,youcanusebothappstogether

\[\.\.\.\]"\},

// \>\> Failure: the toll preference brushes past in the previous step’s hits

// \>\> \(seq 8148, ’avoids tolls’\) and goes unpursued; the model chases the Maps\.me

// \>\> tool candidate instead

\{"step\_index":1,

"reasoning":"\[\.\.\.\]Letmealsocheckseq16614whichmentionsMaps\.measa"CurrentTool"\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[15](https://arxiv.org/html/2608.21690#LST15)\}\},

"observation":"

\[\.\.\.\]

16614\[Session75\|2023\-04\-20\]assistant:ImprovingyourdetouraccuracyandsavingtimewithnavigationtoolslikeMaps\.meisagreatachievement\.Herearesomeothern

\[\.\.\.\]"\},

\{"step\_index":2,

"reasoning":"\[\.\.\.\]that’sanassistantresponse\.Ineedtofindwheretheuserexplicitlystatestheirpreferenceforamappingtool\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[16](https://arxiv.org/html/2608.21690#LST16)\}\},

"observation":"

\[\.\.\.\]

234910\.\.\.Thatsoundslikeasolidplan\!I’llmakesuretouseGoogleMapsandRoadtripperstomapoutthehybridrouteandshareitwithChris\.I’llalsodownloadoff

\[\.\.\.\]

1717577\[Session77\|2023\-04\-22\]user:Thatsoundsgreat\!I’lldefinitelyusemappingtoolslikeGoogleMapsandWazetoplanmyroutesandfindgoodstoppingpoints\.

\[\.\.\.\]"\},

\{"step\_index":3,

"reasoning":"\[\.\.\.\]Letmelookmorecloselyatthemostrecentuserturnsaboutmapping,especiallyinlatersessions\(82\-100\),\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[17](https://arxiv.org/html/2608.21690#LST17)\}\},

"observation":"

\(nooutput\)"\},

\{"step\_index":4,

"reasoning":"\[\.\.\.\]theuserhasconsistentlyused\*\*Roadtrippers\*\*and\*\*GoogleMaps\*\*together\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[18](https://arxiv.org/html/2608.21690#LST18)\}\},

"observation":"

\[\.\.\.\]

233510\.\.\.Thatsoundsperfect\!I’lluseGoogleMapsandRoadtripperstomapoutthehybridrouteandshareitwithChris\.We’lldefinitelyneedtodownloadofflinemapsfora

\[\.\.\.\]

25\[Session1\|2022\-05\-01\]user:HowdoestheRoadtrippersappwork,andcanitreallyhelpmevisualizearoutethatcoversatleast5nationalparks?

\[\.\.\.\]"\},

\{"step\_index":5,

"reasoning":"\[\.\.\.\]checkifthere’sanythinginthemostrecentsessions\(S100,seq22221\-22560\)aboutaspecificroutethey’replanningforthe"upcomingtrip\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[19](https://arxiv.org/html/2608.21690#LST19)\}\},

"observation":"

\[\.\.\.\]

22221user\[Session100\|2023\-05\-31\]user:What’sthebestwaytoplana1,200\-milenorthernroutewithin9months,aimingfor4keylandmarks,likeI’vetargeted?

\[\.\.\.\]"\},

//Theanswerisgroundedandwell\-structured,butwithouttollinformation\.

//Judge:0\.0onallthreecriteria\.

\{"step\_index":6,

"reasoning":"\[\.\.\.\]Themostrecentandrepeatedpreferenceis\*\*GoogleMapsandRoadtrippers\*\*usedtogether\.Theuserconsistentlysaysthey’llusebothtomapoutroutes\.\[\.\.\.\]",

"action":\{"tool":"submit\_answer",

"args":\{"answer":"

Basedonourpastconversations,you’veconsistentlyused\*\*GoogleMapsandRoadtrippers\*\*togethertomapoutyourroutes\-\-youmentionedthiscombinationmultipletimes,includingwhenplanningthehybridroutewithChrisandwhenscoutingscenicareas\.I’dsuggeststickingwiththatapproachforyourupcoming1,200\-milenorthernroutetoyour4keylandmarks:

\[\.\.\.\]

1\.\*\*Roadtrippersfirst\*\*\-\-Plotyour4landmarksaswaypointsanduseittodiscoverscenicstops,detours,andpointsofinterestalongthenorthernroute\.It’sgreatforvisualizingtheoveralltri

\[\.\.\.\]

Thistwo\-toolcombohasworkedwellforyouacrossmultipletrips,soitshouldserveyouwellforthisonetoo\."\}\}\}

\]\}"

Code Block 14:Preference following: multi\-query sweep, de\-duplicated by address; all six queries name tools\.hits=\[\]

forqin\["maproute","GoogleMaps","Roadtrippers","mappingtool","approute","mapout"\]:

hits\+=ms\.search\(q,scope=’task’,k=10\)

seen=set\(\)

forhinhits:

ifh\["seq"\]notinseen:

seen\.add\(h\["seq"\]\)

print\(h\["seq"\],h\["step\_index"\],h\.get\("snippet",""\)\[:150\]\)

print\("\-\-\-"\)

Code Block 15:Expansion of the Maps\.me candidate \(seq16614\)\.rows=ms\.expand\(\[16614\]\)

forrinrows:

print\(r\["seq"\],r\["content"\]\[:500\]\)

print\("\-\-\-"\)

Code Block 16:Preference\-phrase sweep plus a Roadtrippers query—still tool\-framed\.hits2=\[\]

forqin\["I’lluse","Iprefer","myfavorite","I’vebeenusing","Iuse"\]:

hits2\+=ms\.search\(f"\{q\}map",scope=’task’,k=10\)

hits3=ms\.search\("Roadtrippersrouteplan",scope=’task’,k=15\)

seen2=set\(\)

forhinhits2\+hits3:

ifh\["seq"\]notinseen2:

seen2\.add\(h\["seq"\]\)

print\(h\["seq"\],h\["step\_index"\],h\.get\("snippet",""\)\[:160\]\)

print\("\-\-\-"\)

Code Block 17:seq\_range\-bounded recency check over the final sessions\.hits4=ms\.search\("maprouteplan",seq\_range=\(18323,22716\),scope=’task’,k=20\)

forhinhits4:

ifh\.get\("role"\)=="user":

print\(h\["seq"\],h\["step\_index"\],h\.get\("snippet",""\)\[:180\]\)

print\("\-\-\-"\)

Code Block 18:User\-turn search plus session\-scoped SQL over Session 1\.hits5=ms\.search\("GoogleMapsRoadtrippersmapout",scope=’task’,k=15\)

forhinhits5:

ifh\.get\("role"\)=="user":

print\(h\["seq"\],h\["step\_index"\],h\.get\("snippet",""\)\[:200\]\)

print\("\-\-\-"\)

print\("\\n===Session1userturnsaboutRoadtrippers==="\)

rows\_s1=ms\.sql\_query\("SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=1ANDrole=’user’ANDcontentLIKE’%Roadtrippers%’ORDERBYmsg\_indexLIMIT5"\)

forrinrows\_s1:

print\(r\["seq"\],r\["content"\]\[:300\]\)

print\("\-\-\-"\)

Code Block 19:Reading the opening of Session 100 to scope the upcoming trip\.rows\_s100=ms\.sql\_query\("SELECTseq,role,contentFROMhist\.conversation\_historyWHEREkind=’conversation’ANDstep\_index=100ORDERBYmsg\_indexLIMIT10"\)

forrinrows\_s100:

print\(r\["seq"\],r\["role"\],r\["content"\]\[:250\]\)

print\("\-\-\-"\)

### D\.4Failure \(summarization\): positional sampling misses mid\-session evidence

Probe\(task10M\-8, category*summarization*; judge score 0\.42—two of six rubric criteria fully satisfied, one partially\): *“Can you summarize how my travel decisions and habits evolved from April 8, 2023 to April 25, 2023 and how they influenced my overall experience and personal growth?”*

Coverage at session granularity is complete: cells 0–6 page and merge all 4,448 events in the date range \(Sessions 61–80, verified gap\-free\)\. The score is then decided by sampling choices within that coverage: the trajectory reads long mixed\-topic sessions*positionally*\(head and tail\) rather than*thematically*, and the graded mid\-session facts—the 3\-hour driving cap with its fatigue reduction \(Session 77, seq 17171–17207\) and the sleep and hydration goals \(Session 66, seq 14809–14817\)—never enter an observation\.

\{"task\_id":"beam/10M\-8",

"metrics":\{"tokens\_in":197973,"tokens\_out":8846,"wall\_time\_s":221\.2,"step\_count":14\},

"steps":\[

\{"step\_index":0,

"reasoning":"\[\.\.\.\]First,Ineedtofindtheconversationswithinthisdaterange\.I’lltryusingSQLtofilterbydate\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[20](https://arxiv.org/html/2608.21690#LST20)\}\},

"observation":"

stdout:

1000

13611612023\-04\-08user\[Session61\|2023\-04\-08\]user:What’sthebestwaytospendourlastdayinLosAngelesbef

\[\.\.\.\]

\[note\]asql\_queryhitthe1000\-rowcap\-\-matchingrowsbeyondthefirst1000wereNOTreturned;narrowwithWHEREorpagewithLIMIT/OFFS

\[\.\.\.\]"\},

\{"step\_index":1,

"reasoning":"Theresultgotcutoffat1000rows\.Needtopaginate\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[21](https://arxiv.org/html/2608.21690#LST21)\}\},

"observation":"

stdout:

100013611146102023\-04\-13

61\[’2023\-04\-08’\]188

62\[’2023\-04\-09’\]222

63\[’2023\-04\-10’\]196

64\[’2023\-04\-11’\]190

65\[’2023\-04\-12’\]194

66\[’2023\-04\-13’\]10"\},

\{"step\_index":2,

"reasoning":"\[\.\.\.\]Ineedtofetchtheremainingperiod\(April13\-25\)\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[22](https://arxiv.org/html/2608.21690#LST22)\}\},

"observation":"

stdout:

1000

66\[’2023\-04\-13’\]268

67\[’2023\-04\-14’\]200

68\[’2023\-04\-15’\]198

69\[’2023\-04\-15’\]196

70\[’2023\-04\-15’\]138

156002023\-04\-15"\},

\{"step\_index":3,

"reasoning":"IneedtocontinuepagingthroughthedataandkeepcollectingtheremainingpagesuntilIreachApril25th\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[22](https://arxiv.org/html/2608.21690#LST22)\(OFFSET 1000\)\}\},

"observation":"

stdout:

1000166002023\-04\-20

\[\.\.\.\]"\},

\{"step\_index":4,

"reasoning":"Ontrack\-\-continuingthepagingtocoverApril20\-25\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[22](https://arxiv.org/html/2608.21690#LST22)\(OFFSET 2000\)\}\},

"observation":"

stdout:

1000176002023\-04\-24

\[\.\.\.\]"\},

\{"step\_index":5,

"reasoning":"\[\.\.\.\]Letmefetchthelastpage\(theremainderfromApril24thonwards\)tocompletethecoverage,\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[22](https://arxiv.org/html/2608.21690#LST22)\(OFFSET 3000\)\}\},

"observation":"

stdout:

458

79\[’2023\-04\-24’\]178

80\[’2023\-04\-25’\]280"\},

\{"step\_index":6,

"reasoning":"\[\.\.\.\]NextIneedtomergeeverythingintoonecompletedataset\(deduplication\),\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[23](https://arxiv.org/html/2608.21690#LST23)\}\},

"observation":"

\[\.\.\.\]

4448136112023\-04\-08180582023\-04\-25

\[\.\.\.\]

61\[’2023\-04\-08’\]1881361113798

\[\.\.\.\]

77\[’2023\-04\-22’\]4701690917378

\[\.\.\.\]

80\[’2023\-04\-25’\]2801777918058"\},

// \>\> Failure: the first of the two sampling choices that decide the score

// \>\> \-\- positional reading \(first 3 \+ last 2 user turns per session\);

// \>\> head\-and\-tail reads of 200\-470\-row mixed\-topic sessions systematically

// \>\> skip the middle, where habit threads sit

\{"step\_index":7,

"reasoning":"\[\.\.\.\]that’sabout2200userturns,waytoomuch\.Betterapproach:foreachsession,printthefirstfewandlastfewuserturns\.",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[24](https://arxiv.org/html/2608.21690#LST24)\}\},

"observation":"

\[\.\.\.\]

===Session61\(2023\-04\-08\)\-\-94userturns===

\[\.\.\.\]

13611:\[S61\|2023\-04\-08\]U:What’sthebestwaytospendourlastdayinLosAngelesbeforeheadinghome,consideringwe’restartingthefinalstretchofour2,500\-mi

\[\.\.\.\]"\},

// \>\> Failure: the deep read stays head\-only \(first 6 user turns of 7 sessions\);

// \>\> the graded driving\-limit arc sits 100 user turns into Session 77

// \>\> \(seq 17171\-17207\) and is never reached \-\- even though this read surfaces ’I’m

// \>\> trying to manage my travel fatigue’ \(Session 63\) as a lead

\{"step\_index":8,

"reasoning":"\[\.\.\.\]Tograspthemaincomponents,letmetrysamplingafewturnsfromeachsessioninmoredetail\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[25](https://arxiv.org/html/2608.21690#LST25)\}\},

"observation":"

\[\.\.\.\]

\#\#\#\#\#\#\#\#\#\#SESSION61\(2023\-04\-08\)\#\#\#\#\#\#\#\#\#\#

\[\.\.\.\]

\-\-\-seq13611\-\-\-

\[Session61\|2023\-04\-08\]user:What’sthebestwaytospendourlastdayinLosAngelesbeforeheadinghome,consideringwe’restartingthefinalstretchofou

\[\.\.\.\]"\},

// \>\> Failure: the second sampling choice \-\- the trajectory’s only thematic

// \>\> search covers growth vocabulary exclusively; the probe asks about

// \>\> ’decisions AND habits’, but no query ever names driving hours, fatigue,

// \>\> sleep, or hydration \(the graded habit dimensions\)

\{"step\_index":9,

"reasoning":"\[\.\.\.\]Letmesearchforgrowth\-relatedturnsandkeydecisionswithinafewsessions\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[26](https://arxiv.org/html/2608.21690#LST26)\}\},

"observation":"

\[\.\.\.\]

15489\.\.\.IfeellikeIlearnedalotaboutmyselfandourrelationshipduringthathike\.

\[\.\.\.\]"\},

\{"step\_index":10,

"reasoning":"\[\.\.\.\]Letmeexpandafewofthekeyseqstogetverbatimdetails\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[27](https://arxiv.org/html/2608.21690#LST27)\}\},

"observation":"

\[\.\.\.\]

===seq15489\|role=user===

\[Session70\|2023\-04\-15\]user:Yeah,theGrandCanyonhikewasdefinitelyastandoutmoment\.Itpushedusbothphysicallyandmentally,andseeingthecanyonwasbreathtaking\.ItmademerealizehowmuchIcanaccomplishwithdeterminationandteamwork\.Plus,itgavemeanewperspectiveonlifeandmademeappreciatenaturemore\.IfeellikeIlearnedalotaboutmyselfandourrelationshipduringthathike\.

\[\.\.\.\]"\},

\{"step\_index":11,

"reasoning":"\[\.\.\.\]letmegatherafewmorespecificpoints:budgetdetails\($250foodoverspend,Pittsburghdelay$70\),habitchanges\(session72,screentime\),\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[28](https://arxiv.org/html/2608.21690#LST28)\}\},

"observation":"

\[\.\.\.\]

HIT17368\.\.\.Inthiscase,thetotaloverspendonfoodis$250,with$60comingfromasingledinervisitinLA\.Here’sastructuredapproachto

\[\.\.\.\]"\},

\{"step\_index":12,

"reasoning":"\[\.\.\.\]Actually,Ihaveenoughmaterial\.\[\.\.\.\]",

"action":\{"tool":"recall\_history\_python",

"args":\{"source":Code Block[29](https://arxiv.org/html/2608.21690#LST29)\}\},

"observation":"

\[\.\.\.\]

\[Session79\|2023\-04\-24\]assistant:Limitingtripsto2stopsmaxplayedasignificantroleinmyoverallpersonalgrowth,particularlyinhandlingunexpecteddetoursandfee

\[\.\.\.\]"\},

\{"step\_index":13,

"reasoning":"\[\.\.\.\]Letmedoafinalcoveragecheckagainstwhatthequestionisask\[\.\.\.\]",

"action":\{"tool":"submit\_answer",

"args":\{"answer":"

\*\*Thearc,April8\-25,2023\(Sessions61\-80\):\*\*Yourtraveldecisionsevolvedthroughthreeclearphases:\(1\)\*\*wrap\-uplogistics\*\*inLosAngeles\(Apr8\-10\),\(2\)\*\*deliberaterestandthejourneyhome\*\*\(Apr13\-16\),and\(3\)\*\*post\-tripprocessing,sharing,andlesson\-building\*\*backinNewJeffreytow

\[\.\.\.\]

You\*\*quantifiedyourgrowth\*\*:40%morepatience\(laterframedasa40%increaseinconfidenceandadaptability\),35%moreflexibilityafterthe5unplanneddetours,andanoveralltrip\-growthself\-ratingof82%\.

\[\.\.\.\]

ByApril25youhaddistilled\*\*4keytriplessons\*\*\-\-"FlexibilityisKey"and"EmbraceSpontaneity"amongthem\-\-andbegunjournalingtosustainthegains\.Yourunplannedstopsreshapedyourfuturetravelphilosophy:looseritinerarieswithbuffertime,opennesstolocalrecommendations,andfewer,deeperstopsratherthanrigidday\-by\-dayplans\."\}\}\}

\]\}

Code Block 20:Summarization: date\-range SQL over event metadata \(2023\-04\-08 to 2023\-04\-25\)\.rows=ms\.sql\_query\(

"SELECTseq,step\_index,json\_extract\(metadata,’$\.date’\)ASdate,role,headline,substr\(content,1,200\)ASpreview"

"FROMhist\.conversation\_historyWHEREkind=’conversation’"

"ANDjson\_extract\(metadata,’$\.date’\)BETWEEN’2023\-04\-08’AND’2023\-04\-25’"

"ORDERBYmsg\_index"\)

print\(len\(rows\)\)

forrinrows:

print\(r\[’seq’\],r\[’step\_index’\],r\[’date’\],r\[’role’\],\(r\[’preview’\]or’’\)\[:120\]\.replace\(’\\n’,’’\)\)

Code Block 21:Per\-session aggregation of page 1 in the kernel\.rows\_all=list\(rows\)

print\(len\(rows\_all\),rows\_all\[0\]\[’seq’\],rows\_all\[\-1\]\[’seq’\],rows\_all\[\-1\]\[’date’\]\)

fromcollectionsimportdefaultdict

sess=defaultdict\(lambda:\{’dates’:set\(\),’roles’:0\}\)

forrinrows\_all:

sess\[r\[’step\_index’\]\]\[’dates’\]\.add\(r\[’date’\]\)

sess\[r\[’step\_index’\]\]\[’roles’\]\+=1

forsinsorted\(sess\):

print\(s,sorted\(sess\[s\]\[’dates’\]\),sess\[s\]\[’roles’\]\)

Code Block 22:Paging query; steps 3–5 rerun it changing only theOFFSET\.rows2=ms\.sql\_query\(

"SELECTseq,step\_index,json\_extract\(metadata,’$\.date’\)ASdate,role,substr\(content,1,180\)ASpreview"

"FROMhist\.conversation\_historyWHEREkind=’conversation’"

"ANDjson\_extract\(metadata,’$\.date’\)BETWEEN’2023\-04\-13’AND’2023\-04\-25’"

"ORDERBYmsg\_indexLIMIT1000OFFSET0"\)

print\(len\(rows2\)\)

rows2=list\(rows2\)

fromcollectionsimportdefaultdict

sess2=defaultdict\(lambda:\{’dates’:set\(\),’n’:0\}\)

forrinrows2:

sess2\[r\[’step\_index’\]\]\[’dates’\]\.add\(r\[’date’\]\)

sess2\[r\[’step\_index’\]\]\[’n’\]\+=1

forsinsorted\(sess2\):

print\(s,sorted\(sess2\[s\]\[’dates’\]\),sess2\[s\]\[’n’\]\)

print\(rows2\[\-1\]\[’seq’\],rows2\[\-1\]\[’date’\]\)

Code Block 23:Kernel\-side merge of all five pages, de\-duplicated byseq\.all\_turns=\{\}

forcollin\[rows\_all,rows2,rows3,rows4,rows5\]:

forrincoll:

all\_turns\[r\[’seq’\]\]=r

merged=\[all\_turns\[k\]forkinsorted\(all\_turns\)\]

print\(len\(merged\),merged\[0\]\[’seq’\],merged\[0\]\[’date’\],merged\[\-1\]\[’seq’\],merged\[\-1\]\[’date’\]\)

fromcollectionsimportdefaultdict

sess\_all=defaultdict\(lambda:\{’dates’:set\(\),’n’:0,’first\_seq’:None,’last\_seq’:None\}\)

forrinmerged:

d=sess\_all\[r\[’step\_index’\]\]

d\[’dates’\]\.add\(r\[’date’\]\)

d\[’n’\]\+=1

ifd\[’first\_seq’\]isNone:

d\[’first\_seq’\]=r\[’seq’\]

d\[’last\_seq’\]=r\[’seq’\]

forsinsorted\(sess\_all\):

print\(s,sorted\(sess\_all\[s\]\[’dates’\]\),sess\_all\[s\]\[’n’\],sess\_all\[s\]\[’first\_seq’\],sess\_all\[s\]\[’last\_seq’\]\)

Code Block 24:Positional sampling—first 3 and last 2 user turns per session\.fromcollectionsimportdefaultdict

sess\_turns=defaultdict\(list\)

forrinmerged:

sess\_turns\[r\[’step\_index’\]\]\.append\(r\)

forsinsorted\(sess\_turns\):

users=\[rforrinsess\_turns\[s\]ifr\[’role’\]==’user’\]

print\(f"===Session\{s\}\(\{users\[0\]\[’date’\]\}\)\-\-\{len\(users\)\}userturns==="\)

forrinusers\[:3\]\+users\[\-2:\]:

txt=r\[’preview’\]\.replace\(’\[Session’,’\[S’\)\.replace\(’\]user:’,’\]U:’\)

print\(f"\{r\[’seq’\]\}:\{txt\[:160\]\}"\)

print\(\)

Code Block 25:Head\-only deep read \(first 6 user turns\) of sessions 61, 63, 66, 70, 76, 77, 80\.importjson

deffull\_content\(seq\):

rr=ms\.sql\_query\("SELECTcontentFROMhist\.conversation\_historyWHEREseq=?",\(seq,\)\)

returnrr\[0\]\[’content’\]ifrrelseNone

forsin\[61,63,66,70,76,77,80\]:

ut=\[rforrinsess\_turns\[s\]ifr\[’role’\]==’user’\]

print\(f"\\n\#\#\#\#\#\#\#\#\#\#SESSION\{s\}\(\{ut\[0\]\[’date’\]\}\)\#\#\#\#\#\#\#\#\#\#"\)

forrinut\[:6\]:

c=full\_content\(r\[’seq’\]\)

print\(f"\\n\-\-\-seq\{r\[’seq’\]\}\-\-\-"\)

print\(c\[:600\]\)

Code Block 26:The trajectory’s only thematic search—growth vocabulary, bounded to the date range\.hits=\[\]

forqin\["personalgrowth","lessonslearned","personalgrowthtrip","growth","changedme","learnedaboutmyself"\]:

hits\+=ms\.search\(q,seq\_range=\(13611,18058\),scope=’task’,k=6\)

seen=\{\}

forhinhits:

ifh\[’seq’\]notinseen:

seen\[h\[’seq’\]\]=h

print\(len\(seen\)\)

forseq,hinsorted\(seen\.items\(\)\):

print\(seq,h\.get\(’snippet’,’’\)\[:160\]\.replace\(’\\n’,’’\)\)

Code Block 27:Verbatim expansion of eight growth\-evidence addresses\.rows=ms\.expand\(\[15138,15489,16441,16678,16824,17216,17712,17932\]\)

forrinrows:

print\(f"===seq\{r\[’seq’\]\}\|role=\{r\[’role’\]\}==="\)

print\(r\[’content’\]\[:900\]\)

print\(\)

Code Block 28:Targeted expansions plus two budget searches\.rows=ms\.expand\(\[16009,16018\]\)

forrinrows:

print\(f"===seq\{r\[’seq’\]\}\|role=\{r\[’role’\]\}==="\)

print\(r\[’content’\]\[:800\]\)

print\(\)

hits2=ms\.search\("Pittsburghdelay",seq\_range=\(13611,18058\),scope=’task’,k=5\)

forhinhits2:

print\("HIT",h\[’seq’\],h\.get\(’snippet’,’’\)\[:200\]\.replace\(’\\n’,’’\)\)

hits3=ms\.search\("foodoverspend",seq\_range=\(13611,18058\),scope=’task’,k=5\)

forhinhits3:

print\("HIT",h\[’seq’\],h\.get\(’snippet’,’’\)\[:200\]\.replace\(’\\n’,’’\)\)

Code Block 29:Final point reads \(seq16685, 17712\)\.r1=ms\.sql\_query\("SELECTcontentFROMhist\.conversation\_historyWHEREseq=16685"\)

print\(r1\[0\]\[’content’\]\[:500\]\)

r2=ms\.sql\_query\("SELECTcontentFROMhist\.conversation\_historyWHEREseq=17712"\)

print\(r2\[0\]\[’content’\]\[:300\]\)