REM Memory Framework Boosts Code Agent Reuse and Cuts Costs

Large‑language‑model (LLM) coding agents can now run through hundreds of think‑act cycles to solve repository‑scale problems, yet the knowledge they generate is seldom reused. A paper released on arXiv titled REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents proposes a three‑step lifecycle that changes that dynamic.

---

What problem does REM address?

Current memory systems for autonomous agents focus almost exclusively on retrieval: given a new task, the system searches a database of past trajectories and returns the most similar one. Retrieval alone cannot observe the agent’s internal state, so it cannot decide if the agent actually needs a past experience, when during the run it would be helpful, or how long the information should remain available. As a result, even when a relevant trajectory exists, the agent may ignore it, or the retrieval cost may outweigh the benefit. The authors of the REM framework argue that the bottleneck is not how well we can fetch old runs, but how we store, gate, and evict those experiences within the agent’s own decision loop.

---

How does REM decide what to store?

After an agent finishes a task, REM consolidates the raw think‑act trace into a phase‑structured document. The document groups steps into logical phases (e.g., "setup", "search", "apply patch") and drops low‑level token details, resulting in a representation roughly 100× smaller than the original trajectory. This compact form preserves the high‑level reasoning while keeping storage and transmission costs low. By summarising rather than archiving the full trace, REM makes it feasible to keep many experiences in memory without overwhelming the system.

---

When does REM recall stored experience?

Recall happens in two stages. First, the phase‑structured summary is injected at the start of a new task, giving the agent a quick overview of a potentially relevant prior run. The more detailed implementation record—the part that still contains fine‑grained actions—is kept hidden until an in‑loop gate detects that the agent is struggling (e.g., repeated failed attempts or a stall signal). At that moment, the full record is revealed, allowing the agent to copy‑paste or adapt exact commands that succeeded before. This conditional recall prevents unnecessary overhead while still providing deep assistance when it matters most.

---

What does REM forget and why?

After a single exposure to the implementation record, REM evicts it from the active memory. The rationale is that the agent has already extracted the useful pattern; keeping the record longer offers diminishing returns and consumes precious context windows. The phase summary remains for future tasks, acting as a lightweight index of the experience. This “forget after one use” policy aligns with control‑theoretic ideas: the system treats memory as a bounded resource that must be refreshed based on performance signals.

---

Performance results and implications

The authors evaluated REM on the SWE‑ContextBench Lite benchmark, which measures repository‑level bug fixing. Compared with the strongest existing memory baselines, REM achieved a match@1 of 68.7 % versus 55.6 % for the next best system. End‑task resolution improved from 24.9 % to 27.6 %, and the overall compute cost dropped by 17 %. Notably, feeding the same experience as a plain summary or as a raw trajectory— even when selected by an oracle retriever—did not reproduce the gains. Ablation studies showed that removing any of the three decisions (what to store, when to recall, what to forget) reduced both accuracy and efficiency, confirming that the full lifecycle is essential.

These findings suggest a shift in how we think about continual learning for AI agents: rather than building ever‑larger retrieval indexes, we should design governed memory that interacts with the agent’s control loop. The approach could be extended beyond coding to domains such as data cleaning, prompt engineering, or even multi‑modal creative pipelines.

---

How this applies to Grafy

Grafy’s Code studio (/code) already lets developers run LLM‑powered coding sessions, execute code, and iterate on prompts. By integrating REM‑style memory, a Grafy Code workspace could automatically summarise each completed coding run into a phase‑structured note attached to the project. When a developer starts a new task, the system would preload the relevant summary and, if the AI stalls, surface the detailed command history for one‑click reuse. This would make long‑running bug‑fix or feature‑addition sessions more efficient and reduce redundant API calls. Users interested in experimenting with REM concepts can also load the original paper into Reader (/reader) to explore the methodology, then prototype a lightweight version of the framework inside Grafy Code using the built‑in model routing and prompt chaining capabilities.

---

Frequently asked questions

How is REM different from traditional retrieval‑augmented generation?

REM goes beyond fetching the "most similar" past run. It formats experiences into compact phase summaries, injects them at task start, and only reveals detailed actions when the agent signals difficulty, followed by a single‑use eviction policy. This dynamic gating reduces latency and context usage compared with static retrieval.

Can I use REM with any LLM model in Grafy?

The paper demonstrates REM with a range of open‑source and commercial LLMs accessed through standard APIs. In Grafy, the same pattern can be applied regardless of the underlying model because the memory handling happens at the orchestration layer, not inside the model itself.

What are the practical steps to try REM‑like memory in my own projects?

1. After each coding session, export the think‑act log and compress it into phase groups (e.g., using simple heading markers).
2. Store the summary in a project‑level note (Grafy Files or Code workspace).
3. At the start of a new session, prepend the summary to the prompt.
4. Monitor for repeated failures; when detected, append the full log for one‑shot reuse, then discard it.

---

---

Source: arXiv AI — REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents