---
title: 'Text2Mem: Textual Memory Operations'
url: https://www.emergentmind.com/topics/text2mem
type: topic
---

# Text2Mem: Textual Memory Operations

Searching arXiv for the cited Text2Mem-related papers to ground the article in current records.
Text2Mem refers to systems that map textual descriptions of changes into explicit memory operations, and related work uses the term more broadly for mechanisms that read a context once, convert it into a compact memory state, and answer later queries from that state without re-accessing the original context [2606.24040][2603.13875]. In current arXiv literature, the label spans several technical families: explicit associative memories whose core state is writable and forgettable, optimization-based memory writers that adapt a compact state at test time, prompt-to-parameter adaptation schemes that treat a prompt as transient training data, application-layer episodic and semantic memory stacks for conversational or agent systems, and standardized languages for memory control across heterogeneous backends [2502.12851][2406.16069][2605.20724][2509.11145].

## 1. Scope, precursors, and historical development

Several earlier architectures already instantiate the central Text2Mem pattern: text is transformed into a memory substrate that is later read during generation. In neural machine translation, MemDec augments the decoder with a fixed-size external memory matrix \(M_t^b \in \mathbb{R}^{n \times m}\), read and written once at each decoding step with content-based addressing, and improves Chinese–English translation by \(4.8\) BLEU upon Groundhog and \(5.3\) BLEU upon Moses [1606.02003]. In long-document summarization, Mem2Mem introduces readable and writable external memories on both encoder and decoder sides, compresses an input article into a compact set of sentence representations, performs implicit extraction without labels, and attains results competitive with transformer-based summarization methods while using 16 times fewer parameters [2010.11322].

The same pattern extends beyond pure text. VX2TEXT converts video, audio, speech, and text into language-space embeddings by modality-specific tokenizers, performs multimodal fusion in the language space, and generates open-ended text with a transformer encoder–decoder, outperforming prior methods on captioning, question answering, and audio-visual scene-aware dialog [2101.12059]. A plausible implication is that Text2Mem is not restricted to textual inputs alone; it also covers pipelines in which non-textual signals are first rendered into language-like memory representations before retrieval or generation.

More recent work makes the memory interpretation explicit. MeMo proposes language models with explicit multi-layer correlation matrix memories (CMMs), FastMem performs “fast memorization of the prompt” by updating only the last FFN module before inference, GradMem writes long contexts into a fixed set of prefix memory tokens by test-time gradient descent, CALMem implements a dual memory outside the model, Metis structures agent experience into text and code memory, and Text2Mem itself is formalized as a memory operation language in a backend-agnostic control plane [2502.12851][2406.16069][2603.13875][2605.20724][2606.24151][2509.11145].

## 2. Associative-memory and transactional substrates

The most explicit architectural instantiation is MeMo. Its memory primitive is the classical correlation matrix memory
$$
C = \sum_i k_i v_i^{\top},
$$
with retrieval by
$$
\hat{v} = C^{\top} k.
$$
Multi-layer MeMo stacks several such memories,
$$
\mathcal{C}_{\mathrm{MeMo}} = \{C^{(1)}, C^{(2)}, \ldots, C^{(L)}, C^{(\mathrm{out})}\},
$$
so that higher layers compose tokens into higher-level sequence representations and \(C^{(\mathrm{out})}\) stores next-token associations [2502.12851][2606.24040].

At the interface level, MeMo exposes explicit architectural operations
$$
\mathrm{memo}(S,y), \quad \mathrm{forget}(S,y), \quad \mathrm{retrieve}(S),
$$
where \(S\) is a sequence and \(y\) is the associated next token or value. This is the critical departure from transformer-style implicit memorization: memorization, retrieval, and forgetting are callable operations rather than distributed side effects of gradient descent [2606.24040].

The version-aware extension of Multi-layer MeMo turns these primitives into a transactional Text2Mem layer. A primitive edit is
$$
e_j = (S_j, y_j, \lambda_j), \qquad \lambda_j \in \{+1,-1\},
$$
and a high-level operation is an ordered transaction
$$
\tau = \langle e_1; e_2; \ldots; e_m \rangle.
$$
The paper’s key claim is that a version-aware operation is rarely a single MeMo association; it is an ordered program of forgetting, memorizing, preserving historical chains, and recording an inverse program [2606.24040].

This transaction model supports operations such as `replace`, `obsolete`, `keep-history`, `rollback`, and `trace`. For multi-token continuations, MeMo decomposes a continuation \(Y=[y_1,\ldots,y_n]\) into a chain of next-token associations, so a replacement is implemented as forgetting the old chain and memorizing the new one. History preservation is achieved by writing versioned sequences, so the “latest” view can suppress an outdated fact while version-conditioned queries still retrieve the old fact. Rollback is defined by reversing the transaction order and negating the signs:
$$
\tau^{-1} = \langle (\ell_m,S_m,y_m,-\lambda_m); \ldots; (\ell_1,S_1,y_1,-\lambda_1)\rangle.
$$

Two auxiliary CMMs turn this into a memory system for changes themselves. The Version CMM maps version transitions and slot indices to transaction handles, and the Transaction CMM maps transaction handles to executable change content and inverse programs. The framework also accepts structured diff-level inputs. A structured assertion \((v,s,r,o)\) is serialized as
$$
\sigma(v,s,r) = [\mathrm{VERSION}, v, \mathrm{SUBJECT}, s, \mathrm{RELATION}, r],
$$
so writing and removing an assertion are simply \(\mathrm{memo}(\sigma(v,s,r), o)\) and \(\mathrm{forget}(\sigma(v,s,r), o)\) [2606.24040]. In this formulation, Text2Mem is not merely “text to vector”; it is text to an auditable, reversible, version-aware edit program over explicit memories.

## 3. Optimization-based writing and parametric fast memory

A second family keeps the base language model frozen and learns a per-context memory state at test time. GradMem studies the context-removal setting in which the model must answer queries without access to the original context after a write phase. Its memory is a fixed-size matrix of prefix memory tokens,
$$
\mathcal{M} \in \mathbb{R}^{m \times d},
$$
prepended to the query during reading. Writing is driven by a self-supervised context reconstruction loss,
$$
\mathcal{L}_{\mathrm{write}}(\mathcal{M};C) = -\sum_{i=1}^{N} \log f_\theta\!\left(t_i \mid [\mathcal{M}; t_{<i}] \right),
$$
and optimized by \(K\) steps of test-time gradient descent on the memory tokens alone:
$$
\mathcal{M}_{k+1} = \mathcal{M}_k - \alpha \nabla_{\mathcal{M}_k}\mathcal{L}_{\mathrm{write}}(\mathcal{M}_k;C).
$$
The model weights remain frozen; only the memory tokens are adapted for the current context [2603.13875].

This loss-driven write mechanism is empirically stronger than forward-only compression at fixed memory size. On associative key–value retrieval with 8 memory vectors, RMT reaches \(45.5\%\) at 16 pairs and \(12.9\%\) at 96 pairs, whereas GradMem with \(K=1\) reaches \(96.3\%\) at 16 pairs and \(32.6\%\) at 96 pairs, and GradMem with \(K=5\) reaches \(100\%\) at 16 pairs and \(88.4\%\) at 96 pairs. The same paper reports competitive transfer to bAbI, Short SQuAD, and WikiText-103, and emphasizes a compute–capacity knob: increasing WRITE steps at inference improves memory quality without retraining [2603.13875].

FastMem takes an explicitly parametric route. Instead of writing into prefix tokens, it updates only the last Transformer block’s FFN before inference to maximize the likelihood of the memorization text under a next-token-prediction objective with KL regularization:
$$
\mathcal{L}_{\mathrm{NTP}}(\mathbf{x};\theta) = -\sum_{t=1}^{T}\log P_\theta(x_t \mid x_{<t}),
$$
$$
\mathcal{L}_{\mathrm{KL}}(\mathbf{x};\theta_N)=\sum_{t=1}^{T}\mathrm{KL}\!\big(P_{\theta_0}(x_t\mid x_{<t}) \,\|\, P_{\theta_N}(x_t\mid x_{<t})\big).
$$
All layers except the last FFN are frozen. The paper motivates this choice by treating upper FFNs as key–value memory modules and reports that adapting only the last block avoids severe overfitting while remaining fast [2406.16069].

The quantitative gains are large on context-faithfulness tasks. FastMem improves the accuracy of Llama 3-8B-Inst on NQ-SWAP from \(59.1\%\) to \(71.6\%\), and reduces the output structure failure rate of Qwen 1.5-4B-Chat from \(34.9\%\) to \(25.5\%\). On 8×A800 GPUs with a 2500-token input, the memorization phase for Llama-3-8B-Instruct takes about \(1.673\) s and does not increase peak GPU memory over standard forward passes [2406.16069]. The contrast with GradMem is instructive: GradMem writes into explicit prefix memory tokens, whereas FastMem writes the prompt into a narrowly localized parameter subset.

## 4. Application-layer conversational and agent memory

A third family moves Text2Mem entirely outside the model. CALMem is an application-layer dual memory for conversational AI with two subsystems: an episodic memory layer built on sliding-window vector embeddings of conversation history, and a semantic memory layer of agent-writable structured facts [2605.20724]. Episodic memory indexes every stored message in the background using 1,000-character windows with 200-character overlap and 800-character step size, embeds each chunk with all-MiniLM-L6-v2 into \(\mathbb{R}^{384}\), and stores the vectors in SQLite. Retrieval embeds the query, computes cosine similarity, filters by a threshold of \(0.4\), and returns the top-ranked chunks.

The crucial design point is intra-session retrieval. CALMem explicitly excludes chunks that correspond to messages still present in the active prompt and searches over compacted-away turns from the current session as well as prior sessions. This closes what the paper calls the compaction continuity problem: compacted context is no longer irretrievably lost merely because it left the active window [2605.20724].

Memory injection is handled by the MOIM (Message of Injected Memory), whose episodic budget decreases as the context fill ratio rises. For \(r<0.60\), CALMem injects 5 chunks × 600 chars; for \(0.60 \le r < 0.70\), 3 chunks × 400 chars; for \(0.70 \le r < 0.80\), 2 chunks × 250 chars; and for \(r \ge 0.80\), episodic injection is suppressed. Dense retrieval markedly outperforms sparse baselines on a manually labeled conversational retrieval set: TF-IDF yields P@5 \(0.51\), BM25 yields P@5 \(0.59\), and CALMem dense retrieval yields P@5 \(0.74\), R@5 \(0.69\), and MRR \(0.81\). Ablation over long sessions shows that episodic memory alone gives context recovery \(67\%\), semantic memory alone gives fact consistency \(89\%\), and CALMem’s dual memory gives context recovery \(71\%\) and fact consistency \(91\%\) [2605.20724].

Metis applies a related dual-memory idea to self-evolving agents, but with a different distinction: text memory versus code memory. Text memory is structured as
$$
M_{\mathrm{text}} = M_{\mathrm{env}} \cup M_{\mathrm{pit}} \cup M_{\mathrm{plan}},
$$
that is, environment facts, common pitfalls, and execution plans. Code memory is a library of validated callable tools, produced only when a plan shows repeated reuse. The paper’s controlled study isolates the trade-off: text memory is cheaper to construct and transfers better, whereas code memory is more execution-efficient but more expensive and more brittle if distilled too early [2606.24151].

Those trade-offs appear quantitatively in AppWorld. On the official split, Metis improves task goal completion from \(51.8\%\) for No Memory to \(60.1\%\), while reducing execution tokens from \(112.6\)K to \(97.4\)K. On the resampled split, it improves task goal completion from \(54.8\%\) to \(66.1\%\) and reduces execution tokens from \(101.7\)K to \(78.5\)K. The controlled profiling study further shows construction cost asymmetry—text memory requiring \(3.3\)M reflection tokens and 224 rounds versus code memory requiring \(4.3\)M tokens and 562 rounds—and transfer asymmetry, with text dropping from about \(78.9\%\) to \(73.3\%\) from Oracle to Streaming, whereas code drops from about \(75.6\%\) to \(53.3\%\) [2606.24151]. In Metis, Text2Mem is therefore a staged process: raw execution traces become structured textual memory first, and only recurrent plans are crystallized into code.

## 5. Formal memory control languages and execution contracts

The most explicit control-plane formalization is the unified memory operation language Text2Mem. It defines 12 operations organized by stage: `Encode`; storage operations `Update`, `Label`, `Promote`, `Demote`, `Merge`, `Delete`, `Split`, `Lock`, `Expire`; and retrieval operations `Retrieve` and `Summarize` [2509.11145]. Each instruction is represented as a JSON object with fields `stage`, `op`, `target`, `args`, and optional `meta`. The schema uses conditional requirements and invariants: for example, `Encode` requires `args.payload`, `Promote` requires at least one of `priority`, `weight_delta`, or `remind`, `Expire` requires `ttl` or `until`, locked items cannot be hard-deleted, and `Merge` must preserve lineage.

Execution proceeds through a validator–parser–adapter pipeline. The validator checks structural constraints, allowed values, and semantic invariants before execution. The parser converts a valid JSON instance into a typed operation object with normalized parameters such as time, tags, and priority. Adapters then map the typed object either to a SQL prototype backend or to real memory frameworks, invoking embeddings or summarization services when required. Results are returned through a unified execution contract, `ExecutionResult`, which reports status, affected IDs, retrieved content, diffs, and metadata [2509.11145].

The paper explicitly frames this move as analogous to text-to-SQL: natural language is no longer interpreted directly against a backend-specific memory API, but first translated into a formal executable language. The planned Text2Mem Bench correspondingly separates NL→schema generation from schema→execution, with proposed metrics including schema validity, slot accuracy, key–value F1, executability, state diffs, ranking shifts, trigger correctness, and cross-backend consistency [2509.11145]. Relative to transaction-aware MeMo, which formalizes low-level edit programs over explicit associative memories, this language operates one abstraction level above: it standardizes how memory commands are specified, validated, and ported across systems.

## 6. Trade-offs, limitations, and open directions

The literature converges on a recurring set of trade-offs. Explicit memory improves editability, traceability, and locality, but it does not eliminate capacity management or write-time cost. In version-aware MeMo, the scope is explicitly limited to “local changes that can be expressed as MeMo-compatible memory edits”; global corpus-wide shifts are out of scope and would still require training, and the paper gives no formal locality guarantees [2606.24040]. In CALMem, exact brute-force cosine scan is deliberately retained only up to about \(100\)k chunks, with HNSW or external vector databases deferred until scale exceeds about \(500\)k chunks [2605.20724].

Optimization-based writers introduce a different bottleneck. GradMem’s WRITE phase requires \(K\) forward+backward passes over the context, and training relies on second-order meta-learning through the write loop; the paper presents this as the main training cost and notes that one-off queries per context do not amortize the write overhead [2603.13875]. FastMem is cheaper because it updates only the last FFN, but it still assumes that the memorized reference is correct and relevant, and the paper explicitly warns that in RAG settings noisy or malicious references may be followed more faithfully after memorization [2406.16069].

Metis exposes a representation-level trade-off that is likely general. Text memory is broadly applicable and degrades gracefully because the agent can reinterpret or ignore it; code memory is execution-efficient but expensive to construct and brittle if promoted from single trajectories. These results suggest that a robust Text2Mem system should not decide between text and code at design time alone; it should also condition that decision on recurrence, stability, and validation cost [2606.24151]. A similar inference applies across the field: explicit memories are most attractive when updateability, rollback, and provenance matter, whereas prompt- or parameter-based memories are most attractive when the base model must stay fixed and the same context is reused for many queries.

Open directions are stated directly in several papers. Version-aware MeMo calls for benchmarks on update success, rollback, traceability, locality, and transaction reuse; GradMem proposes better write objectives and more efficient meta-learning; FastMem points to multi-layer PEFT-style variants and per-example FFN copies; CALMem identifies hybrid lexical+dense retrieval, fact expiry, and temporal reasoning; Metis highlights better program synthesis and more principled criteria for crystallization; and the memory operation language paper proposes a larger, multilingual Text2Mem Bench and richer adapters [2606.24040][2603.13875][2406.16069][2605.20724][2606.24151][2509.11145]. Taken together, these directions indicate that Text2Mem has become less a single mechanism than a design space organized around one question: how textual experience should be turned into memory objects, memory state, or memory operations that remain editable, economical, and useful over long horizons.

Source: https://www.emergentmind.com/topics/text2mem