I’ve been working on TiDB Filesystem recently, and also thinking about how to build Agent Memory on top of a filesystem.

What I’ve found in practice: Storing memory is easy. The hard part is making the agent recall the right thing at the right time. Once corner cases pile up, the agent quickly becomes “memory-confused” — much like a programmer revisiting code three months after writing it.

Recently I read a paper: Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability,https://arxiv.org/pdf/2607.26637

It has a very interesting conclusion: Well-organized files can cut retrieval cost by nearly half, but they don’t automatically improve answer quality.

So: Having a filesystem doesn’t mean having a memory system. What’s truly hard is: writing, revision, forgetting, permissions, auditing, and rollback.

Filesystem is the interface. Memory is the lifecycle.

This is exactly what TiDB Filesystem is doing: Making stored files automatically carry database semantics — searchable, versioned, auditable, and rollback-capable.

It’s not just adding a directory; it’s about making files genuinely become memory that the agent can rely on over the long term.

Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability

Source: https://arxiv.org/html/2607.26637 Sizhe Zhou*,1,†, Sheldon Yu*,2, Hui Wei*,3, Junda Wu4, Siru Ouyang1, Yizhu Jiao1, Shijia Pan3, Julian McAuley2, Yu Zhang5, Tong Yu4, Jiawei Han1 1University of Illinois Urbana-Champaign2University of California, San Diego 3University of California, Merced4Adobe Research5Texas A&M University {sizhez,siruo2,yizhuj2,hanj}@illinois.edu{ziy040,jmcauley}@ucsd.edu {huiwei2,span24}@ucmerced.edu{jundaw,tyu}@[email protected]

Abstract

Deployed LLM agents increasingly keep their long-term memory as a filesystem: a directory tree of markdown files that the agent itself reads, writes, and reorganizes through generic file tools. Yet research has largely passed over this medium: prior systems design bespoke memory representations and study retrieval over them, leaving the default’s two working assumptions untested: that an agent can keep a growing store organized as memories accumulate, conflict, and go stale, and that this organization pays. We present the first systematic exploration of filesystem-based memory for LLM agents. We formalize the setting as three roles around one memory filesystem: a management agent integrates and organizes incoming content, a search agent answers queries with cited sources, and an execution agent supplies task trajectories that are distilled into skills, unifying declarative memory and skills in a single store. Across long-conversation benchmarks and embodied tasks, we vary memory shape (agent-organized hierarchy, verbatim dump, chunk retrieval), stream scale, tool harness (sandboxed shell, memory-tool-style functions, varied search tooling), and the strengths of the management and search agents, tracking answer quality, cost, and store health as memory grows. What organization reliably buys is search economy: organized stores roughly halve retrieval cost where material is large. Today’s agents, however, fall short of the default’s promise: in our growth study, organization erodes for all but the strongest management agent, and no agent we measure converts organization itself into better answers. And the model is not the only lever over a store’s shape: changing the tool set alone reshapes the store as strongly as swapping the model. The study turns the filesystem default from an assumption into a design space for agent memory.

{NoHyper}††footnotetext:*Equal contribution.†Corresponding author:[email protected].

1Introduction

Large language model (LLM) agents increasingly work over horizons no single context window can span, maintaining codebases across sessions and assisting the same user for months. The field’s ambitions reach further still, toward agents that learn continually from their own experience and, ultimately, intelligence of a human kind. Both demand a memory that works less like a transcript and more like a brain: persisting across episodes and evolving, absorbing new information, reconciling it with what is stored, and staying organized enough to remain efficiently searchable and trustworthy as it grows. Today’s models offer no such memory: the context window is ephemeral and degrades long before it is full(Liu et al.,2024 (https://arxiv.org/html/2607.26637#bib.bib9)), so persistent external memory has become a first-order component of agent design(Zhang et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib22)). Throughout, we usememoryin the inclusive, classical sense(Sumers et al.,2024 (https://arxiv.org/html/2607.26637#bib.bib18)): it spansdeclarativecontent (facts, events, preferences, rules) andproceduralcontent, the reusableskillsan agent distills from experience(Wang et al.,2024 (https://arxiv.org/html/2607.26637#bib.bib19); Anthropic,2025b (https://arxiv.org/html/2607.26637#bib.bib2)), with one store serving both.

Research has explored many forms for this memory: OS-style paged context(Packer et al.,2023 (https://arxiv.org/html/2607.26637#bib.bib13)), extracted fact stores(Chhikara et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib5)), temporal knowledge graphs(Rasmussen et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib15)), self-linking note networks(Xu et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib20)), summary banks(Zhong et al.,2024 (https://arxiv.org/html/2607.26637#bib.bib23)), discourse-unit stores(Pan et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib14); Zhou & Han,2025 (https://arxiv.org/html/2607.26637#bib.bib24)), and embedding-organized trees(Rezazadeh et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib16)), each behind its own purpose-built interface. Deployed practice has converged on something plainer: thefilesystem. Coding agents already live on files, so files became the natural interface for extending their context: Anthropic’s memory tool exposes memory as a directory of files behind six generic file operations(Anthropic,2025a (https://arxiv.org/html/2607.26637#bib.bib1)), Claude Code maintains agent-written notes in an indexed memory folder(Anthropic,2026a (https://arxiv.org/html/2607.26637#bib.bib3)), and agent context files and “skills” ship as repository markdown at ecosystem scale(OpenAI & Agentic AI Foundation,2025 (https://arxiv.org/html/2607.26637#bib.bib12); Anthropic,2025b (https://arxiv.org/html/2607.26637#bib.bib2)). The filesystem earns its place: it is inspectable, portable, and operated with the file tools agents already master. It is also natively hierarchical: folders form a taxonomy whose names are its labels. Yet the medium that ships by default is the one research has largely passed over. Prior work builds agent systemsonfilesystem memory and studies retrievaloverfiles(Zhang et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib22)); the memory form itself has received little systematic study: how an agent-curated file store should be built, shaped, and kept healthy.

This default practice rests on an untested assumption: that the store stays manageable as it grows. Writing memories once and reading them back is the easy case; over long horizons, memories accumulate, and with them duplicates, contradictions, stale facts, and content on one subject scattered across many files. The store must beevolved: updated, reconciled, reorganized. Getting this wrong is costly: continuously rewriting a memory bank with an LLM can degrade it below the no-memory baseline(Zhang et al.,2026 (https://arxiv.org/html/2607.26637#bib.bib21)). Existing mechanisms do not close this gap. Academic memory operations act per item (add, update, delete)(Chhikara et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib5)), never on the shape of the store. Industry consolidation (“dreaming”) runs outside the agent: OpenAI’s dreaming synthesizes a flat memory summary in the background(OpenAI,2026 (https://arxiv.org/html/2607.26637#bib.bib11)), and Anthropic’sDreamsrebuilds a store wholesale from past sessions(Anthropic,2026b (https://arxiv.org/html/2607.26637#bib.bib4)), introduced precisely because the working agent’s own writes remain “local and incremental” and the store degrades between rebuilds. External cleanup treats the symptom; whether the agent itself can keep a growing store organized, and whether organization repays its cost, remains assumed rather than tested. The filesystem’s native answer is the human one,organizing: grouping related material into folders, naming it so it can be found again, splitting and merging as content demands. Whether LLM agents can do the same, and whether it pays, is open in both directions. Organization might be exactly what keeps a growing memorysustainable, efficiently searchable and trustworthy in content as it scales; or a flat store swept by strong search tools might serve just as well, making curation an expensive detour.

This paper presents, to our knowledge, the first systematic exploration of filesystem-based memory for LLM agents.Section2 (https://arxiv.org/html/2607.26637#S2)formalizes the setting as three roles around a single store (Figure1 (https://arxiv.org/html/2607.26637#S2.F1)): amanagement agentthat integrates each incoming chunk and keeps the store organized, asearch agentthat answers queries over it with cited sources, and, in the skill setting, a fixedexecution agentwhose task attempts supply the chunks and consume the retrieved skills. The contracts are minimal by design, so the roles map onto deployed harnesses; in a coding agent, all three may be one model. We instantiate the setting for conversational memory (question answering with source attributions over long dialogues: LoCoMo, PersonaMem, REALTALK;Maharana et al.,2024 (https://arxiv.org/html/2607.26637#bib.bib10); Jiang et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib6); Lee et al.,2025 (https://arxiv.org/html/2607.26637#bib.bib7)) and for procedural memory (task success of a fixed execution agent: ALFWorld;Shridhar et al.,2021 (https://arxiv.org/html/2607.26637#bib.bib17)), and we vary four components: how the store is built (an organizing agent, a verbatim dump, or the raw stream chunked and indexed for retrieval(Lewis et al.,2020 (https://arxiv.org/html/2607.26637#bib.bib8))), the scale of the stream, the harness through which agents touch the store, and the strengths of the models that build and search. Throughout, we measure answer quality together with cost (rounds, tokens, content read) and store health over time (whether early memories survive later evolution and whether updates land correctly): growth curves, not endpoints.

Our study yields an empirical characterization of filesystem memory along five questions, each answered in both settings.

• •RQ1 (organization).Left to organize, management agents grow subject-based trees, but the shape is a signature of the model more than a response to scale: given more material the store consolidates rather than shards, hierarchy relocating between folders, files, and in-file headings; the clearest degenerate behavior is a reorganizing pass that silently condenses content unless one preservation rule is added.
• •RQ2 (value of shape).No shape wins correctness everywhere; organization’s unambiguous payoff is search cost, and it grows with the material. On skills the winner flips with the execution agent: a verbatim episode log serves a strong execution agent best, distilled guidance a weak one.
• •RQ3 (backbone model capability).On conversation the management agent’s strength buys organizational style, not answer quality, while the search agent’s strength pays directly. Capability does couple where writing itself fails: on one benchmark the management agent inconsistently records changed preferences as dated updates, leaving stale facts standing as live traits; a stronger backbone executing the same instruction recovers about half the loss, while the same upgrade moves nothing where the store already serves its search agent. When memory must be distilled into procedures, capability acts as a threshold: once crossed, what the store contains matters more than which model executes.
• •RQ4 (sustainability under scaling).Within our horizons, stores only become more useful as they grow, and accumulated experience substitutes for execution-agent capability. Store health holds in both settings: conversational stores create their few files early and afterwards only edit them, never deleting, while on skills early memories survive and a stronger management agent maintains files in place rather than replacing them. Organization is the weaker half: adherence to the taxonomy contract erodes as most stores grow, and only the strongest management agent we track holds it. The costs that scale are effort and volume: curation never gets cheaper per episode, kept stores stay compact relative to what the task chains generate, and the one liability that grows with the store is the verbatim episode log’s serve-everything retrieval.
• •RQ5 (harness).Adding a tool changes agent behavior but not outcomes; replacing the tool set reshapes the store itself, with direction and payoff set by the setting, sharding and tying on long dialogue, consolidating and winning on skills: the harness is a lever over memory organization, not a neutral wrapper.

Read against the default’s two assumptions, the answer splits: an agent can keep a growing store useful and healthy within every horizon we measured, though how well it stays organized tracks the management agent’s capability; whether organizing pays is conditional, on the material, on the agent that consumes memory, and on the tools in hand; no agent we measure converts organization itself into better answers.

Contributions.

• •Formalization and unification.A management/search/execution role decomposition of filesystem-based agent memory with minimal contracts, unifying declarative memory and skills in one store that mirrors deployed harnesses.
• •A systematic study framework.Benchmarks spanning long conversations and embodied tasks; controlled memory shapes; harness, scale, and model-strength axes; and a sustainability protocol tracking store health, cost, and quality as memory grows.
• •Findings.An empirical characterization that turns the filesystem default from an assumption into a design space: evidence that a growing store stays useful and healthy within the horizons we measure, while the quality of its organization remains bound to the management agent’s capability; guidance on when curation repays its bill and when a dump or chunk index suffices, on what to serve weak and strong consumers of memory, and on where model strength pays, the search agent on conversation and the management agent, past a threshold, on skills; and the tool set established as a control knob over store organization, with the open problems isolated: quality benchmarks largely blind to shape, and horizons beyond one conversation.

2Formalizing Filesystem-Based Agent Memory

The formalization below is deliberately minimal: it abstracts the memory systems that deployed harnesses already implement into the components our study varies.

Refer to captionFigure 1:Overview of filesystem-based agent memory. An execution agent does the work; what it experiences or chooses to save (conversation slices, task trajectories, or any other content) streams out as chunks into amanagement agentthat integrates each chunk into one memory filesystem, serving declarative memory and skills alike, and keeps it organized; when the agent needs to remember, it asks asearch agent, which traverses the store and returns attributed answers, cited to the store, or retrieved skills. The management and search agents act on the store only through an interchangeable tool harness, and the store’s evolution over the stream is tracked. The execution agent is optional and need not invoke the management agent directly (its logged content can be handed over).### 2.1The memory store

Amemory storeM{\mathcal{M}}is a finite set of files organized in a rooted path hierarchy. Each filef∈Mf\in{\mathcal{M}}is a triplef=(pf,df,cf)f=(p_{f},d_{f},c_{f}): a pathpfp_{f}(for example/memories/peopl