TrawMem: Reframing Agent Memory as Task-Oriented Role-Adaptive Workspaces

Mingyu Zhang; Zixu Li; Zhiheng Fu; Zhiwei Chen; Jinhe Bi; Yupeng Hu

cs.CLOct 27, 2026

TrawMem: Reframing Agent Memory as Task-Oriented Role-Adaptive Workspaces

Authors: Mingyu Zhang, Zixu Li, Zhiheng Fu, Zhiwei Chen, Jinhe Bi, Yupeng Hu

Organizations: Shandong University · National University of Singapore

Abstract

Large language model (LLM) agents rely on memory systems to leverage long-term interactions, yet existing systems typically retrieve memories based on their relevance to the current query and use them as contextual evidence. However, relevance alone does not characterize how a memory contributes to task solving: the same memory may serve different roles across tasks, such as directly supporting the answer or linking to complementary memories with weaker semantic relevance but necessary information. We therefore reframe agent memory systems as Task-Oriented Role-Adaptive Workspaces, where memories are selected and organized by their task-oriented roles and relations. Based on this view, we propose TrawMem, which organizes interaction histories into local threads and constructs task-oriented workspaces by assigning roles and jointly selecting complementary memories. Experiments on LoCoMo and MemGallery with four open- and closed-source backbones show consistent improvements over representative memory systems, with macro-F1 gains of 2.23-3.14 points. On LoCoMo, TrawMem improves the LLM-Judge score over SimpleMem by 4.07 and 4.31 percentage points on Qwen3.5-9B and DeepSeek-V4-Flash, respectively, while requiring approximately 12.8% and 5.1% fewer context tokens, respectively.

Figures & tables

Figure 1: Our observation and reframing of agent memory usage. (a) Memory Unit A directly supports Task A, while for Task B it serves as a bridge to memory unit B that may have weaker semantic relevance. (b) Existing memory systems typically retrieve relevant memories as context, whereas TrawMem constructs a task-oriented workspace by jointly selecting memory units and organizing their relations according to their roles.

Figure 2: Overall architecture of TrawMem . Stage 1 organizes the interaction history into threads and constructs a thread graph. Stage 2 locates the thread neighborhood relevant to the current task, selects and organizes memory units according to the task requirements, and constructs a task-oriented workspace.

Figure 3: TrawMem ’s memory organization. Raw interactions are grouped into local threads, each consisting of a thread head and an ordered sequence of memory units. Related thread heads form a thread graph; solid arrows denote within-thread order and thread-level relations, while dashed arrows denote induced unit-level connectivity.

Backbone	Method	F1	B-1	$J$
Qwen3.5 9B	Naive RAG	31.49	21.58	47.92
	A-MEM	34.18	22.83	45.34
	Mem0	35.49	28.43	48.54
	LightMem	35.14	29.94	48.03
	SimpleMem	35.32	28.44	48.08
	Ours	37.17	32.03	49.06

Table 2: Macro-averaged MemGallery results for four answer backbones. F1, B-1 (BLEU-1), and

J

(LLM-Judge) are reported, where higher values are better. Darker red shading indicates higher scores. Bold and underlined values denote the best and second-best results, respectively, within each backbone and metric column.

Figure 4: Ablation results on LoCoMo. The metric is the LLM-Judge score

J

, and the y-axis shows the change relative to Full,

\Delta J=J_{\mathrm{variant}}-J_{\mathrm{Full}}

. Thus,

\Delta J<0

indicates a performance decrease, and a larger

|\Delta J|

indicates more severe degradation.

Figure 5: Ablation results on MemGallery. The LLM-Judge score $J$ is displayed above each cell, and $\Delta J=J_{\mathrm{variant}}-J_{\mathrm{Full}}$ . Color intensity represents the magnitude of the performance decrease, with darker colors indicating larger decreases.

Figure 6: Parameter sensitivity analysis on LoCoMo. The y-axis represents the LLM-Judge score

J

, and each column corresponds to one backbone model for answer generation. The top row shows the joint effects of the task-oriented cost weights

\lambda_{m}

and

\lambda_{r}

over the predefined parameter grid. The bottom row shows the effect of the evidence budget

B_{q}

J

Figure 7: Changes in the query-relevant roles of the same memory across paired queries. The three panels show Anchor, Bridge, and Context, respectively. Solid circular markers denote

q_{A}

, and dashed square markers denote

q_{B}

. Light-colored bars represent the pairwise

\Delta\rho=\rho_{q_{B}}-\rho_{q_{A}}

, corresponding to the right y-axis. The x-axis is ordered by the Anchor weight for

q_{A}

Figure 8: Workspace compression on LoCoMo. (a) Mean numbers of candidate memory units and memory units ultimately selected into the workspace for each query category. Error bars indicate 95% confidence intervals obtained from 2,000 bootstrap resamples, with root as the resampling unit. (b) Distribution of the memory unit reduction ratio for each question,

100c_{q}

. Boxes indicate the 25th to 75th percentiles, black lines indicate medians, orange dots indicate means, whiskers extend to the most distant observations within 1.5 times the interquartile range, and hollow circles indicate outliers beyond the whisker range.

Figure 9: Information coverage and redundancy under different memory budgets. (a) Number of distinct relevant facts retained per query, where higher is better; (b) number of additional occurrences of the same fact across multiple selected memory units, where lower is better. Both metrics are means of counts computed per query, and the horizontal axis shows the number of selected memory units.

Figure 10: Memory context length and per-query retrieval time in an actual run. (a) Empirical cumulative proportions of the four query categories at different memory context token thresholds. Connecting lines are provided only to aid visual reading and do not represent fitted curves. Context length is measured using the Qwen3.8-27B tokenizer and excludes the question answering instructions and generated answers. (b) Box plots of retrieval time for the four query categories, in seconds, with a logarithmic y-axis. Boxes represent the 25th to 75th percentiles, black lines indicate medians, orange points indicate means, whisker endpoints indicate the most distant observations within 1.5 times the interquartile range, and hollow points indicate outliers beyond the whiskers.

Method	Construction time $\downarrow$	Retrieval time $\downarrow$	Total time $\downarrow$	Answer-context tokens $\downarrow$ (tok/q)	LLM-Judge $J$ (%) $\uparrow$
Qwen3.5-9B
A-MEM	5222.3	832.6	6054.9	$\sim\!$ 1372	57.22
Mem0	1076.8	567.2	1644.0	$\sim\!$ 3956	58.67
LightMem	110.3	601.5	711.8	$\sim\!$ 1012	59.96
SimpleMem	103.9	501.4	605.3	$\sim\!$ 2351	59.19
Ours(H=3)	96.1	603.8	699.9	$\sim\!$ 2050	63.26

Table 3: Efficiency and answer quality of different memory systems on LoCoMo. Construction time, Retrieval time, and Total time are all reported in s/root. Retrieval time denotes the cumulative time spent during the query stage, while Total time is the sum of the preceding two quantities. Answer-context tokens denotes the number of context tokens actually fed into the answering model for each question (tok/q), and

J

denotes the average LLM-Judge score across the four question categories (%). Here,

H

denotes the maximum expansion depth of the thread neighborhood. Boldface and underlining indicate the best and second-best results, respectively, according to the optimization direction specified in each column heading.

Panel of Figure 14 — Figure 14: Supplementary case study of relationship support questions.

Panel of Figure 15 — Figure 15: Supplementary case study of the repeated-event problem.

Panel of Figure 16 — Figure 16: Supplementary case study of Travel Relation Questions across Sessions.

Panel of Figure 17 — Figure 17: Supplementary case study of Location and Skill Clues across Sessions.

Panel of Figure 18 — Figure 18: Date-related failure case

LLM Agent Memory

Large language model agent memory lets agents retain, organize, retrieve, and update information across interactions and long-running tasks.

See all 373 papers

FlexA-Mem: Budget-Adaptive Agentic Memory for LLM Agents
Oct 23, 2026Wujiang Xu, Jiaojiao Han, Xi Zhu +5Memory Management for LLM Agents Long-Term Conversational Memory
Rutgers University · Independent Researcher · Stanford University +2
Memory as a Controlled Process: Learned Adaptive Memory Management for LLM Agents
Jul 15, 2026Eric Hanchen Jiang, Zhi Zhang, Yuchen Wu +11Persistent Memory for Language Models Memory Management for LLM Agents
University of California Los Angeles · University of Washington · Northwestern University
Weighted Memory Tree: Remembering What Matters for Long-Horizon LLM Agents
Aug 21, 2026Quang Dao, Purvi Kathalkar, Kenneth EatonLLM Agent Memory Memory Management for LLM Agents
Rose-Hulman Institute of Technology · Georgia Institute of Technology · Georgia Tech Research Institute

Oct 23, 2026J/K move · Enter open · S save

FlexA-Mem: Budget-Adaptive Agentic Memory for LLM Agents

Wujiang Xu, Jiaojiao Han, Xi Zhu, Qizheng Zhang+4

Rutgers University · Independent Researcher · Stanford University+2

Memory Management for LLM Agents Long-Term Conversational Memory Long-Horizon LLM Agents

Open paper AskPDF arXiv

Large language model (LLM) agents work in scenarios with very different memory needs. A question about past conversations needs the exact facts it names, while a multi-step task needs a trace of the steps already taken together with details that the next step cannot name. Existing memories are each designed and tested for one kind of scenario. Retrieval memories such as A-Mem miss steps that the current query does not express, summaries drop exact strings, and pairing the two fixes the split of the budget in advance. We propose FlexA-Mem, a general memory that writes each unit of history once into an immutable store and renders a fresh memory for every call. The rendered memory is a compact timeline of records plus detail that a fixed rule fits into the remaining room without an LLM call. The detail is either relevant units as raw text or excerpts or the verbatim pieces that best match the query. With one store, FlexA-Mem serves both kinds of scenario. On AppWorld challenge tasks at 4k, it outperforms the second-best method by 11.5%, and on 147 unused tasks with predictions fixed in advance it outperforms A-Mem with a summary by 12.2%. On LongMemEval and LoCoMo, it matches a dedicated keyword retriever that writes no memory, while memories built on text written by an LLM fall far behind at tight budgets. Ablations show that the timeline carries AppWorld completion, whereas recovery mainly saves steps there and decides accuracy on exact facts. Code is available at https://github.com/WujiangXu/Flex-Amem

Abstract

LLM Agent Memory

Explore similar work

FlexA-Mem: Budget-Adaptive Agentic Memory for LLM Agents

Memory as a Controlled Process: Learned Adaptive Memory Management for LLM Agents

Weighted Memory Tree: Remembering What Matters for Long-Horizon LLM Agents