- The paper introduces Query-Conditioned Reuse (QCR), which converts a retrieved trajectory into workflow invariants, bindings to re-obtain, applicability conditions, and verification checks.
- QCR achieved 62.3% success across 2,391 target instances, outperforming full-trajectory injection by 10.7 percentage points while using 48.9% fewer online tokens and fewer API calls.
- The results show that reuse—not retrieval—is the main bottleneck when workflows contain long histories or changed bindings, with QCR reducing stale-binding errors from 46.9% to 10.9% under large shifts.
The post-retrieval reuse problem
This paper argues that for long-horizon agent trajectories, the dominant bottleneck in memory systems has shifted from retrieval to reuse. Retrieval-oriented memory evaluations (LongBench, LoCoMo, LongMemEval) end at access: whether a system can retain, rank, or answer questions about stored history. For short facts and compact episodes, retrieving the right item is nearly equivalent to using it. A long verified trajectory, however, encodes a reusable workflow alongside source-specific users, paths, dates, record identifiers, and failed branches. Finding such a trajectory does not tell the acting agent which parts transfer, which bindings have expired, or which checks must be repeated before acting. The paper formalizes this as a distinct evaluation problem—query-conditioned trajectory reuse—and proposes a deliberately minimal intervention to test whether target-conditioned support, rather than additional context, closes the gap.
The evaluation unit is a source–target pair: a verifier-approved historical rollout whose workflow survives in a later task while its bindings change. All compared conditions share a frozen bank of 623 verified trajectories pooled across WebArena, WorkArena, and AppWorld; a fixed embedding retriever (BGE-M3) returns the same top-5 candidates per target; a shared ranker selects one record before any condition runs. Conditions differ only in how that selected experience is delivered: No Memory, Full Trajectory (raw injection), Generic Summary (source-only compression at matched length budget), or QCR.
Query-conditioned reuse support
QCR writes a compact note with four fields from the selected trajectory, target query, and initial observation only—it cannot call tools privately or see hidden evaluator information:
- Workflow invariant: the action pattern that still applies.
- Bindings to re-obtain: dependencies the actor must ground in current evidence, without supplying old values as answers.
- Applicability conditions: preconditions under which reuse should be declined.
- Verification guardrail: the check that established completion in the source.
The authors are explicit that this schema is a diagnostic intervention, not a claim of a universally optimal memory format. Its purpose is legibility: given identical retrieved records, does target conditioning change verified outcomes?
End-to-end results
Across 2,391 target instances with three seed-matched runs each, using DeepSeek-V4-Pro throughout:
| Method |
Avg Success |
API calls |
Online tokens |
| No Memory |
— |
24.6 |
15.2k |
| Generic Summary |
47.9 |
20.8 |
8.1k |
| Full Trajectory |
51.6 |
21.9 |
18.4k |
| QCR |
62.3 |
16.7 |
9.4k |
QCR reaches 62.3% average success, 10.7 points above Full Trajectory, while consuming 48.9% fewer online tokens and making the fewest API calls among memory conditions. It leads on both Success and Milestone in all six environment-specific comparisons, with margins over Full Trajectory of 10.9 (WebArena), 10.8 (WorkArena), and 10.4 (AppWorld) points. Because candidate retrieval, selection, model, decoding, tool budget, and target state are held fixed, these differences are attributable to the representation and use of the same selected trajectory—not to more context. Notably, raw injection costs roughly twice the tokens of QCR yet performs worse, indicating the failure is not a context-window limitation alone but one of stale content displacing current-task evidence.
Selection quality is not the binding constraint
The retriever places the paired trajectory in the top five for 95.6% of targets and some reusable trajectory for 97.8%, though direct top-1 paired accuracy is only 78.9%. Reranking compact candidate summaries raises final reusable-memory accuracy to 94.8%, leaving end-task success within 1.8 points of an oracle reusable selector (64.1% vs. 62.3%). Directly using the retriever's first item yields 56.1%; random top-5 selection yields 44.8%. The implication is that after reranking, most remaining loss occurs downstream of selection—in how the delivered memory is applied.
Sensitivity analyses: length and binding shift
Two stratified analyses locate where direct injection fails. Partitioning by selected-memory length, Full Trajectory's utility falls from +18.4 points over No Memory for short histories (5–10 actions) to +2.9 for very long ones (>35 actions), retaining only 15.8% of its short-trajectory utility; QCR retains +13.2 points, or 60.3% of its short-history gain. Varying the number of rewritten source–target bindings produces a sharper contrast: with no rewrite, Full Trajectory gains +26.9 points, but under large rewrites (≥4 changed bindings, or entity plus initial state), its utility collapses to +2.2—retaining 8.2% of its no-shift value—while QCR retains +20.1 points (67.9%). At large shift, direct trajectories produce stale-binding errors on 46.9% of targets versus 10.9% for QCR, with correct rebinding rising from 31.7% to 77.8%. These are associations under the registered construction rather than causal estimates of length or shift alone, since strata also differ in no-memory difficulty.
Limitations and open questions
The authors state several boundaries plainly. The bank contains only successful source trajectories; naturally recurring histories, partial failures, multi-memory composition, and open-ended acquisition are unmeasured. Only one selected memory is delivered per target, so composition effects are out of scope. Token savings are reported beside verified completion rather than treated as a goal, because safety-sensitive targets may require additional checks—and the study measures completion but not irreversible side effects or policy violations introduced by reused procedures. The design isolates representation-level differences but does not ablate individual support-schema fields. Finally, the length and rewrite effects are observational within the benchmark construction, and the four-field schema's optimality is explicitly left open: learned graphs, hierarchies, or trained reuse policies might do better, provided they preserve the accounting boundary separating what was retrieved, selected, delivered, and verified.
Conclusion
The paper reframes agent-memory evaluation around a question that access-oriented benchmarks leave open: once a relevant long trajectory enters the pipeline, does it improve the current task? Holding retrieval fixed, target-bound support outperforms both raw injection and generic summarization by wide margins (+10.7 success points, −48.9% online tokens versus Full Trajectory), with the advantage concentrated exactly where direct reuse should fail—long traces and shifted bindings. The practical prescription is to preserve rich records in storage while delivering a compact, target-conditioned account of procedure, recoverable bindings, and remaining checks to the actor.
