When Agent Memory Needs to Compute: Evidence Access and Executable Aggregation

Zerui Yang; Quan Xue; Chaorui Zhang; Xueyan Niu; Xuanyu Zheng; Xiyuan Wang; Haolin Ruan; Guangcheng Song

cs.AIOct 14, 2026

When Agent Memory Needs to Compute: Evidence Access and Executable Aggregation

Authors: Zerui Yang, Quan Xue, Chaorui Zhang, Xueyan Niu, Xuanyu Zheng, Xiyuan Wang, Haolin Ruan, Guangcheng Song,

Organizations: Huawei Technologies Ltd.

Abstract

Questions about an agent's history often require aggregating events, which retrieval alone does not resolve. We combine source-preserving evidence access with executable aggregation. Trajectory Memory (TM) retains the original trajectory and constructs a source-addressable reading view at question time. TallyMem augments it with a reusable event ledger, model-generated event specifications and deterministic execution. With a commit-specific adaptation on 776 questions from 99 held-out MINTEval repositories, TallyMem raises Qwen3-32B exact match from 35.2% to 49.0%, a 13.8-point gain over TM; gains span 12.8-13.9 points across three readers. A controlled probe with event sets parsed independently from raw logs shows an 11.0-point gain, from 82.8% to 93.8%, without routing. On full AMA-Bench, the routed system yields a smaller 1.3-point gain, from 69.8% to 71.1%. These results support executable aggregation on tasks that require combining events, with benefits dependent on the task and event specification, the largest residual system-error category in our diagnostic analysis.

Figures & tables

Figure 1: Evidence access and event aggregation on an action-frequency question. Left: an illustrative compression example, not a measured output. Middle: Qwen3-32B’s actual long-context answer miscounts five of eight action types. Right: with TallyMem’s group-count query over all 150 steps, Qwen3-32B reports every count correctly. Red numbers are wrong.

Dimension	Binder	ChatDB	AMA-Agent	TM + TallyMem (ours)
Memory	Task input used by generated programs	SQL databases as symbolic memory	Structured trajectory memory with causal links	Original archive + reusable event ledger
Execution	Programs with language-model API calls	Model-generated SQL instructions	Trajectory-based code when retrieval is insufficient	Explicit event specification + fixed executor
Evidence use	Program execution over task input	Database operations and their results	Memory retrieval with code-based processing	Aggregates and step IDs alongside original evidence
Study focus	Program-based question answering	Symbolic memory for multi-hop reasoning	Long-horizon trajectory memory	Access, event selection and aggregation examined separately

Table 1: Design comparison with executable-query and memory systems ( Cheng et al., 2022 ; Hu et al., 2023 ; Zhao et al., 2026 ) . Entries summarize published designs and study objectives; bold highlights our archive–ledger organization and event-level analysis.

Panel of Figure 2 — Figure 2: Compiler-defined load diagnostic and log-defined aggregation probe. Left: TM (Qwen3-32B) on the 804 AMA-Bench questions with query evidence, by the steps their compiled queries match (406, 186, 108, 64 and 40 questions). Right: the probe, by the size of the event set parsed from the raw log (192, 157, 147 and 138 questions); the fixed counter groups steps by tool, and TM’s curve includes its counter on “how many times” questions.

Figure 3: Two constraints on trajectory answering. Qwen3-32B on 438 rule-selected diagnostic questions with a measured load, with computed evidence always attached. “History fits” means at most 24k raw-history tokens, not full visibility of every TM field. Cells show accuracy (%), sample size and paired sign-test

p

Figure 4: TM and TallyMem through a shared running example. (a) TM retrieves source text from archive

\mathcal{A}

; TallyMem adds computed evidence to the same reader. (b) The AMA ledger combines program-derived fields with model annotations before questions arrive. The outcome check verifies quote occurrence, not semantic correctness; MINTEval uses a programmatic ledger. (c) The model specifies scope, event predicate and operation; the executor selects and groups all 150 rows. The seven circles are the open group; its count and step IDs enter

D_{q}

AMA-Bench: accuracy (%), 2,496 questions
System	Qwen3-32B	gpt-oss-120b	Qwen3-8B
Long context	65.0	73.6	57.6
BM25	46.1	–	–
Dense RAG	36.5	–	–
Rolling summary	36.1	–	–
Mem0	24.3	–	–

Table 2: Main results. Each column compares systems within one setting; external memory systems run in the same deployment with the Qwen3-32B reader. MINTEval uses 99 held-out repositories; its long-context row and its gpt-oss-120b and Qwen3-8B entries were run after the pre-registered test. Paired tests and configurations appear in Appendices D and M .

Category	Errors	Other readers (%)
Specification	51	18.1
Ledger	21	38.1
Answering	21	39.3
Partial coverage	11	50.0
Reference or judge	42	17.3
Unclear	2	0.0

Table 3: The 148 errors TallyMem makes with computed evidence (Qwen3-32B, 630 diagnostic questions; Appendix N ). Last column: accuracy (%) of the other four readers given the same evidence.

Appendix figures & tables27 assets

Supplementary material from the paper’s appendix.

Appendix

Figure 5: TM’s archive and reading view (illustrative records). Deterministic indexes guide budgeted selection; the displayed spans retain their original order and provenance. Storing every step does not guarantee that every step or field reaches the reader. The keyword-triggered fixed counter is part of TM and remains present in the TallyMem comparison.

Figure 6: Comparison of Qwen3-32B systems on the 2,496 AMA-Bench questions. TallyMem denotes the routed main system; “no routing” is its ablation. External memory systems use the same deployment, with failed memory constructions counted as wrong. Deployment and adaptation details below define the comparison scope.

Qwen3-32B reader, official judge, local bf16 deployment
System	All	A	B	C	D	vs. TM: wins/losses ( $p$ )
No trajectory (question only)	21.9	21.6	28.5	20.2	15.5	+115/ $-$ 1311 ( $<$ 0.001)
Long context	65.0	65.2	72.0	63.4	57.2	+262/ $-$ 381 ( $<$ 0.001)
TM	69.8	72.2	72.8	73.1	55.3	–
BM25 (baseline suite)	46.1	47.9	54.5	42.3	36.2	+172/ $-$ 763 ( $<$ 0.001)
Dense RAG (baseline suite)	36.5	39.0	46.6	30.8	25.6	+165/ $-$ 997 ( $<$ 0.001)

Appendix

Table 4: Full AMA-Bench, 2,496 questions; accuracy (%). Categories: A recall, B causal inference, C state updating, D state abstraction. † Refined compiler: two compile rules added after inspecting the principal compiler’s errors. ‡ Rule routing: post hoc restriction to pre-defined aggregation families. § With the router of Appendix J ; “no routing” rows attach every nonempty computed evidence. External baselines: same deployment and reader; failed memory constructions count as wrong.

Method	Accuracy (%)
Externally reported results
AMA-agent	56.91
Hipporag2	44.05
HybridFocus	62.46
Long context	51.35
Memorag	45.70

Appendix

Table 5: AMA-Bench method comparison with Qwen3-32B. External scores are reported under their respective settings; this study’s scores come from Table 2 .

Figure 7: Five-reader diagnostic comparison, without routing: (a) all 630 common rule-selected questions; (b) the 37 questions whose compiled queries match more than 100 steps. Each method’s frozen contexts and evidence are shared across readers, with a common judge. The high-load subset is small; paired tests and full load strata appear in Tables 7 and 10 .

Method (Qwen3-32B reader)	correct	vs. TM: +/ $-$ ( $p$ )
No trajectory (question only)	95/630	+44/ $-$ 339 ( $<$ 0.001)
Long context	350/630	+61/ $-$ 101 (0.002)
TM	390/630	–
TM + enumerate-then-count prompt	386/630	+43/ $-$ 47 (0.75)
TallyMem-lite (zero-generation ledger)	407/630	+32/ $-$ 15 (0.02)
TallyMem	416/630	+55/ $-$ 29 (0.006)

Appendix

Table 6: Correct answers on the 630 rule-selected questions. † Refined compiler adds two compile rules chosen after inspecting the principal compiler’s errors (Section 8 ).

Answer model	$n$	Long context	TM	TallyMem-lite	TallyMem	TallyMem vs. TM
Qwen3-32B (thinking)	630	55.6	61.9	64.6	66.0	+55/ $-$ 29 (0.006)
Qwen3-235B-A22B-2507	630	52.4	59.5	64.3	66.8	+78/ $-$ 32 ( $<$ 0.001)
gpt-oss-120b (reasoning)	630	61.1	68.9	70.2	73.0	+54/ $-$ 28 (0.005)
Qwen3.6-27B (thinking) §	630	64.6	68.4	72.7	72.4	+51/ $-$ 26 (0.006)
Qwen3-8B (thinking) §	630	46.3	54.9	60.3	61.1	+61/ $-$ 22 ( $<$ 0.001)

Appendix

Table 7: Five answer models on the same frozen contexts and evidence (accuracy %, paired sign tests; the judge model is Qwen3-32B throughout). § Answered on our local server (bf16); the others on DeepInfra.

Family	TM $\to$ TallyMem ( $p$ )
Count / frequency (F1)	152 $\to$ 176 / 246 ( $<$ 0.001)
First / last change (F2)	91 $\to$ 92 / 152 (1.00)
State tracing (F3)	113 $\to$ 115 / 186 (0.83)
Action enumeration (F4)	52 $\to$ 72 / 91 ( $<$ 0.001)

Appendix

Table 8: TM

\to

TallyMem correct / questions by rule-defined family on the 630 rule-selected questions (

p

from a paired sign test; one question may be in several families).

Answer model	trajectory fits	does not fit
Qwen3-32B (thinking)	66.0 / 69.6 / 75.1 (0.01)	45.5 / 54.5 / 57.3 (0.21)
Qwen3-235B-A22B-2507	62.5 / 68.0 / 73.5 (0.02)	42.7 / 51.4 / 60.4 ( $<$ 0.001)
gpt-oss-120b (reasoning)	75.4 / 80.9 / 82.2 (0.64)	47.4 / 57.3 / 64.2 ( $<$ 0.001)
Qwen3.6-27B (thinking) §	79.6 / 77.3 / 79.9 (0.24)	50.2 / 59.8 / 65.1 (0.01)
Qwen3-8B (thinking) §	56.6 / 58.6 / 65.4 (0.001)	36.4 / 51.4 / 57.0 (0.010)

Appendix

Table 9: Long context / TM / TallyMem accuracy (%) by nominal raw-history fit (630 questions;

p

: TallyMem vs. TM). When it does not fit, long context collapses (retrieval bottleneck); when it fits, computation adds significantly for three of the five readers. Fit does not guarantee full TM field visibility (Appendix F ). § Local server.

Answer model	load 1–15	load 16–100	load $>$ 100
Qwen3-32B (thinking)	63.2 / 72.9 / 71.2	33.3 / 44.1 / 57.8	2.7 / 2.7 / 48.6
Qwen3-235B-A22B-2507	58.9 / 68.6 / 74.2	33.3 / 48.0 / 57.8	2.7 / 0.0 / 51.4
gpt-oss-120b (reasoning)	61.5 / 75.3 / 76.9	57.8 / 64.7 / 66.7	18.9 / 10.8 / 62.2
Qwen3.6-27B (thinking) §	67.6 / 75.9 / 77.6	60.8 / 57.8 / 61.8	27.0 / 18.9 / 62.2
Qwen3-8B (thinking) §	53.2 / 69.6 / 72.2	24.5 / 25.5 / 40.2	2.7 / 0.0 / 43.2

Appendix

Table 10: Accuracy (%) as long context / TM / TallyMem by aggregation load. Of the 630 diagnostic questions, 438 have defined load; counts are 299 / 102 / 37 for the three strata. § Local server.

Answer model	all	+enum. vs. TM	load $>$ 100
Qwen3-32B (thinking)	61.9 / 61.3 / 66.0 / 65.4	+43/ $-$ 47 (0.75)	2.7 / 2.7 / 48.6 / 56.8
Qwen3-235B-A22B-2507 ∗	59.6 / 61.2 / 66.9 / 65.3	+77/ $-$ 67 (0.45)	0.0 / 24.3 / 51.4 / 62.2
gpt-oss-120b (reasoning)	68.9 / 74.0 / 73.0 / 76.3	+61/ $-$ 29 ( $<$ 0.001)	10.8 / 18.9 / 62.2 / 67.6

Appendix

Table 11: Enumeration controls on 630 diagnostic questions (37 with load above 100). Accuracy columns (%): TM / TM with enumeration / TallyMem / TallyMem with enumeration. The comparison column gives wins/losses and sign-test

p

for TM with enumeration versus TM. ∗ 629 of 630: one question failed four times with a transport error.

	Question	Operation	$n$	$\overline{\|S^{\star}\|}$	TallyMem	TM	Counter	Long context	Correct plan	Code
E1	count go to (three bounds; “how many times”)	count	90	36	100.0	100.0	100.0	78.9	100.0	95.6
E2	as E1 at the full bound (“how often”)	count	30	62	100.0	46.7	100.0	43.3	100.0	36.7
E3	count open	count	30	5	100.0	96.7	100.0	73.3	100.0	100.0
E4	opens and closes of the most-used receptacle	count	25	4	100.0	100.0	100.0	88.0	100.0	100.0
E5	distinct objects taken	distinct	30	2	100.0	100.0	100.0	86.7	100.0	93.3
E6	last step with a take	last	30	2	100.0	90.0	100.0	93.3	100.0	100.0

Appendix

Table 12: Probe templates and accuracy (%, official judge; Qwen3-32B). E: embodied, S: software.

n

: questions;

\overline{|S^{\star}|}

: mean number of logged events in the answer’s event set. Counter: the fixed group-by-tool plan run by TallyMem’s executor. Over all 645 questions: TallyMem 93.8, TM 82.8 (TallyMem +79/

-

p

<

0.001), counter 89.9 (+37/

-

12,

p

<

0.001).

	Bound and wording	$\overline{\|S^{\star}\|}$	TallyMem	TM	Counter	Long
E1	$b_{1}$ , “how many times”	16	100.0	100.0	100.0	100.0
E1	$b_{2}$ , “how many times”	31	100.0	100.0	100.0	80.0
E1	$b_{3}$ , “how many times”	62	100.0	100.0	100.0	56.7
E2	$b_{3}$ , “how often”	62	100.0	46.7	100.0	43.3
S1	$b_{1}$ , “how many times”	13	100.0	100.0	97.2	5.6
S1	$b_{2}$ , “how many times”	26	100.0	97.2	97.2	2.8

Appendix

Table 13: Same count, three bounds and two wordings (accuracy, %; official judge).

Reader	TallyMem	TM	Counter	Long context	Correct plan
Qwen3-32B	93.8	82.8	89.9	49.3	94.9
Qwen3-8B	83.1	70.1	81.9	54.3	84.3

Appendix

Table 14: Probe accuracy (%, official judge) by reader; all arms use the same evidence.

	$n$	Exact	P	R	F1	Counter F1	Expressible
E1	90	90	100.0	100.0	100.0	100.0	90/90
E2	30	30	100.0	100.0	100.0	100.0	30/30
E3	25	25	100.0	100.0	100.0	100.0	30/30
E4	25	21	85.3	88.0	86.0	50.3	24/25
E5	30	30	100.0	100.0	100.0	100.0	30/30
E6	30	30	100.0	100.0	100.0	100.0	30/30

Appendix

Table 15: Event sets of TallyMem’s evidence against

S^{\star}

(questions with a nonempty

S^{\star}

; P, R and F1 in %).

Reader	All	Development half	Held-out half
Qwen3-32B	$+$ 1.3 [ $+$ 0.7, $+$ 2.0]	$+$ 1.4 [ $+$ 0.6, $+$ 2.2]	$+$ 1.3 [ $+$ 0.4, $+$ 2.2]
gpt-oss-120b	$+$ 0.8 [ $+$ 0.2, $+$ 1.4]	$+$ 0.6 [ $-$ 0.2, $+$ 1.4]	$+$ 1.1 [ $+$ 0.3, $+$ 2.0]
Qwen3.6-27B	$+$ 0.7 [ $+$ 0.1, $+$ 1.4]	$+$ 1.4 [ $+$ 0.5, $+$ 2.3]	$+$ 0.1 [ $-$ 0.7, $+$ 1.0]
Qwen3-8B	$+$ 1.5 [ $+$ 0.9, $+$ 2.1]	$+$ 1.8 [ $+$ 1.0, $+$ 2.7]	$+$ 1.2 [ $+$ 0.4, $+$ 2.1]
Qwen3-32B (630)	$+$ 4.1 [ $+$ 1.5, $+$ 6.7]
Qwen3-235B (630)	$+$ 7.3 [ $+$ 4.0, $+$ 10.6]

Appendix

Table 16: Gain of TallyMem over TM in accuracy points, with 95% intervals from a bootstrap over trajectories. Upper block: the full benchmark (2,496 questions), routed TallyMem. Lower block: the 630 diagnostic questions, TallyMem without routing. Halves follow the trajectory split of Appendix A ; method development used the first.

Reader	none	$>$ 5	$>$ 10	$>$ 15	$>$ 20	$>$ 40	$>$ 100	TM
Qwen3-32B	70.4	70.8	71.0	71.1	71.0	71.0	70.6	69.8
gpt-oss-120b	79.2	79.2	79.3	79.2	79.2	78.9	79.1	78.4
Qwen3.6-27B	76.8	76.7	76.7	76.6	76.6	76.7	76.5	75.9
Qwen3-8B	62.4	61.9	62.2	62.3	62.1	61.9	61.4	60.7

Appendix

Table 17: Full-benchmark accuracy (%) when computed evidence is attached only above a load threshold (“none”: always; TM: never).

Reader	Questions	TM	no routing	TallyMem
Qwen3-32B (server)	all 2,496	69.8	70.4 (+79/ $-$ 63)	71.1 (+47/ $-$ 14)
	rule-selected 670	64.9	68.8 (+52/ $-$ 26)	69.7 (+39/ $-$ 7)
	other 1,826	71.6	71.0 (+27/ $-$ 37)	71.6 (+8/ $-$ 7)
gpt-oss-120b (DeepInfra, pre-registered)	all 2,496	78.4	79.2 (+75/ $-$ 54)	79.2 (+40/ $-$ 19)
	rule-selected 670	70.2	74.0 (+54/ $-$ 28)	73.3 (+33/ $-$ 12)
	other 1,826	81.4	81.1 (+21/ $-$ 26)	81.4 (+7/ $-$ 7)

Appendix

Table 18: Accuracy (%) and wins/losses against TM with and without the router on full AMA-Bench.

earlier development controls, 217 questions
Variant	correct	vs. TallyMem	vs. TM
TallyMem	416/630	–	+55/ $-$ 29 (0.006)
no quote recovery	415/630	+2/ $-$ 3 (1.00)	+55/ $-$ 30 (0.009)
no relaxed retry	415/630	+2/ $-$ 3 (1.00)	+52/ $-$ 27 (0.007)
zero-generation ledger (TallyMem-lite)	407/630	+28/ $-$ 37 (0.32)	+32/ $-$ 15 (0.02)
plan self-consistency ( $k{=}5$ )	414/630	+28/ $-$ 30 (0.90)	+50/ $-$ 26 (0.008)

Appendix

Table 19: Ablations (Qwen3-32B). Upper block: 630 rule-selected questions. Lower block: earlier development variants compared with their own TM context.

	All	Load $>$ 100
Questions	630	37
TM	61.9	2.7
TallyMem	66.0	48.6
Free-form code (ledger + log)	62.1 (+72/ $-$ 47; 0.03)	32.4 (+9/ $-$ 3; 0.15)
Free-form code (ledger only)	61.1 (+77/ $-$ 46; 0.007)	40.5 (+9/ $-$ 6; 0.61)
Free-form code, thinking (ledger + log)	60.2 (+82/ $-$ 45; 0.001)	45.9 (+9/ $-$ 8; 1.00)

Appendix

Table 20: Free-form code control (Qwen3-32B, accuracy %). Columns: the 630 rule-selected questions and those with load above 100. In parentheses: questions that TallyMem answers correctly and the code arm does not / the reverse, and the two-sided sign-test

p

Figure 8: MINTEval value-history questions by commits back to the requested value: 288 questions with an annotated lookback of at least one commit (bin sizes shown). TallyMem exceeds TM in every bin; the two farthest bins also show larger advantages over long-context reading. The bins describe different questions, not a controlled intervention on history length.

System	All	Hist.	Order	Count	Simple	Multi-hop	vs. TM
Long context	39.2	45.8	19.0	52.5	47.1	33.6	+123/ $-$ 92 (0.041)
TM	35.2	41.0	17.6	31.1	47.8	31.3	–
TallyMem ¶	49.0	56.6	43.1	47.5	56.6	31.3	+124/ $-$ 17 ( $<$ 0.001)
TallyMem, no routing	49.0	56.6	43.1	47.5	56.6	31.3	+125/ $-$ 18 ( $<$ 0.001)
TallyMem, AMA load routing §	35.7	–	–	–	–	–	+5/ $-$ 1 (0.22)

Appendix

Table 21: MINTEval GitHub split, 99 held-out repositories (776 questions), exact match (%), Qwen3-32B reader, frozen system evaluated once. Long context: the whole history, head and tail truncated to the budget of the AMA-Bench long-context arm, run after the pre-registered test as a reference row. Sign tests are paired with TM. ¶ With the coverage-aware router of Appendix J . § The load-only router.

Questions	Errors	Specification	Ledger	Answering	Partial	Reference/judge	Unclear
Load 1–15	86	24	13	8	9	30	2
Load 16–100	43	17	8	10	2	6	0
Load $>$ 100	19	10	0	3	0	6	0
Count / frequency (F1)	52	21	14	10	5	2	0
First / last change (F2)	29	10	1	2	3	12	1
State tracing (F3)	55	7	7	8	4	28	1

Appendix

Table 22: Errors with computed evidence by aggregation load and question family (Qwen3-32B, 630 diagnostic questions). A question can belong to several families. Executor and truncation errors: none.

Figure 9: A conceptual example of Equation 12 . The executed set includes an extra event and misses an intended one. Their effects cancel in the scalar count, although the selected sets differ.

S^{\star}

is an analysis reference, not an input to inference. Rendering and final answer generation can introduce additional errors.

Domain	$n$	Long ctx.	TM	TallyMem-lite	TallyMem	TallyMem vs. TM
Embodied	239	129	141	161	165	+33/ $-$ 9 ( $<$ 0.001)
Game	17	12	10	10	8	+0/ $-$ 2 (0.50)
Open-world	59	30	45	45	43	+0/ $-$ 2 (0.50)
Software	67	27	21	21	20	+3/ $-$ 4 (1.00)
Text-to-SQL	153	97	99	96	107	+16/ $-$ 8 (0.15)
Web	95	55	74	74	73	+3/ $-$ 4 (1.00)

Appendix

Table 23: Correct answers by domain on the 630 rule-selected questions (Qwen3-32B). The gain is concentrated in the embodied domain, whose trajectories are long and whose questions aggregate the most steps. Long context is better than TM on software engineering and games (small samples), where TM’s selection misses context.

Figure 11: Reading and execution on the worked example. Left: TM’s reading view and the full-ledger computation path. Right: saved TM counts and the executable result against the reference.

Figure 12: Saved answers across reader configurations on the same question. Red entries differ from the reference; all six answer rows come from diagnostic runs.

Agent Memory

Agent memory lets AI systems retain, update, and use facts, experiences, and skills across sessions and long-horizon tasks.

See all 190 papers

From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents
Feb 20, 2026Qiming Zhu, Shunian Chen, Rui Yu +2Agent Memory Agent Memory Management
School of Data Science, The Chinese University of Hong Kong, Shenzhen.
Storage Is Not Memory: A Retrieval-Centered Architecture for Agent Recall
May 6, 2026Joshua Adler, Guy ZehaviAgent Memory LLM Agent Memory
Sauron Labs
When Does Execution Provenance Help Agent Memory Retrieval?
Sep 22, 2026Yiqi Wang, Jinqian Ju, Jiaqi Zhang +4Agent Memory Data Provenance
University of Southern Queensland, Australia · Southern University of Science and Technology, China · Jiangsu University, China +2

Feb 20, 2026J/K move · Enter open · S save

From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents

Qiming Zhu, Shunian Chen, Rui Yu, Zhehao Wu+1

School of Data Science, The Chinese University of Hong Kong, Shenzhen.

Agent Memory Agent Memory Management Long-Term Conversational Memory Hierarchical Memory Data Provenance

Open paper AskPDF arXiv

Long-horizon agents often compress interaction histories into write-time summaries. This creates a fundamental write-before-query barrier: compression decisions are made before the system knows what a future query will hinge on. As a result, summaries can cause unverifiable omissions -- decisive constraints (e.g., allergies) may be dropped, leaving the agent unable to justify an answer with traceable evidence. Retaining raw logs restores an authoritative source of truth, but grounding on raw logs by default is expensive: many queries are answerable from summaries, yet raw grounding still requires processing far longer contexts, inflating token consumption and latency. We propose TierMem, a provenance-linked framework that casts retrieval as an inference-time evidence allocation problem. TierMem uses a two-tier memory hierarchy to answer with the cheapest sufficient evidence: it queries a fast summary index by default, and a runtime sufficiency router Escalates to an immutable raw-log store only when summary evidence is insufficient. TierMem then writes back verified findings as new summary units linked to their raw sources. On LoCoMo, TierMem achieves 0.851 accuracy (vs.0.873 raw-only) while reducing input tokens by 54.1% and latency by 60.7%.

Abstract

Agent Memory

Explore similar work

From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents

Storage Is Not Memory: A Retrieval-Centered Architecture for Agent Recall

When Does Execution Provenance Help Agent Memory Retrieval?