AI Memory Systems: A Comparative Survey

AI systems often **compose multiple memory types**. A common pattern (the “enterprise context layer”) is to feed queries through vector search, graph traversal, and memory retrieval before calling the LLM【30†L536-L543...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-553afbee/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/ai-memory-strategy-comparison/AI Memory Systems A Comparative Survey.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-06T17:59:21.3933560Z
Content hash	sha256:553afbee8eee4770ba5331ee8dec2bee0a9f3d86ed9d5b66a9059b01fa1c5915
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-improve-553afbee8eee.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-improve-553afbee8eee.txt

Current File Content

Structure Preview

• AI Memory Systems: A Comparative Survey
• Memory Types in AI
• Technical Mechanisms: Data Flow and Integration
• Privacy, Security, and Governance
• Comparative Implementations and Platforms
• Table: Memory Mechanisms Compared
• Conclusions

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 25297
• Preview characters: 11920

# AI Memory Systems: A Comparative Survey

**Executive Summary:** Modern AI systems augment stateless models with various *memory* mechanisms to persist context, facts, and user data across time. We identify many memory types – e.g. short-term (conversation context), long-term (persistent knowledge), episodic, semantic, procedural memory – and technical mechanisms like retrieval-augmented generation (RAG), vector embeddings (vector databases), knowledge graphs, caches, session states, fine-tuned weights, and neural memory networks. Each has distinct data structures (e.g. token buffers, vectors, graph edges, key–value stores) and retrieval methods (sliding windows, ANN search, graph queries, embedding models). We detail how these work, their use cases and limits, and how they interoperate. For example, production AI often composes **vector search + graph traversal + user memory** before each generation to supply a full context【30†L536-L543】. We compare major platforms (OpenAI’s ChatGPT memory, Anthropic Claude, Microsoft Copilot, LangChain/LlamaIndex, Weaviate, Pinecone, Milvus, Chroma, etc.) citing official docs. Privacy and governance are critical: user memories must be controlled (e.g. ChatGPT lets users delete saved facts【13†L34-L43】; Claude offers “zero data retention” modes) and secured. Finally, a comparison table contrasts each approach on persistence, capacity, latency, cost, integration effort, and best use cases.

## Memory Types in AI

- **Short-term (Working) Memory:** The model’s immediate context window (chat history). LLMs have no inherent memory beyond their token buffer【6†L168-L176】, so agents use a rolling context window or in-memory buffer to retain recent inputs. For example, a chatbot holds the last *n* messages and discards older ones as it exceeds its token limit【6†L193-L202】. This lets it maintain dialogue coherence (smoother responses over turns). *Implementation:* typically a FIFO buffer of tokens or messages; updating is trivial (append newest, drop oldest). *Scalability:* limited by model’s max tokens; cost negligible. *Latency:* essentially instant (in memory). *Use case:* real-time conversation. *Limitation:* cannot store information beyond a session, and large buffers slow down inference.

- **Long-term (Persistent) Memory:** Data retained across sessions, enabling personalization or knowledge recall【6†L213-L219】. In practice, this is stored externally (databases, vector indexes, knowledge bases). A common pattern is **Retrieval-Augmented Generation (RAG)**: documents or knowledge are chunked, embedded into a vector database, and at query time relevant chunks are retrieved to condition the LLM【39†L1-L4】. This offloads heavy memory from the model and avoids retraining. *Data structures:* vector stores of embeddings or graph DBs. *Retrieval:* approximate nearest neighbor (ANN) search on vectors (e.g. HNSW indexes), or graph traversals. *Updating:* typically offline or background (e.g. re-embedding new documents). *Latency:* vector search often <50 ms (depending on scale). *Scalability:* millions–billions of items (Milvus scales to tens of billions【37†L72-L74】). *Cost:* high storage/indexing costs; queries consume CPU/GPUs (and service fees). *Use cases:* knowledge-base Q&A, personalization (remembering user profile, preferences). *Limitation:* if not updated, memory can become stale. Pure RAG alone can’t do multi-hop reasoning or personalization (no persistent user model)【30†L431-L439】; pure LLM weights can’t be updated without costly retraining.

- **Episodic Memory:** A log of specific past events or interactions (e.g. conversation transcripts, actions). Analogous to human episodic recall, it records *what happened when*. AI agents implement this by appending structured event records (time-stamped actions/responses) to a store. *Use case:* case-based reasoning, sequential decision tasks. For example, a recommender might log a user’s past choices to improve future suggestions. *Implementation:* often a time-indexed database or file logs. *Retrieval:* simple lookup (by session/user ID) or filtering (time range). *Limitation:* grows unbounded; retrieving relevant episodes requires indexing or summarization. Tools like LlamaIndex treat conversation history as episodic memory flushed into vector stores【35†L42-L49】.

- **Semantic Memory:** General facts and concepts (e.g. encyclopedic knowledge). In AI this is usually a *knowledge base* or *vector space of encoded facts*. For instance, an AI legal assistant might store case law and precedents (facts about law) in a knowledge graph or dense index【6†L247-L254】. *Structure:* graph of entities (nodes) and relations (edges), or document store with embeddings. *Retrieval:* graph queries (multi-hop SPARQL/Gremlin) or semantic search in a vector DB. *Updating:* controlled edits to the graph or continuous ingestion of new documents. *Latency:* graph traversals can be slower (especially multi-hop); vector search is fast. *Use:* fact lookup, reasoning chains, compliance checks. *Limitation:* building and curating a comprehensive knowledge graph is labor-intensive and error-prone【30†L461-L468】【30†L481-L490】.

- **Procedural Memory:** Stored skills and procedures (AI “how-to” rules). In practice, this is embedded in model weights (trained patterns) or rule engines, not explicitly manipulated at runtime. An AI agent’s system prompt or script could represent procedural memory (e.g. “How to answer customer requests”). Agents learn automated workflows (e.g. via reinforcement learning) and store them as part of their policy (weights) or explicit task templates. *Use:* repetitive tasks, skill execution (e.g. always use a calculator for math). *Limitations:* hard to adapt on the fly without retraining.

- **Vector Embeddings / Vector DB:** Though not a “memory” type per se, embeddings are the backbone of many memories (especially RAG/semantic memory). Text or data is encoded into vectors (dense numeric representations). These are stored in vector databases (Weaviate, Pinecone, Milvus, Chroma, etc.). *Data structure:* high-dimensional vectors. *Indexing:* ANN indexes (like HNSW or IVF) support nearest-neighbor search. *Retrieval:* query text is embedded and nearest vectors are fetched. *Updating:* vectors are upserted or deleted; indexing usually asynchronous. *Latency:* typically 10–100 ms depending on size and cluster. *Scalability:* designed to handle millions to billions of vectors (Milvus claims “scale to tens of billions”【37†L72-L74】). *Use cases:* Semantic search, document retrieval for RAG, similarity search. *Limitations:* Requires computing embeddings; index rebuilds can be costly; relevance depends on embedding quality.

- **External Databases and Files:** Any persistent storage (SQL/NoSQL databases, file systems, object stores) can serve as memory by logging context or artifacts. For example, Anthropic’s Claude uses a client-side file directory `/memories` as a primitive memory tool【15†L185-L194】. On each session start Claude “checks its memory directory” and reads any relevant files to pick up context【15†L219-L228】. *Retrieval:* simple file read or DB query. *Consistency:* fully consistent (especially if client-controlled). *Latency:* filesystem/DB lookup (milliseconds). *Use:* project context, logs, static resources. *Limitations:* lack semantic indexing (must code retrieval logic); suitable for structured or small data.

- **Session/State Memory:** Tied to a user session or conversation thread. This can be just the conversation history, or a session ID mapping to stored variables in a database. LangChain calls short-term memory “thread-scoped” state【32†L99-L107】. *Implementation:* key-value store (e.g. Redis) or application memory keyed by session. *Retrieval:* by session ID lookup. *Use:* keep user preferences or intermediate state for chatbots. *Limitation:* usually ephemeral (cleared after session ends unless saved to long-term store).

- **Cache:** A temporary in-memory store (e.g. LRU cache or Redis) used to speed up repetitive computations (like model queries or vector searches). *Structure:* hashmap (key → response or vectors). *Update:* on every query, cache result. *Retrieval:* fast lookup if key matches. *Use:* accelerate repeated prompts or intermediate steps. *Limitation:* cache hit rate falls with high variability; must invalidate stale entries. Not suitable for long-term personalization.

- **Fine-tuning / Continual Learning:** Considered a kind of “memory” in that model weights encode learned information. Updating model weights on new data (fine-tuning or continual learning frameworks) is one way to give a model new knowledge. *Data:* training dataset. *Update:* offline gradient-based training. *Retrieval:* implicit in model outputs. *Latency:* high during training, but inference remains as usual. *Use:* permanently imbue domain knowledge or user data into the model. *Limitation:* slow, expensive, risk of catastrophic forgetting; not real-time. Unlike RAG, it cannot easily add or remove individual facts on the fly.

- **Neural Memory Networks & Attention:** Some architectures explicitly incorporate memory-like modules (e.g. Neural Turing Machines, End-to-End Memory Networks). Modern LLMs use attention as a form of *dynamic* short-term memory: they compute key-value attention over past tokens in the context window each time they generate. This is *latent memory* within a session – no persistence beyond the input. *Structure:* matrices of key/value vectors. *Use:* in-model context management. *Limitation:* none persists beyond each generation; also attention’s quadratic scaling limits context length.

## Technical Mechanisms: Data Flow and Integration

AI systems often **compose multiple memory types**. A common pattern (the “enterprise context layer”) is to feed queries through vector search, graph traversal, and memory retrieval before calling the LLM【30†L536-L543】. The data flow can be illustrated as:

```mermaid
flowchart LR
  subgraph ExternalMemory
    vectordb[(Vector DB)]
    kg[(Knowledge Graph)]
    memstore[(Session/Memory Store)]
  end
  UserInput([User Query])
  UserInput --> vectordb
  UserInput --> kg
  UserInput --> memstore
  vectordb -->|documents| Context((Context Buffer))
  kg -->|facts| Context
  memstore -->|user data| Context
  Context --> LLM([LLM (Transformer)])
  LLM -->|Answer| Response([AI Response])
```

Here the user query (and possibly its embedding or entities) triggers:
- a **vector search** (e.g. in Milvus/Pinecone/Chroma) retrieving top-k similar documents or contexts (RAG),
- a **knowledge-graph traversal** extracting related entities/facts (if used), and
- a **user/session memory lookup** (e.g. saved profiles). These pieces of context are merged into the prompt for the LLM. For example, Atlan describes a four-stage flow: "vector search identifies relevant documents, graph traversal gathers connected context, memory retrieval injects session/user info, then LLM inference runs on the composed context"【30†L536-L543】.

**Interoperability & Integration Patterns:** Modern AI stacks rarely use one memory mode in isolation. In practice:
- **RAG + Memory:** A vector DB (text index) supplies factual context, while a separate user memory store holds personal preferences. For instance, ChatGPT uses both conversation history and a “memory” of user info【13†L34-L43】.
- **Hybrid KG & RAG (Graph RAG):** GraphRAG methods combine vector search to find seed nodes and then traverse a knowledge graph for multi-hop insights【30†L473-L481】. This yields better reasoning over linked facts than flat similarity alone.
- **Session + Long-term Memory:** Agents often first retrieve any persistent user profile (e.g. “Alice prefers Italian food”) and then feed that plus current session logs into the prompt. LangChain’s memory framework does this via “stores” that persist across threads【32†L99-L107】.

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: AI Memory Systems: A Comparative Survey; Memory Types in AI; Technical Mechanisms: Data Flow and Integration; Privacy, Security, and Governance; Comparative Implementations and Platforms; Table: Memory Mechanisms Compared; Conclusions. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-416 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "AI Memory Systems: A Comparative Survey",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-553afbee/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/ai-memory-strategy-comparison/AI Memory Systems A Comparative Survey.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:553afbee8eee4770ba5331ee8dec2bee0a9f3d86ed9d5b66a9059b01fa1c5915",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-06T17:59:21.3933560Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-416",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}