PEEK: Context Map as an Orientation Cache for Long-Context LLM Agents #

1. TL;DR #

For agents that repeatedly query the same large external context (a 50k-entry feedback corpus, a code repo), PEEK caches the reusable "orientation knowledge" — what the context contains, how it is organized, key entities/constants/schemas — as a small constant-size context map kept resident in the system prompt. A programmable cache policy (Distiller → Cartographer → Evictor) maintains it from execution trajectories under a hard token budget. Result: +6.3–34.0% quality with 93–145 fewer iterations and 1.7–5.8× lower cost than ACE.

2. Q1 / Q2 / Q3 #

Q1 — 痛点 (what problem) #

Modern agents over recurring external contexts manage state in ways that each preserve the wrong object:

• Shared chat / history compaction keep the agent's prior trajectory — high-volume, low-density, and persisting full history actually hurts (see §5, Shared Chat row).
• RAG / context offloading / context compaction keep passive access to raw or condensed material, but never a curated artifact about the context itself.
• Prompt learning (ACE, Reflexion, GEPA) curates task-level strategies, not knowledge about the recurring context.

The gap: nothing actively maintains orientation knowledge about a recurringly-queried external context. The paper formalizes this as the empty active × external-context quadrant of a 2×2 design space.

Paper's Figure 2, verbatim (caption: "Design Space of Agent State. Context maps fill the active external-context quadrant."). The horizontal axis splits methods managing agent/task state from those managing external-context state; the vertical axis splits methods that deliberately maintain an artifact across interactions (Active) from those that merely carry/retrieve/summarize on demand (Passive). Every prior method lands in three of four cells; the active/external-context cell is empty and is exactly what PEEK targets.

Q2 — 方法 (the approach) #

A context map: a small, constant-sized (default budget B = 1024 tokens) artifact prepended to the agent's system prompt, holding 5 sections — 2 default (Context Roadmap, Context Understanding) + 3 optional (Domain Constants, Reusable Results, Parsing Schema). It begins nearly empty and is grown automatically through interaction by a three-module programmable cache policy:

• Distiller — reads the execution trajectory + current map, emits a diagnosis (orientation vs task-specific spend, where it stalled), per-item tags (helpful/harmful/neutral/stale), and cache candidates (only transferable contextual knowledge; task-specific rules discarded). Operates without ground truth, on always-available execution signals.
• Cartographer — translates the Distiller output into minimal structured edits (ADD / DELETE / REPLACE) against stable item IDs, deduplicating against existing entries.
• Evictor — enforces the hard budget B by evicting lowest-Distiller-score items first (ties → older first), in inverse section-value order (Parsing Schema → Reusable Results → Domain Constants; Roadmap & Understanding protected last).

核心技术壁垒: the separation of extraction (Distiller) from editing (Cartographer). Collapsing them into one LLM call ("Monolithic Update") leaks task-specific facts into the cache and produces noisy, duplicative, overwrite-prone updates — costing −7.7% on average (§5 ablation). This split, plus trajectory-only (no-ground-truth) diagnosis, is the hardest-to-replicate insight; naive single-call "summarize the trajectory into the map" variants the authors tried all underperformed or actively hurt (runtime full-swap: −14.86%).

Q3 — 结果 (what they found) #

• Quality: +6.3–34.0% on OOLONG, +6.0–14.0% solving rate / +7.8–12.1% rubric accuracy on CL-bench over strong baselines; vs SOTA prompt-learning ACE: +7.8–15.0% (OOLONG), +6.0% solve / +9.9% rubric (CL-bench).
• Efficiency: on iteration–quality and cost–quality Pareto frontiers across all benchmarks; 93–145 fewer iterations than ACE on OOLONG; 1.7–5.8× lower cost (OOLONG) / 1.4× (CL-bench).
• Generalization: gains hold across base LMs (GPT-5-mini → GPT-5.5, Qwen3-Coder-Next-FP8) and a different backbone agent (RLM → production-grade OpenAI Codex), without changing PEEK's algorithm or prompts.

3. 架构 / 方法图 #

PEEK treats the map as a CPU-cache-style fast store sitting next to the agent: a small piece of curated information supplied in addition to the (arbitrarily large) external context. Two coupled mechanisms: (1) the constant-sized context map in the system prompt; (2) a cache-management policy that, after each query completes, inspects the trajectory and updates the map for the next query.

Paper's Figure 3, verbatim (caption: "The PEEK System. ... PEEK caches orientation knowledge in a context map and updates it through a modular process consisting of a Distiller, a Cartographer, and an Evictor."). The red-boxed context map lives inside the agent's system prompt; the green-starred dashed box is the cache policy that runs after each query. Note the loop: the updated map flows back into the next query's prompt, so orientation knowledge compounds across queries on the same context.

The agent loop and map-evolution loop, as a state machine:

Map evolution can be frozen after as few as m = 1 query; m = n gives fully online adaptation. The map schema itself uses stable per-item IDs (e.g. [cr-00001]) so edits stay local and traceable.

Paper's Figure 4, verbatim (caption: "Example Context Map Generated by PEEK (Partially Shown). The map stores contextual knowledge in structured sections with stable item IDs, enabling consistent cache updates."). A Context Roadmap entry such as "[cr-00001] Single text block (∼38k chars) containing 388 records of the form..." is a navigational summary any future query reuses without re-discovering — the concrete payload of "orientation knowledge."

4. 作者证明 #

无形式化作者证明 — 仅实证. PEEK is an agent system; it has no convergence or success-rate guarantee. The only numbered equation is the OOLONG partial-credit scoring rule (a benchmark metric, not a PEEK theorem). What could have been bounded — e.g. a monotonicity guarantee of map value vs queries, or a regret bound on eviction — is left entirely empirical.

Notation #

Core procedure (Algorithm 1) #

For $i = 1 \dots n$: run $a_i, \text{traj} \leftarrow \text{AgentLoop}([\text{sys}+\text{map}, Q_i], C)$; if $i \le m$, then $(\text{diag}, \text{tags}, \text{cands}) \leftarrow \text{Distiller}(\text{traj}, \text{map})$, $\text{edits} \leftarrow \text{Cartographer}(\text{diag}, \text{tags}, \text{cands}; \text{map})$, $\text{map} \leftarrow \text{Apply}(\text{map}, \text{edits})$, $\text{map} \leftarrow \text{Evictor}(\text{map}, B)$.

The one numbered equation — OOLONG scoring #

$$\text{score}(\hat{y}) = 0.75^{\,|y - \hat{y}|}$$

Physical meaning: exponential-decay partial credit. An exact numeric match ($|y-\hat{y}|=0$) scores 1.0; each unit of absolute error multiplies the score by 0.75, so near-misses earn graded credit rather than a hard 0/1. Non-numerical answers use exact match. (Reconstructed: the PDF dropped the exponent superscript; restored per OOLONG [7] convention — see issues.)

6 empirical sanity checks (in lieu of formal proof) #

1. Static-map lower bound: even with eviction disabled and the map frozen at budget, PEEK still beats base RLM by large margins (Table 3, "No Eviction") — confirms the presence of orientation knowledge is the dominant effect, not the maintenance machinery.
2. Maintenance gain is real: the full policy adds +10.2% on average over the frozen-at-budget variant — eviction/updating contributes a measurable, separable increment.
3. Separation is necessary: Monolithic Update (Distiller+Cartographer merged) trails the full pipeline by −7.7% avg — the architectural split is load-bearing, not cosmetic.
4. Budget robustness: across B ∈ {512, 1024, 2048} (a 4× range) all budgets beat base RLM (avg +15.5% at 512, +20.3% at 2048); presence of a map matters more than its exact size.
5. Overhead accounting closes: PEEK maintenance is 6.2–17.9% of total cost (Distiller ≈ ⅔ of it), and because the map keeps iterations productive, total iteration counts stay at/below base RLM on 3 of 4 benchmarks — the overhead is partially self-offsetting (Tables 4–7).
6. Negative-control battery: 5 alternative map fills (raw prefix +0.73%, sub-goal retrieval +4.92%, retrieval-playbook +0.73%, runtime full-swap −14.86%, behavioral nudges +5.65%) all underperform PEEK, isolating curated orientation knowledge as the active ingredient (Appendix B.2).

5. 实验与数据 #

Built on the official RLM agent (externalizes context as REPL variables); GPT-5-mini as the main base LM. Benchmarks: OOLONG (long-context reasoning/aggregation; 3 hardest splits trec_coarse / agnews / yahoo) and CL-bench (context learning; up to 12 tasks/context, GPT-5.1 judge, solve rate + rubric accuracy). Baselines: RLM, RLM+Shared Chat, RLM+RAG, RLM+Compaction Agent (MemAgent), RLM+ACE (SOTA prompt learning).



Paper's Figure 1, verbatim (caption: "Performance Snapshot (GPT-5-mini as the Base LM). PEEK ... consistently achieves the highest scores across long-context tasks compared with strong baselines."). The headline one-glance claim: PEEK dominates every baseline on every benchmark shown.



Paper's Table 1, verbatim (caption: "Results of Different Methods Across Long-context Benchmarks ... PEEK outperforms all baselines across every metric."). Key numbers (absolute Δ vs base RLM in parentheses):

Method	TREC-coarse↑	AGNews↑	Yahoo↑	Solve↑	Rubric↑
RLM	30.3	46.5	23.0	14.0	54.5
RLM + Shared Chat	32.0 (+1.7)	49.6 (+3.1)	23.0 (0)	12.0 (−2.0)	51.3 (−3.2)
RLM + RAG	36.6 (+6.3)	63.1 (+16.6)	29.0 (+6.0)	14.0 (0)	55.6 (+1.1)
RLM + Compaction	42.0 (+11.7)	49.5 (+3.0)	30.0 (+7.0)	20.0 (+6.0)	54.6 (+0.1)
RLM + ACE	48.8 (+18.5)	61.6 (+15.1)	42.0 (+19.0)	20.0 (+6.0)	53.5 (−1.0)
RLM + PEEK	58.1 (+27.8)	69.4 (+22.9)	57.0 (+34.0)	26.0 (+12.0)	63.4 (+8.9)

The diagnostic story in the baseline rows: Shared Chat barely helps OOLONG and hurts CL-bench (raw accumulation = noise); RAG helps only well-structured contexts; Compaction lifts coarse success but not rubric accuracy; ACE improves solve rate (+6.0) but drops rubric accuracy (−1.0), the signature of task-specific playbook overfitting. PEEK improves both coarse and fine metrics — i.e. it strengthens context understanding rather than overfitting task types.



Paper's Figure 5, verbatim (caption: "Score vs. Total Iterations (Top) ... Score vs. Total Cost (Bottom) ... PEEK consistently lies on the Pareto frontier across all four benchmarks."). Shared Chat blows iterations up to 748 (OOLONG) / 301 (CL-bench) for ~zero gain; ACE needs 93–145 more iterations than PEEK on OOLONG while scoring 7.8–15.0% lower and costs up to 5.8× more. Cost decomposition (Tables 4–7) shows ACE's blow-up is driven by verbose execution (e.g. 12.45M output tokens, $29.42 on TREC-coarse = 5.8× PEEK).

Generalization (Table 2): with GPT-5.5, PEEK gains +43.1 / +29.3 / +41.0 on OOLONG splits over RLM and beats ACE; with Qwen3-Coder-Next-FP8 gains persist (+14.0 / +12.6 / +26.0); swapping RLM→Codex the gains are larger still (+44.0 / +35.6 / +52.0). RLM+PEEK with a small GPT-5-mini becomes competitive with out-of-the-box frontier models (GPT-5.5 High, Claude Opus 4.6 High) on the CL-bench leaderboard.

Rejected benchmarks (Appendix D): BrowseComp-Plus, FanOutQA, QuALITY were tried and discarded — the first two are manufactured unions of independent documents (per-task evidence nearly disjoint: only 1.1% of FanOutQA dev-question pairs share any evidence page), and QuALITY contexts are too short (~5.6k tokens) to need a cache. This motivates the paper's call for benchmarks that natively pose many hard questions over one persistent context.

6. 论证链 #

#	步骤 (paper-internal claim)	支撑
1	Repeated same-context workloads need orientation knowledge, which no existing method (shared chat, RAG, compaction, prompt learning) actively preserves.	§2.1 2×2 design space; the active/external-context quadrant is empty (Fig 2).
2	Orientation knowledge can be stored as a small, constant-size, prompt-resident context map — distinct from KV-cache (model-level) and from task playbooks.	§3.1 5-section schema; example map with stable item IDs (Fig 4).
3	The map must be grown automatically from interaction, not hand-crafted, and updated by separating extraction from editing under a budget.	§3.2 Algorithm 1: Distiller → Cartographer → Evictor loop.
4	This design beats all semantic-layer baselines on quality, iterations, and cost.	§4.3 Table 1 (best every metric) + Fig 5 (Pareto frontier).
5	The two key design choices (Distiller/Cartographer split; eviction policy) each contribute measurably, and the effect is budget-robust.	§4.5 Table 3: −7.7% if merged, +10.2% from full policy over frozen, all B ∈ {512,1024,2048} win.
6	The gains are not artifacts of one model/agent.	§4.4 Table 2: GPT-5.5, Qwen3-Coder, Codex all improve.
7	The active ingredient is specifically curated orientation knowledge, not just "more context."	Appendix B.2: 5 alternative fills (raw/retrieval/playbook/swap/nudge) all underperform or hurt.

7. 实现 cross-reference #

[实现未公开 in L1] — the L1 source cites a code handle (zhuohangu/peek) but no file:line-level implementation is captured in the ingested material, so concrete citations are unavailable here. The reproducible specification is Algorithm 1 plus the module contracts below.

• PEEK is built on the official RLM system [49] (arXiv:2512.24601), which stores contexts as REPL environment variables — this externalized-context interface is a hard prerequisite; the map is injected into the agent's system prompt, and the trajectory consumed by the Distiller is RLM's reasoning/action/observation log.

核心技术壁垒 (详述): The non-obvious, hardest-to-replicate piece is the Distiller/Cartographer separation operating purely on execution trajectories without ground truth. The Distiller must classify trajectory spend (orientation vs task-specific) and tag map items (helpful/harmful/neutral/stale) and extract only transferable candidates — explicitly discarding task-specific rules — while the Cartographer independently performs dedup + minimal ADD/DELETE/REPLACE editing against stable IDs. Merging these into one LLM call drops 7.7%; the authors' direct attempts to skip this structure (runtime full-swap of the map) cost −14.86%. Replicating the headline numbers therefore hinges on faithfully reproducing this two-stage contract and the trajectory-only diagnosis, not merely on "having a context map."

关键实现细节 (easy to miss):

1. Eviction order is tied to the section-value hierarchy, not just to scores: ties break by age, and section priority (Parsing Schema → Reusable Results → Domain Constants evicted first; Context Roadmap & Context Understanding protected last) is what keeps the navigational backbone stable as the budget bites.
2. The map starts as bare section headers (or fully blank) and is never pre-populated/hand-crafted — and update can be frozen after as little as m = 1 query, so the maintenance cost is a one-time-ish amortized expense rather than a per-query tax; m = n only when full online adaptation is wanted.