INQUIRING LINE

When an AI assistant 'remembers' you, is it actually searching its notes about you, or something murkier?

How does stored memory actually get selected and inserted into a given request?

This explores how an AI system picks which saved memories to pull in when you send it a new message, and how those memories end up inside the request the model actually sees.


This explores how an AI system picks which saved memories to pull in for a new request, and how they get into the model's working context. The usual mental picture is a search engine: store notes, find the closest matches to the query, paste them into the prompt. The corpus suggests that picture is only one of several ways this works. It also suggests the selection step is where most of the interesting failures happen.

Start with who makes the decision. One useful split separates a 'hot path', where the agent chooses on the fly (often through a tool call) to read or write memory, from a 'background path', where code on a schedule or trigger decides for it How should agents decide what memories to keep?. The hot path pays more attention to context but is less reliable. The background path is predictable but blunt. A real example of how much the system decides on its own: in ChatGPT, 96% of stored memories were created without the user asking Who actually controls what ChatGPT remembers about you?. Interviewed users said they want consent and editing at every stage, from creation through use What memory controls do users actually want from LLMs?.

Next, how the selection itself happens. Several notes push against 'retrieve once, then reason.' MRAgent builds memory as a graph and reasons while it walks it, dropping paths as evidence piles up. It beats fixed retrieval pipelines and costs fewer tokens Can agents reconstruct memory on demand instead of retrieving it?. FluxMem makes a related claim: whether a memory gets used depends less on what's stored than on how it links to memories that tend to be needed together. A memory with no links is effectively unreachable Is agent memory a storage problem or a connectivity problem?. For web agents, PRAXIS finds it works better to look up memories by the agent's current situation (what's on screen, what was just clicked) than by high-level task summaries Does state-indexed memory outperform high-level workflow memory for web agents?. So the 'key' used to look a memory up matters as much as the memory.

The less obvious lesson is that inserting everything that looks relevant can backfire. One analysis argues long multi-turn agents fail less from missing knowledge than from weak control over what enters context. Replaying transcripts and retrieving freely let errors and drifting constraints build up. A small, schema-governed 'committed state', kept separate from free recall, holds up better Can agents fail from weak memory control rather than missing knowledge?. Insertion also has a governance side. In shared memory systems, retrieval and vector stores can surface information that was supposedly deleted or that the requester isn't authorized to see. In those systems, 'deleted' rarely means gone Can shared agent memory systems reliably delete information?.

Some approaches skip inserting text altogether. MeMo trains a separate memory model that carries the knowledge, so nothing has to be searched or pasted at inference time Can a separate memory model inject knowledge without touching the LLM?. Another line of work moves older context into the model's weights during offline 'sleep' phases. There, the bottleneck is the compute spent consolidating, not storage space Is long-context bottleneck really about memory or compute?. Memory can also appear where nobody designed it: short-lived agents used a shared package repository to pass findings to later agents Can ordinary infrastructure become unplanned agent memory?. If you want to see which of these stages actually breaks, a data-management view splits memory into storage, extraction, retrieval and maintenance and tests each separately How should we actually evaluate agent memory systems?. The corpus has little on the exact prompt-assembly mechanics of commercial products (ranking formulas, where in the prompt memories go). It is stronger on the design choices around that step.


Sources 12 notes

How should agents decide what memories to keep?

Memory management decomposes into explicit hot-path (agent decides via tool calling) and implicit background (programmatically triggered) paths. Each approach trades context-sensitivity for reliability differently across generation, storage, retrieval, and deletion.

Who actually controls what ChatGPT remembers about you?

Analysis of 2,050 memory entries from 80 users shows the system initiated 96% of memories without user request, while users explicitly requested only 4%. This suggests OpenAI's stated user control over memory doesn't match observed behavior.

What memory controls do users actually want from LLMs?

An 18-person interview study found users want explicit consent at memory generation, management interfaces to review and edit memories, purpose limits on usage, and agency over inferred data. Participants actively perform privacy calculus rather than passively accept memory's trade-offs.

Can agents reconstruct memory on demand instead of retrieving it?

MRAgent achieves up to 23% gains on reasoning tasks by reconstructing memory through active graph traversal that prunes paths based on accumulated evidence, while reducing token and runtime cost compared to fixed-retrieval pipelines.

Is agent memory a storage problem or a connectivity problem?

FluxMem shows that memory usefulness is determined by links between co-activated units forming an accessible subgraph, not by what is stored. Storage is necessary but inert; topology determines whether useful memories are reachable at decision time.

Show all 12 sources
Does state-indexed memory outperform high-level workflow memory for web agents?

PRAXIS shows that indexing procedures by environment state and local action pairs yields consistent accuracy and reliability gains across VLM backbones on the REAL benchmark, compared to higher-level workflow abstractions that lose click-by-click specifics.

Can agents fail from weak memory control rather than missing knowledge?

Agent performance degrades in long workflows because transcript replay and retrieval-based memory lack gating mechanisms. A bounded, schema-governed committed state that separates artifact recall from permanent memory write prevents error accumulation and constraint drift.

Can shared agent memory systems reliably delete information?

GateMem evaluated three requirements jointly: utility on legitimate requests, access control across authorization boundaries, and active forgetting after deletion. Long-context prompting governs best but scales poorly; retrieval and vector store systems leak unauthorized or deleted information because deletion rarely means unrecoverable erasure.

Can a separate memory model inject knowledge without touching the LLM?

MeMo trains a dedicated memory model to encode new knowledge, eliminating inference-time search costs that scale with corpus size. It avoids fine-tuning risks and works with frozen proprietary models, but trades this for up-front training cost and capacity limits.

Is long-context bottleneck really about memory or compute?

Research shows the bottleneck is not memory capacity but the compute required to consolidate evicted context into fast weights during offline sleep phases. Performance improves with more consolidation passes, following a test-time scaling pattern on harder reasoning tasks.

Can ordinary infrastructure become unplanned agent memory?

During a 2026 evaluation, short-lived AI agents repurposed a shared package repository as memory by writing and reading exploit findings across agent lifespans. The agents converted ordinary infrastructure into persistent state without deliberate memory system architecture.

How should we actually evaluate agent memory systems?

Decomposing memory into storage, extraction, retrieval, and maintenance stages exposes design trade-offs and failure modes that task-success metrics completely hide. Module-by-module evaluation across 12 systems shows which component actually failed rather than just whether the task succeeded.

Papers this line draws on 8

The research behind the notes this line reads — ranked by how closely each paper relates.