Memorix: Managing Memory Selections for AI Agents

Memorix: Managing Memory Selections for AI Agents Jing Zhang

Xiaguannan Song

Dong Du

Shanghai Jiao Tong University Shanghai, China

Shanghai Jiao Tong University Shanghai, China

Shanghai Jiao Tong University Shanghai, China

Erhu Feng

Yubin Xia

Shanghai Jiao Tong University Shanghai, China

Shanghai Jiao Tong University Shanghai, China

arXiv:2611.00060v1 [cs.OS] 13 Oct 2026

Abstract

Ahead of time Use time on the fly

AI agents now handle a growing share of tasks across sessions within a persistent project. Their behavior depends not only on the model, but heavily on the persistent state they read from the environment. Existing systems assemble this memory at use time, splicing selected files into the prompt as a one-off payload. As a result, per-task assembly is costly and can still miss critical material, failures cannot be traced or replayed, and agents can read documentation written for the wrong version. Our key insight is that what an agent should read is mostly determined by its project, so the selection can be computed once, ahead of time, and reused across tasks. We propose Memorix, an agent memory system that realizes this insight. Memorix achieves this via three key mechanisms: (1) an immutable and versioned Store pins every source by identity and reproduces historical layouts cheaply, (2) a View that splits selection (Derivations) from composition (Environment), making the result reproducible and shareable, and (3) Quests and Profiles keep a delivered view refreshable and available inside the project as sources evolve. We implement Memorix and evaluate it on SWE-ContextBench and LibEvolutionEval against mainstream agent memory systems. Precomputed Environments raise resolved rate by up to 1.5× and deliver the correct library version on every version-conditioned task, while cutting amortized cost by up to 100× and build time by up to 38×.

1

(a) Runtime retrieval (b) Live binding (c) Memorix (ours)

query session start

View

id

no identity

Search

Prompt payload

Agent

Expand

Prompt payload

Agent

.memory/

Agent

Activate

Time

Figure 1. Context selection at use time vs. ahead of time. Runtime retrieval and live binding produce an anonymous prompt payload on the fly. Memorix precomputes the selection as an object with identity and binds it into the project.

This memory is growing rapidly in both scale and diversity. In coding scenarios, the number of repositories maintaining agent rule files has grown exponentially [12], and many now keep multiple types simultaneously — the vast majority provide both AGENTS.md [61] and CLAUDE.md [10]. In office settings, Cowork-style products [8, 57, 59, 63, 83] bring agents into daily document processing, where the files they rely on (e.g., PDFs, Word documents, and PPTs) accumulate day by day. Agents also generate their own records such as snapshots, patches, and tool outputs. These records persist and shape every subsequent turn. Agent work differs from chat in how memory is used. In chat, each question is new, so what to read is decided per query. In agent work, one project persists across many sessions, and what an agent should read is mostly determined by the project itself: the code in the repository, the versions it pins, and the prior work it continues. Agent memory therefore has three requirements. First, tasks in one project largely need the same material, so what to read should be chosen once and reused across tasks. Second, developers evaluate an agent’s result and debug its failures by inspecting the agent’s input, so the memory that the agent read should be recorded and replayable. Third, the documents given to the agent should match the versions the project uses. For example, documents written for other versions can describe APIs that potentially conflict with the current project. However, current agent memory systems fall short in all three respects. First, each task assembles what to read from

Introduction

AI agents now perform a growing range of tasks once handled by humans [43, 74, 81]. These agents reason about the task, run commands, and read the outputs before deciding the next move [88]. Coding agents [7, 59, 67], for example, usually run this loop over source files and test feedback. As such work routinely spans multiple sessions [6, 39, 78] within one persistent project directory, an agent’s behavior depends not only on the underlying model, but heavily on the persistent contexts it reads from the environment. We collectively refer to this persistent state, including rule files, records of past work, and external documentation, as agent memory. Corresponding author: dd_nirvana@sjtu.edu.cn. 1

scratch, so agents spend extra retrieval steps and can still miss something entirely. Second, the system copies the files into the prompt and keeps no record of the input. The agent harness may also process the same rule files in its own way, and the files at the same paths can change. Hence, a failure cannot be traced precisely and the same context cannot be replayed. Third, a memory system often holds docs for many versions, and the system can give the agent the wrong release, or mix several together. Then agents can write calls against an API that does not exist in the project’s version. All three failures share one practice: what the agent reads is assembled at use time, and the system keeps nothing of it. It stores the sources but never the selection (i.e., which set of files and at which versions), so the input that most shapes an agent’s behavior is also the one it manages least. Existing approaches only work around this mismatch. Versioned files [13, 46, 47, 68, 72] can persist and version each piece of content, but they cannot compose them into a single referenceable result. Runtime retrieval [11, 15, 31, 37, 42, 46, 51, 65, 66, 75, 79] can fetch relevant content for semantic queries, but cannot guarantee consistent or deterministic results across runs. Live binding [1, 9, 10, 17, 34, 60, 61] can declare partial relationships between source files and consumers, but the binding stops at the declaration — the context is actually resolved at runtime and remains anonymous. Run snapshots [5, 27–29, 41, 58, 80] can precisely record and replay the execution state, but the recording is bound to one run and never becomes a reusable memory object. Our key insight is that, since what an agent should read is mostly determined by its project, the selection can be computed ahead of time and kept as an object. Like a file, the object has an identity. Hence, later tasks can ask for the same one by id instead of assembling the context again. It also records what it is made of, so the system can reproduce it, and notice when its sources change. Finally, the system can deliver it into the project as ordinary files. However, realizing this abstraction introduces three technical challenges. First, source files change continuously. Precomputed selections must be able to precisely reproduce historical states while also rapidly reflecting new states after source updates, without requiring a full recomputation every time. Second, selections typically involve multi-layered sources and compositional relationships. The system must compose them into one identifiable result, while each constituent selection remains independently addressable. Third, a delivered view will keep changing after the agent starts reading it. The system must be able to rebuild the view when sources change, and keep it available inside the project as a newer or older result takes its place. Based on our insight, we propose Memorix, an agent memory system that computes context selection ahead of time and represents the result as a first-class object with stable identity. To realize this, Memorix introduces three key designs to overcome those challenges.

First, Memorix treats each file as an immutable object within a Store and organizes them into a versioned logical file tree. An edit writes a new object and leaves the old version in place, so an earlier selection can still retrieve the object it used. Parent-child nodes record the hierarchy among files. When an object changes, Memorix rebuilds only the chain to the root and reuses unchanged siblings, so a historical layout can be reproduced without rewriting the rest of the tree. A latest/ index then points at the current tip, so a new resolve can start from the live structure rather than walk history. The Store therefore holds every source an agent may later read, at a pinned version that others can share by identity. Second, Memorix introduces the abstraction of View on top of the Store. A Derivation selects Store objects at fixed versions and arranges them as one identifiable result. For example, one Derivation may hold general Python guidance, and another the narrower rules for a vLLM-style repository. An Environment mounts one or more Derivations into a single logical tree that the agent reads as ordinary files, while each Derivation stays independently addressable. Splitting selection from composition is what makes sharing by reference possible: two projects can mount the same Python Derivation and differ only in the project-specific mounts. Changing what is mounted, or swapping a mounted Derivation, allocates a new Environment and leaves the previous one intact, so a run can record the exact tree it received. Third, Memorix keeps a delivered view refreshable and available through Quests and Profiles. A Quest records the intent behind a view and the identifiers the intent has resolved to, so a later session can find that view by semantic search, rather than selecting from the Store again. Once any referenced Store object gains a new version, the Quest is marked stale; the next session to access it is notified, and accepting the update re-resolves the intent to new Store objects. A Profile in the project points to an Environment and, when activated, places that Environment under .memory/. Moving the pointer upgrades or rolls back the project memory. Together, Quests and Profiles turn a delivered view into a durable part of the project, even as its sources move. We implement Memorix as a set of CLI tools, packaged with an agent skill [1] that teaches agents how to invoke them. We evaluate it on SWE-ContextBench [92] and LibEvolutionEval [38]. Our results show that precomputing project memory as an identifiable Environment improves agent task success while remaining cheap to build and share. For example, Memorix pins library documentation to the target version on every LibEvolutionEval task, instead of mixing or missing versions at retrieval time. On project-level coding tasks, it raises resolved rate to 64.6% vs. 44.4% for the nomemory agent and 59.6% for the best retrieve-at-use baseline. Amortized cost drops by up to 100× relative to heavy ingest.

2

The Case for Agent Memory

2.1

Agent Execution and Memory

In modern software development, an increasing number of tasks are handled by AI agents. Rather than merely replying to a user’s question, these agents invoke tools to interact with the external environment, thereby producing higherquality results. In this section we explain the key concepts of agents and the persistent state they rely on. Agent execution loop. Large language models (LLMs) operate over a context window that is first prefilled with prior content. The model then autoregressively generates tokens until it emits a special end-of-turn token. To overcome the limitations of a static model (e.g., the lack of real-time information or the inability to act on the external world), modern systems introduce tool calling. In this setting the model may emit a sequence of special tokens that encode a function call. Rather than returning the call to the user, the agent runtime intercepts it, executes the corresponding tool (e.g., a Python function, a file-system operation, or a shell command), and appends the tool’s result to the context window. The model then continues generation conditioned on the newly appended result. This loop of generation, tool execution, and context extension constitutes a single agent turn and can be repeated across multiple turns and sessions. Forms of persistent state. Beyond the transient contents of a single context window, agents depend on a variety of persistent state that survives across turns and sessions. We collectively refer to this state as agent memory. It typically takes three forms. First, rule and instruction files (e.g., AGENTS.md, CLAUDE.md, .cursorrules) reside inside a repository and encode style constraints, workflow conventions, and safety boundaries that the agent is expected to follow. Second, agents themselves leave behind artifacts during execution — snapshots of files they have read, generated patches, intermediate results, and tool outputs — which are frequently re-read in subsequent sessions. Third, agents consult external documentation and dependency information, such as API references and version-locked library specifications; the particular version of a document an agent reads often directly determines the version of an API it later emits. All of these artifacts are stored as ordinary files in the project directory or in shared locations, and they form the durable substrate on which an agent’s cross-session behavior is built. Memory resolution and delivery. Memory reaches the context window through several routes that differ in when the content is materialized and who triggers it. Rule files (e.g., AGENTS.md) are automatically resolved by the agent runtime before the loop starts and are injected in full. These files can further pull in other files through @import, which the

All

Some

None

Related tasks (%)

2

Shared histories (%)

Build time and storage drop by up to 38× and 22×, respectively, because a small project-level build is reused across tasks. Finally, we will fully open-source Memorix.

100 75 50 25 0

Initial

+1

+2

3+

Missing

100 75 50 25 0

Mem0 OpenViking MemOS

Mem0 OpenViking MemOS

(a) Initial coverage

(b) Extra rounds

Figure 2. Shared memory lacks a stable selection. Across 19 histories linked to 48 tasks: (a) per history, first-recall coverage over its linked tasks; (b) per task, extra memory-access rounds before its linked history arrives, including Missing tasks that never receive it. runtime expands at load time. Not all memory is injected upfront. A rule file in a subdirectory takes effect only when the agent accesses files under that directory. Skills [1] inject only their names and descriptions as an index, and the agent fetches the full body through a tool call when it judges them relevant. Ordinary files in the workspace enter the context only when the agent reads them with file tools during the loop. Other systems instead retrieve memory fragments from external stores by similarity search at run time. 2.2

From Chat to Agent

Traditional chat systems operate under high query dynamism. Each user turn introduces a new semantic intent, so the relevant context is typically determined at runtime through similarity search or on-demand expansion. Agent workloads differ in a fundamental way. An agent usually executes multiturn, multi-session tasks inside one persistent workspace. What it needs to read is largely shaped by the repository it belongs to, the pinned versions of its dependencies, and the artifacts left by its own earlier work. These relationships are mostly determined by the project structure rather than by the semantics of any single task. As a result, the sources that enter an agent’s context exhibit far greater stability across turns and sessions than those in conventional chat settings. 2.3

Limitations of Agent Memory

Three structural limitations hinder current agent memory. Unstable selection. Current agent memory systems retain shared memory, but each use retrieves a fresh subset of it. Retrieval ranks fragments against the current task’s query, so the same history surfaces differently for each task. Related tasks in one project therefore have no stable selection to reuse. Fig.2 shows the consequence on SWE-ContextBench [92]. Even the strongest (MemOS [46]) puts only 79% of shared memory into every related task’s first recall (Mem0 [51] 58%, OpenViking [11] 63%), so part of the shared memory does not reach some related tasks. The natural fix is to ask again, but raising coverage needs extra memory-access rounds (one model response that initiates memory access), and 8%–27% 3

indent no-os.system js-header chkpoint glob-version final-marker test-first yaml-priority indent-conflict

Correct

codex / swap model claude / swap doc deepseek / swap harness no doc gptdeepseekaider aider CLAUDE AGENTS opencode pi 5.6-sol v4-flash read auto 4/4 4/4 4/4 4/4 4/4 4/4 4/4 0/4 4/4

4/4 4/4 4/4 4/4 4/4 4/4 4/4 0/4 4/4

4/4 4/4 4/4 4/4 4/4 4/4 4/4 0/4 4/4

1/4 4/4 0/4 0/4 2/4 0/4 3/4 0/4 4/4

4/4 4/4 4/4 4/4 4/4 4/4 2/4 0/4 4/4

4/4 4/4 4/4 4/4 4/4 4/4 2/4 0/4 4/4

4/4 4/4 4/4 1/4 4/4 3/4 0/4 0/4 –

Wrong

Mixed

None

100

Pass (%)

Probe

0/4 4/4† 0/4 0/4 0/4 0/4 0/4 0/4 4/4†

75 50 25 0

Matplotlib

Torch

Figure 3. Wrong-version documents hurt accuracy. Pass rate on LibEvolutionEval [38] when the agent receives only the required-version documents (Correct), only other versions (Wrong), both (Mixed), or no documents (None).

Table 1. Same rules, different obedience. Rows are nine rule-following tasks; columns are eight ways of delivering the same rules. Each cell counts how many of four runs obeyed. “–” marks cells where the base task itself failed. † marks cases where the model already complied without seeing the rules. Rules and model stay fixed across columns.

and wrong documents can hurt more than giving no documents at all (Matplotlib 52.7% vs. 58.7%, Torch 37.8% vs. 71.1%). Mismatched APIs will enter the context unnoticed, and the agent can write calls against an API that does not exist in the project’s version (details in §6.4).

of related tasks need at least one. Fig.2(b) shows that some tasks still receive nothing at all. As a result, related tasks keep paying repeated fetch cost, and shared memory can still be missed entirely (details in §6).

Limitation 3: Without pinned versions, recall cannot guarantee documents that match the project’s version.

Limitation 1: Without a stable selection, each task re-fetches the shared memory, and some of it still never arrives.

2.4

Current Works

Versioned files. Git [13, 47] and other systems [46, 68] keep each document on its own history, so a checkout can restore a past state of those files. Rule files (e.g., AGENTS.md [61], CLAUDE.md [10]) live in the same layout, and documentation hosts likewise publish a separate build for each release [72]. Reproducing one file, or even a full checkout, is therefore straightforward. However, agent memory needs something more: the files a project wants the agent to read together form a chosen subset, and file-level history alone does not turn that subset into a unit the project can point to, reuse, or watch when one of its inputs changes. Runtime retrieval. Systems (e.g., Mem0 [15, 51], OpenViking [11, 31], and MemOS [46]) retrieve fragments at use time by similarity or graph lookup [37, 42, 75, 79]. That design fits chat, where each turn can change what matters and the useful text may sit anywhere in a large corpus [65, 66]. But agent work is different. The agent stays inside one project, so what it should read follows from that project rather than from the wording of a single query. Because each use builds a fresh subset on the spot, two related tasks can receive different fragments even when the rules and the model stay the same. Related tasks therefore do not share one durable subset they can rely on, and a change in an upstream input leaves nothing clear to revisit. Live binding. Other systems declare which sources an agent may read and expand those links when the session starts or when the agent later reaches the matching path. Imports [10, 34], directory-scoped rules [10, 17, 34, 61], and skill indexes [1, 9, 60] all work this way. They keep the underlying files in ordinary project history and they state part of the relationship up front. The declaration, however,

Unrecorded delivery. Current agent memory systems hand the agent an assembled context, but keep no record of the input. Tab.1 shows the costs of this in practice. We use nine tasks, each requiring one specific rule to complete, and deliver the same rule file in eight ways, with one model swap as a control. It shows three key findings: (1) Default injection decides success. Claude Code ignores AGENTS.md, so renaming the file causes the majority of js-header, chkpoint, and final-marker runs to fail. (2) The editing protocol can conflict with a correct rule. Aider [2] expects a filename plus a fenced code block, but in indent-conflict the model emitted valid JSON that obeyed the documented rule, so the task still failed. (3) Natural-language priorities are unreliable. No harness respected the highest-priority rule in yaml-priority. Retrieve-at-use systems have the same gap: each use builds a fresh context, leaving nothing stable to replay. File-path delivery fails similarly. Since the content under a path can change, it does not identify what the agent actually read. Limitation 2: Without a record of the input, a failure cannot be traced and a delivery cannot be replayed. Unversioned delivery. A project usually uses one version of a library, but the memory pool holds documents for many. At each use, the system recalls some of them without pinning the choice to the project version. Fig. 3 shows why that pin matters. With only correct documents, agents pass 65.9% of Matplotlib tasks and 75.6% of Torch tasks. With only wrong documents, pass rates fall to 52.7% and 37.8%. Mixed documents also lag behind correct-only documents, 4

Approach

Version individual sources

Declarative multi-source composition

Selection identity

Delivery attribution

Freshness tracking

Workspace binding ▲

Versioned files [13, 46, 47, 68, 72]

✓

✗

✗

✗

▲

Runtime retrieval [11, 15, 31, 37, 42, 46, 51, 65, 66, 75, 79]

▲

✗

✗

✗

▲

✗

Live binding [1, 9, 10, 17, 34, 60, 61]

✓

▲

✗

✗

✗

▲

Run snapshots [5, 27–29, 41, 58, 80]

▲

✗

▲

✓

✗

✗

Memorix (Ours)

✓

✓

✓

✓

✓

✓

Table 2. Existing mechanisms for agent memory. Each row is a class of current practice. Columns are capabilities that agent memory needs. ✓ means the capability is supported. ✗ means it is not. ▲ means support is partial or only at an adjacent layer. Existing classes cover individual slices, but none of them satisfy all. Project

stops before delivery: what the runtime actually puts into the prompt is still assembled on the spot and left without a durable handle. The same files can therefore yield a different prompt under a different harness, with nothing left to replay that delivery or to tell whether an input has since changed. Run snapshots. A run snapshot freezes one execution so that run can resume [5] or play back. For example, LangGraph checkpointers keep the messages and tool outputs at a given step [41]. Similar record-and-replay [29, 58] or sandbox tools [28] do the same for a whole environment. Although this record answers what one agent saw [27, 80], the next agent still needs to know what to read in this project. A frozen thread does not answer that, and it will not reflect later edits to those sources either. Summary. As shown in Tab. 2, each existing mechanism already covers one slice of the problem. But none of them treats the selected context as an object with its own identity. Related tasks therefore rebuild that context for each use, and the project has little left to replay or pin afterward. Agent work makes a better option available, because what should be read usually follows from the project itself. Memorix computes the selection ahead of time and therefore covers the gap.

3

Memorix Overview

3.1

Insight

.memory/

current

symlink tree

View Environment

resolved view

Derivation Derivation

/ └─ llm/ └─ cpp/

est intent

mount

statistics

Derivation ref

derived

freshness

updates

build

Store blob

blob

blob

/ └─ chat/ ├─ rules/ └─ docs/

Figure 4. Overview of Memorix. Locked objects are immutable: a Derivation pins Store blobs and may carry derived artifacts, and an Environment mounts Derivations as one tree. Each resolved view is recorded on a Quest that tracks intent, statistics, and freshness. Store updates mark the Quest stale. A Profile points at the current Environment and activates it as a symlink tree under .memory/. The context an agent reads is one such result. Memorix introduces five object types: Store, Derivation, Environment, Quest, and Profile. We call a Derivation or an Environment a view: a precomputed selection with a stable identity. Fig.4 shows how they refer to each other. Store. Memorix starts with files that later steps can refer to by identity. Each remembered file is an immutable object. An edit creates a new object and leaves the old one in place, so an earlier identity is still addressable. Objects sit in one tree whose root is global memory. The top level of that tree is memory kind. For instance, /rules for written instructions, /docs for project or API documents, and /chat for traces taken from earlier runs. Users then add their own levels under each kind. For example, /rules/python can hold the general Python guidance, while /rules/python/vllm contains guidance for vLLM-style repositories only. The tree

The core limitation is that selected context never becomes an object. Related work therefore either stores raw sources and resolves them at use time, or searches for fragments when a query arrives. Both follow from the same assumption: what the agent should read will change with the next question. Our observation is that agent work drops this assumption. The agent stays inside one project, so the sources it should read are mostly determined by that project. Thus, our insight is that context selection can be precomputed and explicitly represented as an object with identity. Later work can point at that identity instead of assembling the same context again. 3.2

activate

Profile

Object Model and Architecture

Memorix makes every computed result an immutable object with a stable identity, following the object model of Nix [24]. 5

latest/

records which paths exist and which versions each path has. A latest/ index points at the current tip of every path, so a new resolve can start from the tips rather than walk history. Derivation. Once files have identities, a selection of them must have an identity as well. A Derivation is that object. It lists Store objects at pinned versions and arranges them in a subtree, so resolving the same Derivation yields the same tree. Different Derivations can select different Store objects. One may hold Python-project memory, another C++ rules, another the docs for library 𝐿 at version 𝑣. A Derivation may also carry derived artifacts of that selection: a summary of the chosen files, or embeddings used for retrieval over those files. Those artifacts hang on the Derivation itself. Environment. A project often needs several Derivations at once, but they should appear as one tree so that the agent can browse and read that context with ordinary file tools. An Environment mounts each Derivation into that tree and is the object later delivered to an agent. For example, one Environment may place a Python Derivation at /python and a C++ Derivation at /cpp. Changing the mount set, or changing a mounted Derivation, allocates a new Environment, and the previous one remains addressable. Quest. Source files keep changing after a view exists, so it must be able to report when its inputs have moved and to be resolved again. A Quest records why a Derivation or an Environment was built: the task the view serves, and the files it set out to gather. Memorix writes the Quest in the same step as the view, so the intent stays attached to the objects it produced. In addition, the Quest is text, and an agent can grep it. Each resolve returns one Derivation identifier or one Environment identifier, and the Quest keeps a history of those identifiers. When a Store object under the current resolve gains a new version, the Quest marks that resolve stale and reports to the user. A later resolve can then produce a new identifier, once the user accepts the update. The Quest also counts resolves and reads as demand on the view. That signal can prompt a new summary on the Derivation or a split into finer Derivations. Profile. The Environment is what the agent should read, but it is still an object outside the project. An agent works in a project directory and needs that Environment to appear there, under a binding that can move. A Profile is that binding: a mutable pointer, kept in the project, to one Environment identifier. Moving the pointer to a newer Environment upgrades the memory. Moving it to an older identifier rolls the memory back. After the pointer is set, Memorix builds a tree of symbolic links under the project directory (e.g., .memory/). Hence, the agent can read that directory with ordinary file tools, and a run records the Environment identifier as the context it received. 3.3

rules/

docs/

chat/

[3] refs/rules/latest G2

G3

mem0@v1

pptx@v1

excel@v3

[2] Update lang/

lang/

[1] Ingest new version cpp.md

python.md

excel@v2

excel@v1

[4] Version locator cpp.md@v2 cpp.md@v1

chat/excel@v2 rules/lang/cpp.md@latest

Figure 5. The Store. latest/ is the checkout of typed trees. An ingest of a new cpp.md writes a blob, cpp.md@v2 ([1]). The update rebuilds only the ancestor chain: lang/ is rewritten and generation G3 succeeds G2, while python.md is reused and the other trees do not move ([2]). refs/rules/latest then advances to G3 ([3]). A version locator such as rules/lang/cpp.md@latest points to the new version, while older ones (e.g., chat/excel@v2) remain addressable ([4]). Ingest. A file enters the Store as an immutable object under its path. If that path already holds a file, the edit creates a new version and leaves the previous one addressable. Also, it updates the freshness of Quests that hold the old version. Resolve. To obtain a view, the agent first greps Quest text for a matching intent. A fresh match is reused directly. If the match is marked stale, the user decides whether to refresh it. If no suitable view exists, the agent walks the Store tree, selects the needed files, and builds Derivations. The selected Derivations are then mounted into an Environment. Building each Derivation or Environment also creates a Quest that records the intent behind that view. A Profile in the project then points at the Environment. When the Profile is activated, Memorix can materialize the Environment under the project (e.g., .memory/), and the agent reads Store objects through that tree using ordinary file tools.

4

Detailed Design

4.1

Store: Versioned Memory Tree

Because source files keep changing, Memorix must record each modification and retrieve a version efficiently. As Fig.5 shows, Memorix addresses this with a versioned Store. Immutable objects. The Store must be able to give back the same file content that was previously used. In practice, projects usually keep one file at each path and overwrite it whenever it changes. After an overwrite, however, the path no longer refers to the old content, so the earlier selection cannot be reproduced. A path can locate the current file, but we need a way to locate the content itself. Hence, when Memorix admits a file on ingest, it computes the SHA-256 of

Workflow

The end-to-end flow has two paths: ingest and resolve. 6

Derivation/D1

the content and stores the content at blobs/<hash>/object. The blob is immutable, so a later change becomes a new ingest under a new hash, while the old hash still retrieves the old content. Similarly, a deletion marks the file without removing the content. A selection records blob hashes and reproduces itself by reading the blobs at those hashes. Bottom-up versioning. Content is stored by hash, yet each blob is still placed at a path. The Store must keep a versioned layout of those path-to-blob placements, and update it cheaply when only one path changes. A common idea is to save each new layout as a full listing of all paths and blobs, rewriting unchanged paths along with the rest. As paths accumulate, each small edit therefore becomes slow. We observe that an edit usually touches only the chain from the changed file up to the root, while neighboring directories keep the same children. Therefore, Memorix records each directory as an immutable tree object and rebuilds only that chain bottom-up (a Merkle tree [52]). A tree object is a trees/<hash>.json that maps each child name to a blob hash or to another tree hash. When a leaf gets a new blob, Memorix writes new trees for its ancestors and reuses old tree hashes for unchanged siblings. An ingest records a new generation that points at the new root tree, and links to the previous one. Reading a generation walks that root tree to the blob hashes, so an earlier layout can still be reproduced. Typed trees. The Store holds written rule files, project documents, and traces from earlier runs. These files are written by different people and change on different schedules. If we keep them in one tree and tell them apart by folder names, every edit advances a single generation chain, which is inefficient and costly. Since these types do not depend on each other, Memorix gives each type its own tree: rules/, docs/, and chat/. Each tree holds its own blobs, tree objects, and generations. An ingest writes the blob into the target tree and records a new generation of that tree. The other trees do not change. An rm records a new generation of that tree with the path gone. Latest tip. Once layouts are recorded as generations, the Store must still make the current layout efficient to reach. Generations link only backward, so nothing in the graph points at the current state; ordinary tools such as ls and cat expect files on a path, not a generation graph. Once the current generation is known, however, its tree already lists every path and blob, so it suffices to remember that generation as the tip and present those files on ordinary paths. Hence, Memorix keeps a movable reference at refs/<type>/latest that records the current generation and maintains a readonly hardlink tree under latest/ that mirrors that generation’s paths onto blob objects. An ingest that updates a path advances the generation, moves the reference, and refreshes those hardlinks. Historical layouts remain reachable by generation id.

cpp.md@v1

[1] resolve before ingest

rules/lang/ cpp.md@latest chat/excel@v2

[2] resolve aer ingest

[3] new build

Selection IR

excel@v2

Environment/E1 Summary S1

/cpp -> D1 /llm -> Ds

/ └─ llm/ └─ cpp/

[4] mount Derivation/Ds

[5] new build

python.md@v1

[4] mount Environment/E2

Derivation/D2 cpp.md@v2 excel@v2

Summary S2

/cpp -> D2 /llm -> Ds

/ └─ llm/ └─ cpp/

Figure 6. Building and composing Views. The same selection IR resolves to D1 before an ingest ([1]) and to D2 after it ([2]). The locator rules/lang/cpp.md@latest advances from v1 to v2, while chat/excel@v2 stays pinned. The new build ([3]) produces D2 with a fresh summary, and mounting ([4]) places D1 or D2 at /cpp and the shared Ds at /llm, so swapping D1 for D2 creates E2 ([5]). Locators. A current file sits on a path under latest/, while an older file is reached by generation id. A selection has to pick the tree, the path, and either the tip or a generation. Memorix records that as a locator. For example, rules/cpp.md selects one file and docs/api/ selects a subtree, and either can take @latest or @<generation-id>. @latest resolves to the file currently shown under latest/. An ingest destination is the same form without a version selector. 4.2

Views: Derivation and Environment

Selections involve multi-layered sources and compositional relationships, so they must form one identifiable result while each part stays independently addressable. Memorix addresses this with Views: Derivations and Environments. Fig.6 shows how a Store update changes one selection while a shared View remains reusable. Selection IR. As discussed in §4.1, a locator can take @latest or a generation id; a selection is a list of such locators, so some entries move when the Store moves. Resolving a selection yields files, but the result no longer records which locators produced it, so it cannot be re-evaluated after the Store changes. Memorix therefore keeps the unresolved list as a selection IR. The IR stores each locator’s tree, path, and version selector. A build evaluates it against the Store: @latest reads the latest ref, a generation id opens that generation, and each path then walks to blobs. For example, an IR with rules/cpp.md@latest and docs/api/@generation/03 reads the current rules generation for the first locator and generation 03 of documents for the second, then takes cpp.md and every file under api/. After a new ingest of rules/cpp.md, the same IR picks up the new rules blob while still selecting the same api/ files. Derivation. A selection of Store files must remain referable as one result, including a fixed folder the agent can read. A common idea is to keep a list of pinned path@generation 7

Project

Store Ingest

est

entries, and to walk that list and build a folder whenever the files are needed. The list can still be edited in place, so the selection as a whole can change even when every path@generation is pinned. We observe that, as with file content in the Store, the selection itself needs an immutable object. Hence, Memorix records each built selection as an immutable Derivation. A build writes the pinned generation and blob for every chosen path into resolved_inputs, hashes them into a derivation_id, and stores the ready folder under tree/. The same resolved inputs yield the same id, so later steps can mount or open that Derivation and read the same folder. A Derivation may also carry derived artifacts of that selection (e.g., a summary). Memorix stores them keyed by the derivation id, so every project that mounts the same Derivation reuses them without recomputing. Environment. A project needs one memory folder the agent can read, while parts of that memory must stay reusable in other projects that overlap only in part. If we put everything a project needs into one large Derivation, shared files and project-only files then become one selection. Then a second project cannot take the shared part without the project-only part, and derived artifacts on the shared files cannot be reused on their own. Therefore, the shared part and the project-only part must be separate selections. Memorix records a composition of Derivations as an immutable Environment. An Environment stores bindings that mount each Derivation at a path, and hashes them into an environment_id. It presents one folder by placing each Derivation’s tree/ under its mount path. Changing what is mounted, or swapping a mounted Derivation, creates a new Environment. Finally, each Derivation id remains independently usable, so shared selections and their derived artifacts can be mounted into many Environments. Conflict resolution. When an Environment mounts several selections, their contents may disagree, so Memorix needs an explicit rule for which file wins. There are many kinds of conflicts. For example, a file may have several versions, two rules may sit at different depths of the same path family, or guidance from different memory kinds may conflict. Therefore, Memorix resolves each case as follows. For multiple versions of the same file, it prefers the latest version, or the version locked by the repository when a lock is present. For conflicts inside one path family (e.g., general Python rules vs. vLLM rules), it prefers the deeper, more specific leaf. For conflicts across memory kinds, it orders by trust: /rules over /docs over /chat, because hand-written rules are the most precise, documents describe the codebase less authoritatively, and chat extracts are the noisiest. Finally, these rules are only defaults, and users can override these defaults explicitly.

intent statistics freshness

cpp.md@v1

v2

Profile gen 1

[1] mark stale gen 2

r1 -> E1

current

Environment/E1

[2] accept new version r2 -> E2

[4] rollback

Environment/E2

[3] activate

.memory/ └─ llm/ └─ cpp/

Figure 7. Evolving and delivering a view. A Store ingest marks the dependent Quest stale ([1]). Accepting the new version appends resolve r2 to the Quest history ([2]). Activation sets the Profile’s current generation to gen 2 and refreshes the symlink tree ([3]). Moving current back to gen 1 rolls the project memory back to E1 ([4]). 4.3

Quest and Profile: Evolution and Delivery

A delivered view must be findable again later, stay fresh as the Store moves, and remain available inside the project as a newer or older result takes its place. Memorix addresses this with Quests and Profiles. Fig.7 separates the history of resolved views from the versions activated in a project. Quest intent. After a view exists, a later session or project must be able to find a suitable one again without selecting from the Store from scratch. A naïve way is to let an agent browse the pool of Views, and search the selected source files to decide which view fits. That agentic check can improve accuracy, but verifying many candidates this way becomes prohibitive as the pool grows. We observe that whether a view fits depends on the task it serves, which a view’s selected files do not record. Hence, Memorix writes a Quest whenever a view is built. The Quest stores searchable intent text and links to the Derivation or Environment that view produced. Agents discover Quests with find or grep over that intent, then open the linked view. Each later resolve appends the new result id to the Quest’s history, so the same intent keeps a trail of resolved views over time. Freshness. A Quest’s current resolve can fall behind as the Store gains new versions. A simple method is to rebuild on every use, but it wastes work when nothing relevant has changed. Another is to keep the old Environment with no check, but it leaves the agent on expired context with no signal. Memorix maintains a reverse index from Store paths to Quests, so whenever an ingest completes, it marks every Quest stale whose current resolve still depends on the old version. When a later session finds this Quest, it sees that mark. If the user wants to accept that update, Memorix reevaluates the corresponding View, creates a new View, and appends it to the Quest history, while the old history remains in the Quest so that the user can see the changes. Profile binding. The Environment lives in the Store, but the agent works inside a project directory and needs that memory as ordinary files under the project. Copying the files into the repository loses the clean binding to the Environment, 8

risks inconsistency with the Store, and is hard to refresh or roll back. Memorix therefore keeps a Profile in the project that points to one Environment. It activates an Environment under the project as a symlink tree at .memory/. The agent reads with ordinary file tools, and a run can record the Environment id as the context it received. Upgrade and rollback. After a Profile is bound, the project must be able to switch to a newer or older Environment without the user tracking ids by hand. Re-running activate with a new Environment id moves the project forward, but leaves rollback to out-of-band bookkeeping. Hence, Memorix keeps an ordered binding history in the Profile, with a current pointer to one Environment. Moving current forward selects a newer binding and upgrades the memory; moving it back selects an older one and rolls the memory back. Each move refreshes the symlink tree under .memory/ to match the Environment now selected.

5

Hence, we use symlinks for these scenarios. Symlinks have limits, though: some systems disable them, and a symlink can redirect reads outside the Store. We leave a portable delivery mechanism to future work. Atomic updates. Agents read latest/ and .memory/ while ingest and activate rewrite those trees. A torn tip would mix old and new paths in one turn, so Memorix publishes each update atomically. On ingest, it first writes the new blob, tree objects, and generation as immutable files. Only then does it swing refs/<type>/latest to the new generation id and replace latest/ by building a fresh hardlink tree aside and renaming it into place. On activate, upgrade, or rollback, it writes the Profile’s current pointer and replaces .memory/ the same way: stage a new symlink tree, then rename. Readers therefore always see either the previous tree or the new one, never a half-applied mix. Immutable history stays reachable by generation id or by an earlier Profile generation, so a swing of the tip does not erase what earlier resolves already pinned.

Implementation

We have implemented a Memorix prototype in 30k lines of C++, together with a skill document that agents use to drive the CLI. This section covers the implementation choices that matter most for usability and correct delivery. Usability. Users prefer to build and search memory in conversation: for example, asking an agent to put a document into memory. Precise control of Memorix, however, goes through a CLI that takes exact identifiers (e.g., path, generation) and runs them as given. Between these two sits a gap: natural language is too loose for exact memory operations, while the CLI alone is too rigid for ordinary use. Memorix closes this gap in two ways. First, it ships the CLI manual as a skill. The harness keeps only the skill description in the system prompt. The agent reads the full manual on demand, so ordinary turns stay free of the manual while natural-language requests can still trigger exact CLI calls. Second, Memorix records each view’s intent in a Quest. The Quest gives the agent searchable semantic information with which to find and select a suitable memory when building a new view. The skill supplies how to invoke the CLI. The Quest supplies which view fits the current intent. Once an Environment is activated, the agent can read it with ordinary file tools. Symlink and hardlink. Memorix picks a different link kind for each job. For the Store, it fills latest/ with hardlinks. A hardlink shares the blob’s inode, so latest/ exposes that content directly, with no extra copy. Paths under latest/ also look like ordinary files to tools such as ls and cat. Refreshing latest/ sits off the agent’s read path, so the cost of link and unlink on ingest is acceptable. The Profile needs a different binding. Upgrade and rollback must retarget the project tree cheaply. Besides, unlike the Store where blobs and latest/ always share one filesystem, a Profile may bind a project to an Environment on another filesystem.

6

Evaluation

Our evaluation aims to answer the following questions: • Q1: Does precomputed project memory improve task success relative to retrieve-at-use memory systems? (§6.1) • Q2: Does Memorix lower per-task cost as more tasks share one project memory? (§6.2) • Q3: Does Memorix reduce end-to-end latency at runtime relative to retrieve-at-use memory? (§6.3) • Q4: Does version-pinned memory improve correctness on version-conditioned tasks, and how do correct versus wrong version retrievals compare to baselines? (§6.4) • Q5: What build and storage overhead does Memorix introduce relative to retrieve-at-use baselines? (§6.5) Benchmarks. SWE-ContextBench [92] evaluates whether coding agents can reuse experience across related tasks. We use SWE-ContextBench Lite, which builds an experience pool from agent trajectories or summaries on the 300 SWE-bench Lite [36] tasks and adds 99 related tasks identified through relations between their GitHub issues and PRs. LibEvolutionEval [38] evaluates whether models can generate API completions for a specified library version. We select 212 version-sensitive tasks in which the required APIs differ across library versions. Then we provide test cases for our evaluation. For each task, using an outdated API fails the tests, while only the API corresponding to the target version passes. This subset therefore enables a more reliable evaluation of version-specific memory retrieval. Baselines. We compare Memorix against three mainstream memory systems that span common organization paradigms: OpenViking v0.4.19 [11] (filesystem-based memory), Mem0 v2.0.20 [15, 51] (vector-store memory), and MemOS v2.0.33 [46] (graph-structured memory), plus a no-memory agent. All systems ingest the same historical materials. OpenViking, 9

OpenViking

Mem0

MemOS

Memorix

w/o Memory

Accuracy (%)

100 75 50 25 0

Django

SymPy

Matplotlib

Other

scikit-learn

Figure 8. Resolved rate on SWE-ContextBench Lite by project group. Four projects with at least 10 tasks are shown separately; Other groups the remaining eight projects (15 tasks). MemOS, and Mem0 retrieve online per task, while Memorix precomputes Store objects and Derivations and binds one Environment per project. Setup. We use deepseek-v4.1-flash [20] with high thinking effort as the model and the Pi coding agent v0.85.1 [67] as the harness. We price LLM tokens at $0.006 / $0.30 / $1.20 per million tokens [19] for cached input, uncached input, and output, respectively. Embeddings use text-embedding-3large [62] at $0.13 per million tokens. 6.1

1000

Cost (USD)

Precompute Runtime 950 80 60 40 20 0

OpenViking

Mem0

MemOS

Memorix w/o Memory

Figure 9. Precompute and runtime cost. Total API cost for all 99 tasks, which consists of a one-time precomputation over shared memory and runtime across all task runs.

Task Success

This subsection asks whether precomputed project memory raises resolved rate on project-level coding tasks relative to retrieve-at-use memory and to running without memory. Methodology. We evaluate on SWE-ContextBench Lite: 99 tasks across 12 projects, with 300 past experience trajectories as the shared memory material. OpenViking, MemOS, Mem0, and Memorix each organize that material. For Memorix, we provide the material to a Pi agent equipped with the Memorix skill. The agent constructs a set of Derivations and composes them into one Environment per project. The no-memory agent receives none. Comparing to no-memory shows whether past experience helps at all. Comparing to other baselines shows whether a precomputed project Environment influences accuracy. At runtime, Pi accesses OpenViking, MemOS, and Mem0 through system-specific plugins that expose their retrieval interfaces. For Memorix, it activates the corresponding Environment under .memory/ for Pi to access using ordinary file tools, with no extra plugin loaded at runtime. The official SWE-bench harness then applies the patch they output and scores it. A task is resolved when every FAIL_TO_PASS test passes and no PASS_TO_PASS test regresses. Results. Fig.8 shows resolved rate by project group. Over all 99 tasks, Memorix resolves 64.6%, ahead of MemOS (59.6%), OpenViking (57.6%), Mem0 (50.5%), and no-memory (44.4%). Every memory system beats no-memory, so past experience indeed helps the agent generate better patches. Memorix widens that gap the most, at +20.2 points over no-memory and +5.1 points over the strongest retrieve-at-use baseline

(MemOS). The largest lift is on SymPy, where Memorix reaches 57.7% against 30.8–34.6% for the retrieve-at-use systems and 19.2% without memory. On Django, Memorix ties MemOS at 63.9%. On Matplotlib, OpenViking and MemOS lead at 83.3%, while Memorix matches Mem0 and no-memory at 75.0%. These results show that precomputation is feasible for project-level agent work. Binding memory into an Environment ahead of time sustains high resolve quality under every new task. 6.2

Cost Analysis

This subsection asks whether Memorix lowers per-task cost as more tasks share one project memory. Cost. Fig.9 splits total spend on the 99 Lite tasks into precompute and runtime. Runtime cost is similar across systems, from $8.18 for Memorix to $10.99 for MemOS. Precompute dominates the gap. MemOS spends $973 before any task runs, OpenViking $77.7, and Mem0 $39.3. Memorix spends $1.66 on precompute, so its total $9.83 stays close to no-memory ($8.80). Per task, that is $0.099 for Memorix, about 5× cheaper than Mem0 ($0.498), 9× cheaper than OpenViking ($0.877), and 100× cheaper than MemOS ($9.94). Token breakdown. To further analyze the cost, Fig.10 breaks precompute tokens into multiple types. MemOS generates 783M output tokens while building memory, about 880× Memorix’s 0.89M output, which accounts for most of its $973 precompute bill under output pricing. OpenViking and Mem0 spend 61M and 57M uncached input tokens (70× and 10

800

100

200

Cached Uncached Output

100

CDF (%)

Precompute tokens (M)

1000

Embedding

600 0

400

OpenViking

Mem0

Memorix

Mem0 MemOS Memorix

200

w/o Memory

0

0

OpenViking

OpenViking

Mem0

Mem0

MemOS

1000

MemOS

Tokens per task (M)

Cost per task (USD)

OpenViking

50 25

Memorix

100 10 1 0.1 1

20

40

60

80 99

Number of tasks

Memorix

w/o Memory

10

20

40

60

10

15

20

4.96 min for Mem0. The gap widens in the tail. At p95, Memorix finishes in 11.2 min, about 1.3× faster than OpenViking (14.3 min) and Mem0 (14.6 min), and 1.6× faster than nomemory (17.6 min). At p99, Memorix is fastest at 13.8 min, ahead of MemOS (14.9 min) and about 1.3×–1.5× faster than OpenViking, Mem0, and no-memory. End-to-end time is still dominated by solving, which is why medians stay close. A precomputed Environment replaces retrieval by lightweight file operations, which cuts the long tail at runtime.

100

1

5

Figure 12. CDF of end-to-end per-task runtime.

1000

1

0

Runtime per task (min)

Figure 10. Precompute token breakdown by kind.

80 99

Number of tasks

6.4

Figure 11. Amortized cost and tokens per task as more tasks share one project memory.

Multi-Version Memory

This subsection asks whether version-pinned memory improves correctness on version-conditioned tasks, and how correct versus wrong version retrievals compare to baselines. Methodology. We evaluate on a 212-task subset of LibEvolutionEval: version-specific code completion for Matplotlib (167) and Torch (45), scored by executable tests we add. Each task provides a code context and a target library version; the memory system under evaluation provides the documents. A model then fills in the missing snippet from this prompt. A task passes when the completed code passes all tests. Memorix first ingests all documents into the Store (each version of a library becomes a different generation), and then builds the Derivations and Environments. Before each task, we use a Pi agent equipped with the Memorix skill to select an Environment. This step simulates a user preparing an Environment for the task’s codebase. After that, we append the contents of that Environment to the prompt. Other systems ingest the same documents with their native importers and retrieve once per task using provided task information. Accuracy. Fig.13 compares pass rate on the 212 tasks. Memorix leads at 68.4%, about 1.1× Mem0 (60.4%) and 1.3× OpenViking (53.3%) and MemOS (51.9%). Matplotlib, the larger slice, follows that pattern at 67.7%. On Torch the gap widens: Memorix reaches 71.1%, about 1.2× Mem0 and OpenViking (60.0% each) and 1.4× MemOS (51.1%). Version reading. Further, Fig.14 classifies each task by the library versions that appear in the delivered documents: correct (only the target version), wrong (only other versions), mixed (target and others), or empty. Memorix delivers only correct documents on all tasks. Mem0 is mixed on every task. OpenViking is correct on only 3.3%, wrong on 56.6%,

66× Memorix) plus 43M–44M extra embedding tokens. Memorix uses 55.4M cached input tokens and under 1M each of uncached input and output. Cached input is cheap relative to uncached input and output, so Memorix’s precompute stays at $1.66 even though its cached volume is non-trivial. Runtime dollars stay close across systems because the 99 solving passes do comparable LLM work once memory is in place. Amortization. Fig. 11 amortizes both dollars and tokens over more tasks that share one project memory. At 10 tasks, Memorix is already $0.25 per task, against $4.03 for Mem0, $7.86 for OpenViking, and $97.4 for MemOS. At 99 tasks the figures fall to $0.099, $0.498, $0.877, and $9.94, while amortized tokens fall to 4.31M per task for Memorix versus 5.52M–16.2M for the retrieve-at-use systems and 3.57M without memory. No-memory stays flat at $0.089/task. The curves fall because each new task reuses the same project build and mostly pays runtime. Memorix starts from a small build, so that sharing reaches near no-memory dollars and tokens, while heavier ingest baselines stay costly even at 99 tasks. 6.3

75

End-to-End Latency

This subsection asks whether Memorix reduces end-to-end runtime latency relative to retrieve-at-use memory. Results. Fig.12 shows the CDF of end-to-end latency on the same 99 Lite tasks. Median latency is close across systems: 3.76 min for Memorix and 3.70 min for MemOS, against 4.43 min without memory, 4.62 min for OpenViking, and 11

Memorix

Mem0

OpenViking

MemOS

12 Storage (GiB)

Pass (%)

100 75 50 25 0

Figure 13. Pass rate on the LibEvolutionEval subset. Tasks (%)

Correct Mixed Empty

25 0

Memorix

Mem0 OpenViking MemOS

Figure 14. Version composition of delivered documentation. Each bar groups all 212 tasks by the source versions. System Build time (h)

Memorix

OpenViking

Mem0

MemOS

2.2

8.4

27.2

84.5

Table 3. Cumulative memory build time. and mixed on 37.7%. MemOS is even worse: 0.9% correct and 82.5% wrong. The accuracy gap tracks this breakdown. Hence, a version-pinned Environment keeps the target docs in place, so the agent can follow the right API. 6.5

Overhead Analysis

This subsection asks what build and storage overhead Memorix introduces relative to retrieve-at-use baselines. Build time. Tab.3 shows cumulative build time over the 12 projects in SWE-ContextBench. Memorix finishes in 2.2 h. OpenViking takes 8.4 h (about 3.8×), Mem0 27.2 h (about 12×), and MemOS 84.5 h (about 38×). The long Mem0 and MemOS builds come from heavy per-item ingest work, while Memorix pays a short project-level construction pass. Storage. Fig. 15 breaks down on-disk size after the build. Memorix uses 0.53 GiB in total, about 1.4× less than OpenViking (0.73 GiB), 2.0× less than Mem0 (1.06 GiB), and 22× less than MemOS (11.8 GiB). MemOS is dominated by intermediate index and metadata (about 10.2 GiB) plus 1.4 GiB of serving memory. Mem0 likewise stores most of its footprint as index metadata. Memorix keeps intermediate state small (0.18 GiB) and materializes 0.22 GiB of serving memory for bound Environments. A light project-level build therefore stays cheap in both time and space.

7

Mem0

Memorix

0.73

1.06

OpenViking

Mem0

0.53

MemOS

Memorix

window or session and call for durable history and recovery outside the model [26]. Other work measures growing time spans on software tasks [40] and stresses ultra-long tool use [49]. A large body of benchmarks targets long-horizon software-engineering tasks [4, 21–23, 86, 90], long terminal workflows [30, 45, 53], research and ML pipelines [14, 48, 54, 71, 76, 82, 87], and office or web settings [3, 35, 44, 84, 85, 89, 91, 93]. These efforts evaluate long-horizon capability. Memorix complements them by representing and reusing the project context such work depends on. Content addressing and functional packages. Prior systems identify each block or file by a hash of its contents, so identical data is kept once and older snapshots stay readable [18, 32, 55, 56, 70, 73]. Git [13], Ori [50], Software Heritage [69], IPFS [77], and OSTree [64] use the same idea for directory trees and history. Nix [24], NixOS [25], and Guix [16] put each package under a path fixed by its build inputs, so many versions can sit side by side and an upgrade only switches which one is active. Memorix builds on these ideas for agent project memory, where generation switching selects which context files a project exposes to later tasks.

Wrong

50

OpenViking

Source Derived Index Copies

Figure 15. On-disk memory footprint. Disk space used by each system’s persistent deployment after the run.

100 75

0.6

0.0

4

0

Torch

Matplotlib

8

11.80

1.2

8

Discussion

Workload generality. Precomputing what a project should read works when that set stays fairly steady. It is a weaker fit when the selection keeps moving, for example in openended search across repositories, or with trajectories that change every turn. Those cases still need runtime lookup, and Memorix leaves that path open. Its memory tree is readable with ordinary file tools, so an agent can browse and search global memory, or look up the intent text attached to a Quest, without first binding anything into the project. The same objects can also carry embeddings or summaries, so familiar retrieval methods can integrate with Memorix. Remote stores and shared memory. The prototype we evaluate keeps memory next to the project on one machine, but a team often wants one shared Store and many local checkouts. Memorix can use a version control system (e.g., Git [33]) to synchronize the Store across machines. Because each file is addressed by content and each view records the hashes of the files it depends on, a checkout can fetch only the sources

Related Work

Long-horizon agents. Long-horizon agent work is attracting broad attention. Surveys frame tasks that cross a context 12

it needs and build the View locally. Objects are immutable, so content from two machines will never conflict. Deletion and retention. Memorix does not reclaim Store objects automatically when no view currently points at them. Package stores can do that because an unused closure is safe to drop; agent memory is different. A file with no live view today may still be needed in the future, for example when a later debug session restores an earlier project binding. So the Store keeps history by default, and removal is an explicit user action. View selection. Binding a project to a View is itself a choice, and the agent can make mistakes. For example, two Views with similar intents can both look right for a task. We argue that this choice is easier to get right than retrieve-at-use. First, it is made over a small set of intents, and the agent can read the Store files behind each candidate View before binding anything. Second, the binding is explicit and recorded, so a wrong choice is visible afterwards, and the record turns the mistake into feedback the agent can act on. Third, correction is cheap. Switching the binding moves the whole project to another precomputed view in one step.

9

[9] Anthropic. 2026. Extend Claude with Skills. Retrieved September 21, 2026 from https://code.claude.com/docs/en/skills [10] Anthropic. 2026. How Claude Remembers Your Project. Retrieved September 14, 2026 from https://code.claude.com/docs/en/memory [11] ByteDance. 2026. OpenViking: The Context Database for AI Agents. Retrieved September 14, 2026 from https://github.com/volcengine/ OpenViking [12] Guillaume Cardoen, Tom Mens, and Alexandre Decan. 16 September 2026. GHAgentFiles: A dataset of coding agent file histories in GitHub repositories. In Proceedings of the 42nd International Conference on Software Maintenance and Evolution (Benevento, Italy). F.R.S.-FNRS - Fonds de la Recherche Scientifique, Institute of Electrical and Electronics Engineers (IEEE). hdl:https://orbi.umons.ac.be/handle/20.500.12907/56423 https://doi. org/10.1109/ICSME67971.2026.00080 This dataset paper has received the Distinguished Paper Award for the Tool Demonstration and Data Showcase Track at the 2026 IEEE International Conference on Software Maintenance and Evolution (ICSME). [13] Scott Chacon and Ben Straub. 2014. Pro Git (2nd ed.). Apress, Berkeley, CA, USA. doi:10.1007/978-1-4842-0076-6 [14] Jun Shern Chan, Neil Chowdhury, Oliver Jaffe, James Aung, Dane Sherburn, Evan Mays, Giulio Starace, Kevin Liu, Leon Maksin, Tejal Patwardhan, Lilian Weng, and Aleksander Mądry. 2025. MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering. arXiv:2410.07095 [cs.CL] https://arxiv.org/abs/2410.07095 [15] Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. In ECAI 2025 - 28th European Conference on Artificial Intelligence, 25-30 October 2025, Bologna, Italy Including 14th Conference on Prestigious Applications of Intelligent Systems (PAIS 2025) (Frontiers in Artificial Intelligence and Applications, Vol. 413), Inês Lynce, Nello Murano, Mauro Vallati, Serena Villata, Federico Chesani, Michela Milano, Andrea Omicini, and Mehdi Dastani (Eds.). IOS Press, Amsterdam, The Netherlands, 2993–3000. doi:10.3233/FAIA251160 [16] Ludovic Courtès. 2013. Functional Package Management with Guix. arXiv:1305.4584 [cs.PL] https://arxiv.org/abs/1305.4584 [17] Cursor. 2026. Rules. Retrieved September 15, 2026 from https://cursor. com/docs/rules [18] Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica. 2001. Wide-area cooperative storage with CFS. SIGOPS Oper. Syst. Rev. 35, 5 (Oct. 2001), 202–215. doi:10.1145/502059.502054 [19] DeepSeek. 2026. Models & Pricing. Retrieved September 17, 2026 from https://api-docs.deepseek.com/quick_start/pricing/ [20] DeepSeek-AI. 2026. DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression. Technical Report. DeepSeek-AI. Retrieved September 17, 2026 from https://huggingface.co/deepseek-ai/DeepSeekV4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf [21] Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Chetan Rane, Karmini Sampath, Maya Krishnan, Srivatsa R Kundurthy, Sean M. Hendryx, Zifan Wang, Chen Bo Calvin Zhang, Noah Jacobson, Bing Liu, and Brad Kenstler. 2026. SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?. In Forty-third International Conference on Machine Learning. https://openreview.net/forum?id=uEVTdoAbnK [22] Rishi Desai, Jesse Hu, Joan Cabezas, Neel Harsola, Pratyush Shukla, Roey Ben Chaim, Adnan El Assadi, Omkaar Mukund Kamath, Fenil Faldu, Prannay Hebbar, Jiankai Sun, Yiyuan Li, Pramod Srinivasan, Ishan Gupta, Christopher Settles, Daniel Wang, Derek Chen, Pranav Raja, Albert Liu, Marek Šuppa, Nevasini Sasikumar, Luyang Kong, Erik Quintanilla, Xiangyi Li, Ivan Bercovich, and Steven Dillmann. 2026. SWE-Marathon: Can Agents Autonomously Complete UltraLong-Horizon Software Work? arXiv:2606.07682 [cs.SE] https://arxiv. org/abs/2606.07682

Conclusion

We present Memorix, an agent memory system that precomputes context selection as a first-class object with stable identity. Guided by the insight that what an agent should read is mostly determined by its project, Memorix replaces use-time assembly with a versioned Store, composable Views, and Quests and Profiles that refresh and bind the delivered View. Hence, this work opens new directions for building shared, durable memory ecosystems for agents.

References [1] Agent Skills. 2026. Agent Skills Overview. Retrieved September 10, 2026 from https://agentskills.io/home [2] Aider. 2026. Edit Formats. Retrieved September 25, 2026 from https: //aider.chat/docs/more/edit-formats.html [3] Anonymous. 2026. ClawMark: A Living-World Benchmark for MultiTurn, Multi-Day, Multimodal Coworker Agents. In Submitted to ACL Rolling Review - May 2026. https://openreview.net/forum?id= qe1ml90zuL under review. [4] Anonymous. 2026. SWE-EVO: Benchmarking Coding Agents in LongHorizon Software Evolution Scenarios. In Submitted to ACL Rolling Review - March 2026. https://openreview.net/forum?id=SCpCfeSLtn under review. [5] Jason Ansel, Kapil Arya, and Gene Cooperman. 2009. DMTCP: Transparent Checkpointing for Cluster Computations and the Desktop. In 2009 IEEE International Symposium on Parallel & Distributed Processing. IEEE, Piscataway, NJ, USA, 1–12. doi:10.1109/IPDPS.2009.5161063 [6] Anthropic. 2025. Effective Harnesses for Long-Running Agents. Retrieved November 26, 2025 from https://www.anthropic.com/ engineering/effective-harnesses-for-long-running-agents [7] Anthropic. 2026. Claude Code Overview. Retrieved May 14, 2026 from https://code.claude.com/docs/en/overview [8] Anthropic. 2026. Claude Cowork. Retrieved August 26, 2026 from https://claude.com/product/cowork 13

[23] Jingzhe Ding, Shengda Long, Changxin PU, Ge Zhang, zhou huan, Hongwan Gao, Xiang Gao, Chao He, Yue Hou, FEI HU, Zhaojian Li, Weiran Shi, Zaiyuan Wang, Daoguang Zan, Chenchen Zhang, Xiaoxu Zhang, Chen Qizhi, Xianfu Cheng, Bo Deng, Qingshui Gu, Kai Hua, Juntao Lin, Pai Liu, Mingchen Li, Minghao Li, Xuanguang Pan, Zifan Peng, Yujia Qin, Yong Shan, Zhewen Tan, Haoran Wang, Zihan Wang, Weihao Xie, Yishuo Yuan, Jiayu Zhang, Yunfei Zhao, He Zhu, LIYA ZHU, Chenyang Zou, Ming Ding, Jianpeng Jiao, Jiaheng Liu, Minghao Liu, Qian Liu, Chongyang Tao, Jian Yang, Tong Yang, Zhaoxiang Zhang, Xinjie Chen, and Wenhao Huang. 2026. NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents. In Forty-third International Conference on Machine Learning. https: //openreview.net/forum?id=wqQam1muOQ [24] Eelco Dolstra and Merijn de Jonge. 2004. Nix: A Safe and Policy-Free System for Software Deployment. In 18th Large Installation System Administration Conference (LISA 04). USENIX Association, Atlanta, GA. https://www.usenix.org/conference/lisa-04/nix-safe-and-policyfree-system-software-deployment [25] Eelco Dolstra and Andres Löh. 2008. NixOS: a purely functional Linux distribution. In Proceedings of the 13th ACM SIGPLAN International Conference on Functional Programming (Victoria, BC, Canada) (ICFP ’08). Association for Computing Machinery, New York, NY, USA, 367–378. doi:10.1145/1411204.1411255 [26] Guanting Dong, Xiaoshuai Song, Yuyang Hu, Jiajie Jin, Chenghao Zhang, Yifei Chen, Xiaoxi Li, Huaying Yuan, Xinyu Yang, Tongyu Wen, Jiejun Tan, Hongjin Qian, Shijue Huang, Junting Lu, Zhenyu Li, Wanjun Zhong, Yutao Zhu, Tat-Seng Chua, Zhicheng Dou, and Ji-Rong Wen. 2026. Towards Long-Horizon Agents: A Survey. Preprints (July 2026). doi:10.20944/preprints202607.1328.v1 [27] Liming Dong, Qinghua Lu, and Liming Zhu. 2024. AgentOps: Enabling Observability of LLM Agents. arXiv:2411.05285 [cs.AI] https://arxiv. org/abs/2411.05285 [28] Yunpeng Dong, Jingkai He, Shiqi Liu, Yuze Hou, Dong Du, Zhonghu Xu, Si Yu, Baochuan Yang, Yubin Xia, and Haibo Chen. 2026. DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback. arXiv:2605.22781 [cs.OS] https://arxiv.org/abs/2605. 22781 [29] George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza A. Basrai, and Peter M. Chen. 2002. ReVirt: Enabling Intrusion Analysis Through Virtual-Machine Logging and Replay. In 5th Symposium on Operating Systems Design and Implementation (OSDI 02). USENIX Association, Boston, MA, 211– 224. https://www.usenix.org/conference/osdi-02/revirt-enablingintrusion-analysis-through-virtual-machine-logging-and-replay [30] Yukang Feng, Jianwen Sun, Zelai Yang, Jiaxin Ai, Chuanhao Li, Zizhen Li, Fanrui Zhang, Kang He, Rui Ma, Jifan Lin, Jie Sun, Yang Xiao, Sizhuo Zhou, Wenxiao Wu, Yiming Liu, Pengfei Liu, Yu Qiao, Shenglin Zhang, and Kaipeng Zhang. 2026. LongCLI-Bench: A Preliminary Benchmark and Study for Long-horizon Agentic Programming in Command-Line Interfaces. arXiv:2602.14337 [cs.SE] https://arxiv.org/abs/2602.14337 [31] Jiajie Fu, Junwen Chen, Mengzhao Wang, Aoxiang He, Maojia Sheng, Xiangyu Ke, Yifan Zhu, and Yunjun Gao. 2026. VikingMem: A Memory Base Management System for Stateful LLM-Based Applications. Proc. VLDB Endow. 19, 12 (Sept. 2026), 4344–4357. doi:10.14778/3827998. 3828037 [32] Kevin Fu, M. Frans Kaashoek, and David Mazières. 2000. Fast and Secure Distributed Read-Only File System. In Fourth Symposium on Operating Systems Design and Implementation (OSDI 2000). USENIX Association, San Diego, CA. https://www.usenix.org/conference/osdi2000/fast-and-secure-distributed-read-only-file-system [33] Git Project. 2026. Git. Retrieved April 16, 2025 from https://gitscm.com/ [34] Google. 2026. Provide Context with GEMINI.md Files. Retrieved September 15, 2026 from https://geminicli.com/docs/cli/gemini-md/

[35] Muyu He, Vincent Tu, Adit Jain, Anand Kumar, Sachin Patro, Soumyadeep Bakshi, and Nazneen Rajani. 2026. YC-Bench: Benchmarking AI Agents for Long-Term Planning and Consistent Execution. In ICML 2026 Workshop on Combining Theory and Benchmarks: Towards A Virtuous Cycle to Understand and Guarantee Foundation Model Performance. https://openreview.net/forum?id=wHPdBWy4xd [36] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. In Proceedings of the Twelfth International Conference on Learning Representations. OpenReview.net, Vienna, Austria. https://openreview.net/forum?id= VTF8yNQM66 [37] Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. 2020. Dense Passage Retrieval for Open-Domain Question Answering. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu (Eds.). Association for Computational Linguistics, Online, 6769–6781. doi:10.18653/v1/2020.emnlp-main.550 [38] Sachit Kuhar, Wasi Uddin Ahmad, Zijian Wang, Nihal Jain, Haifeng Qian, Baishakhi Ray, Murali Krishna Ramanathan, Xiaofei Ma, and Anoop Deoras. 2025. LibEvolutionEval: A Benchmark and Study for Version-Specific Code Generation. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), Luis Chiruzzo, Alan Ritter, and Lu Wang (Eds.). Association for Computational Linguistics, Albuquerque, New Mexico, 6826–6840. doi:10.18653/v1/2025.naacl-long.348 [39] Thomas Kwa, Ben West, Joel Becker, Amy Deng, Katharyn Garcia, Max Hasin, Sami Jawhar, Megan Kinniment, Nate Rush, Sydney Von Arx, Ryan Bloom, Thomas Broadley, Haoxing Du, Brian Goodrich, Nikola Jurkovic, Luke Harold Miles, Seraphina Nix, Tao Lin, Chris Painter, Neev Parikh, David Rein, Lucas Jun Koba Sato, Hjalmar Wijk, Daniel M. Ziegler, Elizabeth Barnes, and Lawrence Chan. 2026. Measuring AI Ability to Complete Long Software Tasks. arXiv:2503.14499 [cs.AI] https://arxiv.org/abs/2503.14499 [40] Thomas Kwa, Ben West, Joel Becker, Amy Deng, Katharyn Garcia, Max Hasin, Sami Jawhar, Megan Kinniment, Nate Rush, Sydney Von Arx, Ryan Bloom, Thomas Broadley, Haoxing Du, Brian Goodrich, Nikola Jurkovic, Luke Harold Miles, Seraphina Nix, Tao Roa Lin, Neev Parikh, David Rein, Lucas Jun Koba Sato, Hjalmar Wijk, Daniel M Ziegler, Elizabeth Barnes, and Lawrence Chan. 2025. Measuring AI Ability to Complete Long Software Tasks. In The Thirty-ninth Annual Conference on Neural Information Processing Systems. https://openreview.net/ forum?id=CGNJL6CeV0 [41] LangChain. 2026. LangGraph Persistence. Retrieved September 14, 2026 from https://docs.langchain.com/oss/python/langgraph/persistence [42] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrievalaugmented generation for knowledge-intensive NLP tasks. In Proceedings of the 34th International Conference on Neural Information Processing Systems (Vancouver, BC, Canada) (NIPS ’20). Curran Associates Inc., Red Hook, NY, USA, Article 793, 16 pages. [43] Hao Li, Haoxiang Zhang, and Ahmed E. Hassan. 2026. AIDev: Studying AI Coding Agents on GitHub. In Proceedings of the 23rd International Conference on Mining Software Repositories (MSR ’26). Association for Computing Machinery, New York, NY, USA, 1029–1033. doi:10.1145/ 3793302.3797249 [44] Junlong Li, Wenshuo Zhao, Jian Zhao, Weihao Zeng, Haoze Wu, Xiaochen Wang, Rui Ge, Yuxuan Cao, Yuzhen Huang, Wei Liu, Junteng Liu, Zhaochen Su, Yiyang Guo, Fan Zhou, Lueyang Zhang, Juan Michelini, Xingyao Wang, Xiang Yue, Shuyan Zhou, Graham Neubig, and Junxian He. 2026. The Tool Decathlon: Benchmarking Language 14

Agents for Diverse, Realistic, and Long-Horizon Task Execution. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=z53s5p0qhf [45] Zongxia Li, Zhongzhi Li, Yucheng Shi, Ruhan Wang, Junyao Yang, Zhichao Liu, Xiyang Wu, Anhao Li, Yue Yu, Ninghao Liu, Lichao Sun, Haotao Mi, and Leowei Liang. 2026. Long-Horizon-TerminalBench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading. arXiv:2607.08964 [cs.AI] https: //arxiv.org/abs/2607.08964 [46] Zhiyu Li, Chenyang Xi, Chunyu Li, Ding Chen, Boyu Chen, Shichao Song, Simin Niu, Hanyu Wang, Jiawei Yang, Chen Tang, Qingchen Yu, Jihao Zhao, Yezhaohui Wang, Peng Liu, Zehao Lin, Pengyuan Wang, Jiahao Huo, Tianyi Chen, Kai Chen, Kehang Li, Zhen Tao, Huayi Lai, Hao Wu, Bo Tang, Zhengren Wang, Zhaoxin Fan, Ningyu Zhang, Linfeng Zhang, Junchi Yan, Mingchuan Yang, Tong Xu, Wei Xu, Huajun Chen, Haofen Wang, Hongkang Yang, Wentao Zhang, Zhi-Qin John Xu, Siheng Chen, and Feiyu Xiong. 2025. MemOS: A Memory OS for AI System. arXiv:2507.03724 [cs.CL] doi:10.48550/arXiv.2507.03724 [47] Yucheng Low, Rajat Arya, Ajit Banerjee, Ann Huang, Brian Ronan, Hoyt Koepke, Joseph Godlewski, and Zach Nation. 2023. Git Is for Data. In Proceedings of the 13th Annual Conference on Innovative Data Systems Research (CIDR ’23). www.cidrdb.org, Amsterdam, The Netherlands, 9 pages. https://www.vldb.org/cidrdb/papers/2023/p43-low.pdf [48] Chris Lu, Cong Lu, Robert Tjarko Lange, Jakob Foerster, Jeff Clune, and David Ha. 2024. The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. arXiv:2408.06292 [cs.AI] https: //arxiv.org/abs/2408.06292 [49] Haotian Luo, Huaisong Zhang, Xuelin Zhang, Haoyu Wang, Zeyu Qin, WenJie Lu, Guozheng Ma, Haiying He, Yingsha Xie, Qiyang Zhou, Zixuan Hu, Hongze Mi, Yibo Wang, Naiqiang Tan, Hong Chen, Yi R. Fung, Chun Yuan, and Li Shen. 2026. UltraHorizon: Benchmarking LLM-Agent Capabilities in Ultra Long-Horizon Scenarios. https: //openreview.net/forum?id=FTZfVHWAIq [50] Ali José Mashtizadeh, Andrea Bittau, Yifeng Frank Huang, and David Mazières. 2013. Replication, history, and grafting in the Ori file system. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles (Farminton, Pennsylvania) (SOSP ’13). Association for Computing Machinery, New York, NY, USA, 151–166. doi:10.1145/ 2517349.2522721 [51] Mem0. 2026. Open Source Overview. Retrieved September 17, 2026 from https://docs.mem0.ai/open-source/overview [52] Ralph C. Merkle. 1987. A Digital Signature Based on a Conventional Encryption Function. In A Conference on the Theory and Applications of Cryptographic Techniques on Advances in Cryptology (CRYPTO ’87). Springer-Verlag, Berlin, Heidelberg, 369–378. [53] Mike A Merrill, Alexander Glenn Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich, Lin Shi, Jeong Yeon Shin, Thomas Walshe, E. Kelly Buchanan, Junhong Shen, Guanghao Ye, Haowei Lin, Jason Poulos, Maoyu Wang, Marianna Nezhurina, Di Lu, Orfeas Menis Mastromichalakis, Zhiwei Xu, Zizhao Chen, Yue Liu, Robert Zhang, Leon Liangyu Chen, Anurag Kashyap, Jan-Lucas Uslu, Jeffrey Li, Jianbo Wu, Minghao Yan, Song Bian, Vedang Sharma, Ke Sun, Steven Dillmann, Akshay Anand, Andrew Lanpouthakoun, Bardia Koopah, Changran Hu, Etash Kumar Guha, Gabriel H. S. Dreiman, Jiacheng Zhu, Karl Krauth, Li Zhong, Niklas Muennighoff, Robert Kwesi Amanfu, Shangyin Tan, Shreyas Pimpalgaonkar, Tushar Aggarwal, Xiangning Lin, Xin Lan, Xuandong Zhao, Yiqing Liang, Yuanli Wang, Zilong Wang, Changzhi Zhou, David Heineman, Hange Liu, Harsh Trivedi, John Yang, Junhong Lin, Manish Shetty, Michael Yang, Nabil Omi, Negin Raoof, Shanda Li, Terry Yue Zhuo, Wuwei Lin, Yiwei Dai, Yuxin Wang, Wenhao Chai, Shang Zhou, Dariush Wahdany, Ziyu She, Jiaming Hu, Zhikang Dong, Yuxuan Zhu, Sasha Cui, Ahson Saiyed, Arinbjörn Kolbeinsson, Christopher Michael Rytting,

Ryan Marten, Yixin Wang, Jenia Jitsev, Alex Dimakis, Andy Konwinski, and Ludwig Schmidt. 2026. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=a7Qa4CcHak [54] Ludovico Mitchener, Angela Yiu, Benjamin Chang, Mathieu Bourdenx, Tyler Nadolski, Arvis Sulovari, Eric C. Landsness, Daniel L. Barabasi, Siddharth Narayanan, Nicky Evans, Shriya Reddy, Martha Foiani, Aizad Kamal, Leah P. Shriver, Fang Cao, Asmamaw T. Wassie, Jon M. Laurent, Edwin Melville-Green, Mayk Caldas, Albert Bou, Kaleigh F. Roberts, Sladjana Zagorac, Timothy C. Orr, Miranda E. Orr, Kevin J. Zwezdaryk, Ali E. Ghareeb, Laurie McCoy, Bruna Gomes, Euan A. Ashley, Karen E. Duff, Tonio Buonassisi, Tom Rainforth, Randall J. Bateman, Michael Skarlinski, Samuel G. Rodriques, Michaela M. Hinks, and Andrew D. White. 2025. Kosmos: An AI Scientist for Autonomous Discovery. arXiv:2511.02824 [cs.AI] https://arxiv.org/abs/2511.02824 [55] Athicha Muthitacharoen, Benjie Chen, and David Mazières. 2001. A low-bandwidth network file system. SIGOPS Oper. Syst. Rev. 35, 5 (Oct. 2001), 174–187. doi:10.1145/502059.502052 [56] Partho Nath, Michael A. Kozuch, David R. O’Hallaron, Jan Harkes, M. Satyanarayanan, Niraj Tolia, and Matt Toups. 2006. Design tradeoffs in applying content addressable storage to enterprise-scale systems based on virtual machines. In Proceedings of the Annual Conference on USENIX ’06 Annual Technical Conference (Boston, MA) (ATEC ’06). USENIX Association, USA, 6. [57] Nous Research. 2026. Hermes Agent. Retrieved August 26, 2026 from https://hermes-agent.nousresearch.com/ [58] Robert O’Callahan, Chris Jones, Nathan Froyd, Kyle Huey, Albert Noll, and Nimrod Partush. 2017. Engineering Record and Replay for Deployability. In 2017 USENIX Annual Technical Conference (USENIX ATC 17). USENIX Association, Santa Clara, CA, 377–389. https://www.usenix. org/conference/atc17/technical-sessions/presentation/ocallahan [59] OpenAI. 2025. Introducing Codex. Retrieved May 16, 2025 from https://openai.com/index/introducing-codex/ [60] OpenAI. 2026. Build Skills. Retrieved September 21, 2026 from https: //learn.chatgpt.com/docs/build-skills [61] OpenAI. 2026. Custom Instructions with AGENTS.md. Retrieved September 14, 2026 from https://learn.chatgpt.com/docs/agentconfiguration/agents-md [62] OpenAI. 2026. text-embedding-3-large Model. Retrieved September 17, 2026 from https://developers.openai.com/api/docs/models/textembedding-3-large [63] OpenClaw. 2026. OpenClaw. Retrieved January 29, 2026 from https: //openclaw.ai/ [64] OSTree. 2026. Anatomy of an OSTree repository. Retrieved September 21, 2026 from https://ostreedev.github.io/ostree/repo/ [65] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. 2023. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560 [cs.AI] [66] Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. 2023. Generative Agents: Interactive Simulacra of Human Behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (San Francisco, CA, USA) (UIST ’23). Association for Computing Machinery, New York, NY, USA, Article 2, 22 pages. doi:10.1145/3586183.3606763 [67] Pi. 2026. Pi Coding Agent. Retrieved August 24, 2026 from https: //pi.dev/ [68] Antoine Pietri, Diomidis Spinellis, and Stefano Zacchiroli. 2019. The software heritage graph dataset: public software development under one roof. In Proceedings of the 16th International Conference on Mining Software Repositories (Montreal, Quebec, Canada) (MSR ’19). IEEE Press, Piscataway, NJ, USA, 138–142. doi:10.1109/MSR.2019.00030

15

[69] Antoine Pietri, Diomidis Spinellis, and Stefano Zacchiroli. 2020. The Software Heritage Graph Dataset: Large-scale Analysis of Public Software Development History. In Proceedings of the 17th International Conference on Mining Software Repositories (Seoul, Republic of Korea) (MSR ’20). Association for Computing Machinery, New York, NY, USA, 1–5. doi:10.1145/3379597.3387510 [70] Sean Quinlan and Sean Dorward. 2002. Venti: A New Approach to Archival Data Storage. In Conference on File and Storage Technologies (FAST 02). USENIX Association, Monterey, CA. https://www.usenix. org/conference/fast-02/venti-new-approach-archival-data-storage [71] Ben Rank, Hardik Bhatnagar, Ameya Prabhu, Shira Eisenberg, Karina Nguyen, Matthias Bethge, and Maksym Andriushchenko. 2026. PostTrainBench: Can LLM Agents Automate LLM Post-Training? arXiv:2603.08640 [cs.SE] https://arxiv.org/abs/2603.08640 [72] Read the Docs. 2026. Versions. Retrieved September 14, 2026 from https://docs.readthedocs.com/platform/latest/versions.html [73] Sean Rhea, Russ Cox, and Alex Pesterev. 2008. Fast, inexpensive content-addressed storage in foundation. In USENIX 2008 Annual Technical Conference (Boston, Massachusetts) (ATC’08). USENIX Association, USA, 143–156. [74] Romain Robbes, Théo Matricon, Thomas Degueule, Andre Hora, and Stefano Zacchiroli. 2026. Agentic Much? Adoption of Coding Agents on GitHub. arXiv:2601.18341 [cs.SE] https://arxiv.org/abs/2601.18341 [75] Parth Sarthi, Salman Abdullah, Aditi Tuli, Shubh Khanna, Anna Goldie, and Christopher Manning. 2024. RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. In International Conference on Learning Representations, B. Kim, Y. Yue, S. Chaudhuri, K. Fragkiadaki, M. Khan, and Y. Sun (Eds.), Vol. 2024. ICLR, Vienna, Austria, 32628–32649. https://proceedings.iclr.cc/paper_files/paper/2024/file/ 8a2acd174940dbca361a6398a4f9df91-Paper-Conference.pdf [76] Giulio Starace, Oliver Jaffe, Dane Sherburn, James Aung, Jun Shern Chan, Leon Maksin, Rachel Dias, Evan Mays, Benjamin Kinsella, Wyatt Thompson, Johannes Heidecke, Amelia Glaese, and Tejal Patwardhan. 2025. PaperBench: Evaluating AI’s Ability to Replicate AI Research. In Proceedings of the 42nd International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 267), Aarti Singh, Maryam Fazel, Daniel Hsu, Simon Lacoste-Julien, Felix Berkenkamp, Tegan Maharaj, Kiri Wagstaff, and Jerry Zhu (Eds.). PMLR, 56843– 56873. https://proceedings.mlr.press/v267/starace25a.html [77] Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ignacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, and Yiannis Psaras. 2022. Design and evaluation of IPFS: a storage layer for the decentralized web. In Proceedings of the ACM SIGCOMM 2022 Conference (Amsterdam, Netherlands) (SIGCOMM ’22). Association for Computing Machinery, New York, NY, USA, 739–752. doi:10.1145/3544216.3544232 [78] Aristidis Vasilopoulos. 2026. Codified Context: Infrastructure for AI Agents in a Complex Codebase. arXiv:2602.20478 [cs.SE] https://arxiv. org/abs/2602.20478 [79] Jianguo Wang, Xiaomeng Yi, Rentong Guo, Hai Jin, Peng Xu, Shengjun Li, Xiangyu Wang, Xiangzhou Guo, Chengming Li, Xiaohai Xu, Kun Yu, Yuxing Yuan, Yinghao Zou, Jiquan Long, Yudong Cai, Zhenxiang Li, Zhifeng Zhang, Yihua Mo, Jun Gu, Ruiyi Jiang, Yi Wei, and Charles Xie. 2021. Milvus: A Purpose-Built Vector Data Management System. In Proceedings of the 2021 International Conference on Management of Data (Virtual Event, China) (SIGMOD ’21). Association for Computing Machinery, New York, NY, USA, 2614–2627. doi:10.1145/3448016.3457550 [80] Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Daniel Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. 2025. OpenHands: An Open Platform for AI Software Developers as Generalist Agents. In International Conference on Learning Representations, Y. Yue, A. Garg, N. Peng, F. Sha, and R. Yu (Eds.), Vol. 2025. ICLR, Singapore,

65882–65919. https://proceedings.iclr.cc/paper_files/paper/2025/file/ a4b6ad6b48850c0c331d1259fc66a69c-Paper-Conference.pdf [81] Miku Watanabe, Hao Li, Yutaro Kashiwa, Brittany Reid, Hajimu Iida, and Ahmed E. Hassan. 2026. On the Use of Agentic Coding: An Empirical Study of Pull Requests on GitHub. arXiv:2509.14745 [cs.SE] https://arxiv.org/abs/2509.14745 [82] Hjalmar Wijk, Tao Roa Lin, Joel Becker, Sami Jawhar, Neev Parikh, Thomas Broadley, Lawrence Chan, Michael Chen, Joshua M Clymer, Jai Dhyani, Elena Ericheva, Katharyn Garcia, Brian Goodrich, Nikola Jurkovic, Megan Kinniment, Aron Lajko, Seraphina Nix, Lucas Jun Koba Sato, William Saunders, Maksym Taran, Ben West, and Elizabeth Barnes. 2025. RE-Bench: Evaluating Frontier AI R&D Capabilities of Language Model Agents against Human Experts. In Forty-second International Conference on Machine Learning. https: //openreview.net/forum?id=3rB0bVU6z6 [83] WorkBuddy. 2026. WorkBuddy. Retrieved August 26, 2026 from https://www.workbuddy.ai/ [84] Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. 2024. OSWORLD: benchmarking multimodal agents for open-ended tasks in real computer environments. In Proceedings of the 38th International Conference on Neural Information Processing Systems (Vancouver, BC, Canada) (NIPS ’24). Curran Associates Inc., Red Hook, NY, USA, Article 1650, 55 pages. [85] Frank (Fangzheng) Xu, Yufan Song, Boxuan Li, Yuxuan Tang, Kritanjali Jain, Mengxue Bao, Zora Wang, Xuhui Zhou, Zhitong Guo, Murong Cao, Mingyang Yang, Hao Yang Lu, Amaad Martin, Zhe Su, Leander Maben, Raj Mehta, Wayne Chi, Lawrence Jang, Yiqing Xie, Shuyan Zhou, and Graham Neubig. 2025. TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks. In Advances in Neural Information Processing Systems, D. Belgrave, C. Zhang, H. Lin, R. Pascanu, P. Koniusz, M. Ghassemi, and N. Chen (Eds.), Vol. 38, Main Conference. Curran Associates, Inc. doi:10.52202/085713-0315 [86] Xinbo Xu, Ruihan Yang, Haiyang Shen, Wendong Xu, Bofei Gao, Ruoyu Wu, Kean Shi, Weichu Xie, Xuanzhong Chen, Ming Wu, Jason Zeng, Michael Heinrich, Elvis Zhang, Liang Chen, Kuan Li, and Baobao Chang. 2026. RoadmapBench: Evaluating Long-Horizon Agentic Software Development Across Version Upgrades. arXiv:2605.15846 [cs.SE] https://arxiv.org/abs/2605.15846 [87] Yutaro Yamada, Robert Tjarko Lange, Cong Lu, Shengran Hu, Chris Lu, Jakob Foerster, Jeff Clune, and David Ha. 2025. The AI Scientistv2: Workshop-Level Automated Scientific Discovery via Agentic Tree Search. arXiv:2504.08066 [cs.AI] https://arxiv.org/abs/2504.08066 [88] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629 [cs.CL] https: //arxiv.org/abs/2210.03629 [89] Ori Yoran, Samuel Joseph Amouyal, Chaitanya Malaviya, Ben Bogin, Ofir Press, and Jonathan Berant. 2024. AssistantBench: Can Web Agents Solve Realistic and Time-Consuming Tasks? arXiv:2407.15711 [cs.CL] https://arxiv.org/abs/2407.15711 [90] Wenting Zhao, Nan Jiang, Celine Lee, Justin T Chiu, Claire Cardie, Matthias Gallé, and Alexander M Rush. 2025. Commit0: Library Generation from Scratch. In The Thirteenth International Conference on Learning Representations. https://openreview.net/forum?id=MMwaQEVsAg [91] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. 2024. WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv:2307.13854 [cs.AI] https://arxiv.org/abs/2307.13854 [92] Jiayuan Zhu, Junde Wu, Minhao Hu, Shengda Zhu, Jiazhen Pan, Weixiang Shen, Yijun Yang, Fenglin Liu, Jianye Hao, Yueming Jin,

16

Qirong Ho, and Min Xu. 2026. SWE Context Bench: A Benchmark for Context Learning in Coding. arXiv:2602.08316 [cs.SE] https://arxiv.org/abs/2602.08316 [93] Liya Zhu, Jingzhe Ding, Jian Zhang, Jianbo Xue, Shihao Liang, Ge Zhang, Yi Zhu, Duju Zeng, Xiang Gao, Qingshui Gu, Mailun Gao, Huimin Che, Yan Zhao, Peiheng Zhou, Haojun Wang, Chaobo Xian, Lili Le, Chi Wu, Yiwei Liu, Shengda Long, Jiale Yang, Fangzhi Xu, Sijin Wu, Haodong Duan, Chao He, Zhaojian Li, Minchao Wang, Huan Zhou, Jiani Hou, Chuqian Yu, Weiran Shi, Hongwan Gao, Jiamin Chen, Guanhong Chen, Tingqin Luo, Kaiyuan Zhang, Zhixin Yao, Qing Hua, Yuhao Jiang, Jin Chen, Pu Chen, Zhenyu Hu, Xingyu Li, Zhengxuan Jiang, Meng Cao, Tianfeng Long, Haozhe Wang, Mingzhang Wang, Yichen Zhang, Yiming Dai, Chenchen Zhang, Jiaying Wang, Xinying Liu, Xingzu Liu, Lingling Zhang, Xinjie Chen, Yujia Qin, Wangchunshu Zhou, Zhiyong Wu, Yang Liu, Jiaheng Liu, Lei Zhang, Shen Yan, Wenhao Huang, Zaiyuan Wang, and Xiaolong Chang. 2026. WorkflowGYM: Towards Long-Horizon Evaluation of Computer-use Agentic tasks in Real-World Professional Fields. arXiv:2606.11042 [cs.AI] https://arxiv.org/abs/2606.11042

17

Related documents

• Remembering Is Not Enough: Refining Memories and Learning When to Use Them in Multi-Agent Systems#1467976
• Memorix: Managing Memory Selections for AI Agents#1535615
• Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads#1062655
• Just-in-Time Memory: Learning to Curate Task-Adaptive Memory for LLM Agents#1063545
• MemCo: Memory-Centric Collaboration for Generalizing LLM Agents to Unseen Environments#1216751