A Survey on the Memory Mechanism of Large Language Model based Agents

In plain words

An agent is a model that acts over many steps, so it needs a memory: something that stores what happened, tidies it up, and brings the right piece back when the next decision is made. This survey gathers the many memory designs that have been published for such agents and sorts them into a few questions. Where does the memory come from? Is it stored as text the model can read, or built into the model's weights? What happens to it while the agent runs? It also asks how to test whether a memory works, and it lists the kinds of agent (role-play, personal assistants, games, coding, and others) where memory matters. It is a map of the field, not a new method.

TL;DR

• A survey of memory mechanisms for LLM-based agents. Memory is defined as three operations: writing, management and reading §3.4.
• Memory sources are inside-trial history, cross-trial experience and external knowledge; memory forms are textual or parametric §5.1 §5.2.
• Evaluation is split into direct tests of the memory and indirect tests through agent tasks §6.
• It runs no experiments. Its tables classify 28 systems, and the paper notes that no open benchmark targets agent memory alone §6.3.

Problem

Without memory an agent does not know the context of its current task. The paper gives conversation and role-play as cases where the agent drifts or loses the thread without memory §4.3. Two costs appear when all history is simply placed in the prompt. Attention cost grows with the square of the sequence length, and a memory longer than the pretraining context must be cut, which loses information. The paper also cites evidence that the position of a passage inside a long context changes how well it is used §5.2.1. Parametric memory avoids the prompt length, but fine-tuning on agent data risks catastrophic forgetting and is costly to repeat at every step §5.2.2. The survey assumes that agents act in a loop with an environment §3.1, and its unified function treats the LLM as a fixed function that maps memory and context to the next action §3.4.

Method

This is a survey, so the "method" is the framework the paper proposes for organising memory designs.

Definitions. A task is a goal the agent must reach. A trial is one complete agent-environment interaction for a task. A step is one action and the environment's response within a trial §3.1. The paper gives two definitions of agent memory:

1. Narrow: the memory depends only on the history of the current trial, so it is emptied when the trial ends §3.2.
2. Broad: the memory can also draw on earlier trials, on earlier tasks and on external knowledge §3.3.

Three operations. Each stored item passes through three functions §3.4.

1. Writing W turns the latest action and observation into a stored memory item. The item can be natural language or parameters §3.4.
2. Management P updates the existing memory with the new item. The paper lists merging similar items, reflecting to form higher-level items and forgetting unimportant ones as examples §3.4 §5.3.2.
3. Reading R selects what is needed for the next action, using the context of that action. The paper says it is usually a similarity computation §3.4 §5.3.3.

The paper combines the three into one function that gives the next action from the previous memory, the latest action and observation, and the next context §3.4, unnumbered equation. It notes that other designs fit this form with different choices. For example, one design makes reading and management identity functions and applies management only at the end of a trial. Another reads by combining similarity, time and importance [§3.4, remark].

# Memory-assisted agent step  [§3.4]
# Input:  memory M; latest action and observation; next context
# Output: next action

def agent_step(memory, action, observation, next_context):
    # Write: turn the raw interaction into a stored item  [§3.4]
    stored_item = write(action, observation)
    # Manage: merge, reflect or forget over the existing memory  [§3.4]
    memory = manage(memory, stored_item)
    # Read: select the entries relevant to the next context  [§3.4]
    recalled = read(memory, next_context)
    # Act: the fixed LLM conditions on the recalled memory  [§3.4]
    next_action = llm(recalled, next_context)
    return memory, next_action

Sources (§5.1, tab. 1). The paper counts for each system whether it uses inside-trial information, cross-trial information, or external knowledge. Inside-trial history is used by almost all listed works, but it cannot accumulate knowledge across tasks §5.1.1. Cross-trial information holds successful and failed attempts and the lessons drawn from them. Reflexion is the main example and Retroformer trains the reflection model §5.1.2. External knowledge covers Wikipedia, game wikis, APIs and databases. It gives knowledge the agent could not gather by itself, and an API call can reduce outdated knowledge §5.1.3.

Forms (§5.2, tab. 2). Textual memory keeps natural language or structured records (tuples, database rows). The paper splits it into four types: complete history, recent history, retrieved history and external knowledge §5.2.1. The sub-types are:

• Complete: all history is concatenated into the prompt. This is simple, but the cost grows with length §5.2.1.
• Recent: only the last few steps or a time window are kept, following the principle of locality §5.2.1.
• Retrieved: entries are embedded when written, scored against the current query when read, and the top-K are used §5.2.1.

# Retrieved textual memory  [§5.2.1]
# Input:  entries (text, embedding); query; K (not stated in the paper)
# Output: the K entries with the highest matching scores

def retrieve(entries, query, k):
    # Embed the current query once  [§5.2.1]
    query_vector = embed(query)
    # Score each stored entry against it  [§5.2.1]
    scores = [similarity(query_vector, e.vector) for e in entries]
    # Keep the top-K entries  [§5.2.1]
    return top_k(entries, scores, k)

The paper does not fix the similarity function. Generative Agents uses cosine similarity together with recency and importance, and MemoryBank uses a dual-tower dense retriever with FAISS indexing §5.2.1.

Parametric memory stores information in weights. It has two sub-types. Fine-tuning injects domain knowledge with supervised training, often with LoRA §5.2.2. Editing changes only the facts that need updating and leaves other knowledge unchanged; the paper lists MAC, MEND, KnowledgeEditor and others §5.2.2. The paper compares the two forms: textual memory is more interpretable and cheaper to write, while parametric memory is cheaper to read because it adds nothing to the prompt §5.2.3.

Operations (§5.3, tab. 3). Writing may store raw observations or summaries. Examples are TiM's entity relations in a database and MemoChat's topic keys §5.3.1. Management includes merging, reflection and forgetting. Examples are MemoryBank's daily summaries and Generative Agents' reflection, which runs when enough events have accumulated §5.3.2. Reading uses SQL in ChatDB and top-K examples in ExpeL §5.3.3.

Evaluation (§6). Direct evaluation tests the memory alone. Subjective tests ask human judges about coherence (is the recalled memory suited to the context) and rationality (is it reasonable) §6.1.1. Objective tests use the following measures §6.1.2:

• Result correctness: the share of questions answered correctly from memory. It is the mean of an indicator that the answer matches the ground truth §6.1.2, unnumbered equation.
• Reference accuracy: the F1 score of the retrieved memory against the memory that should have been used. Precision is TP/(TP+FP) and recall is TP/(TP+FN) §6.1.2, unnumbered equations.
• Time and hardware cost: the mean time per memory operation, and the peak GPU memory allocation §6.1.2.

Indirect evaluation measures the agent's task result. The paper lists conversation (consistency and engagement), multi-source question answering, long-context tasks and other task success rates or exploration measures. It recommends ablations with and without memory §6.2.

Applications (§7, tab. 4). The table groups listed systems into nine areas: role-playing, social simulation, personal assistants, games, code generation, recommendation, medicine, finance and science tab. 4. For each area the text lists the memory roles. In role-play, memory keeps the character consistent. Personal assistants retrieve earlier dialogue. Games store successful trajectories. Coding agents store compiler errors and past conversations §7.1–§7.4.

Hyperparameters

The survey trains and runs nothing, so it states no training values. The table lists the parameters that an implementer of these designs must choose, with what the paper says about them.

Results

Survey: no experiments and no new measurements. The paper's content is classification and discussion, so there are no headline numbers to compare. The figures below count entries in the paper's own tables.

The author-reported claim that this is the first survey on agent memory is stated in the introduction §1. It was not checked against other surveys.

Paper vs code

No official code. The abstract links a repository (github.com/nuster1128/LLM_Agent_Memory_Survey) that its authors create to follow advances in the field. It is a literature list, not an implementation, so it was not cloned and is not recorded as code. The paper contains no code.

Pitfalls

• Read the tables as the authors' classification. The paper does not say how a system was judged to use or lack an element. A "✗" in tab. 1 and tab. 2 means the paper does not show that element, which is weaker than "absent".
• In tab. 3, "○" means the system has no special design for that operation, while "✗" means the paper does not discuss it. The two differ in meaning.
• Most equations in the paper are unnumbered. This card cites them by section §3.4 §6.1.2, not by equation number.
• The unified formula §3.4 applies reading at the next context, but the text does not say when the reading must run relative to management. Choose the order explicitly when you implement it.
• The timing formula for average operation time §6.1.2 has no parentheses around the difference, so it reads as an average of differences. Taken literally, the average of (end minus start) over M operations is the intended measure.
• The paper says textual memory is more efficient to write and parametric memory to read §5.2.3. It gives no measurements, so treat that as the authors' reasoning, not a measured result.
• Long textual memory has a quadratic attention cost, and the paper's position-bias evidence comes from other work it cites §5.2.1. Neither is measured here.
• The survey defines external knowledge as memory from outside the agent loop §3.3. Textual memory also stores some outside knowledge §5.2.1, so the split between "textual" and "external" is by source, not by storage form.
• Many of the 28 systems are cited for claims that were not checked in this card. Verify any single system against its own paper before relying on it.

Lineage

• Builds on: not stated. The survey's frame draws on the systems it tabulates in §5 and tab. 1–3.
• Compared against: other LLM and LLM-agent surveys, reviewed in the related surveys section §2. That section was not read in detail for this card.
• Superseded by: not stated in this card.