Agent Memory Systems

Agent memory systems are techniques for giving AI agents persistent context across documents, sessions, tasks, or time. The new research positions llm-wiki as one member of this broader family, but with a distinctive artifact-first design: the persistent unit is a readable Markdown wiki.

Why This Matters

A simple chatbot has no durable workspace unless the application gives it one. Agent memory systems try to solve this by storing, retrieving, consolidating, or compiling knowledge so future work does not start from zero.

The research traces a genealogy from earlier memory and retrieval systems toward LLM Wiki:

• 2023 — Generative Agents (observation, reflection, planning, and memory retrieval) and MemGPT (a “virtual context” model inspired by operating systems).
• 2024 — GraphRAG (graph/community summaries for global questions over private corpora) and MCP (Anthropic’s Model Context Protocol).
• 2025 — HippoRAG 2 (memory-inspired non-parametric retrieval) and mem0 (production memory layer for agents).
• 2026 — Karpathy’s LLM Wiki gist (April), the Tencent LLM-Wiki paper (May), and Anthropic’s Managed Agents with built-in memory, vaults, and scheduled deployments.

Three Families

The research usefully separates the ecosystem into three families, each with a different persistent unit, retrieval model, and update approach:

Family	Persistent Unit	Retrieval Method	Update Model	Best-Fit Use Case
Artifact-first	Markdown wiki pages with links and provenance	Compile-time ingest, index navigation, manual browsing	Incremental source-to-page extension	Personal second brain, research vault, agent documentation
Memory-first	Memory objects, session state, consolidated facts	Associative retrieval, consolidation, reflection	Continuous learning across sessions	Multi-session agents, customer support, persistent chat
Graph/retrieval-first	Knowledge graph, vector indexes, community summaries	Graph traversal, vector search, PageRank	Incremental graph updates or full rebuild	Large corpora, global queries, multi-hop retrieval

1. Artifact-first

The system produces a durable human-readable artifact. llm-wiki is the clearest example here: the output is a Markdown wiki with pages, links, index, log, and source references. Update means reading a source and the existing wiki, then writing or extending pages.

2. Memory-first

The system focuses on retaining useful facts or context across sessions. mem0, MemGPT, and related systems are closer to this family. Their goal is not necessarily to produce a browsable wiki. Update means consolidating new information into an existing memory store.

redis-iris-agent (2026) is a vendor-preview instance of the same pattern: a managed Agent Memory service auto-promotes durable facts from a conversation in the background and exposes them to the agent as search_memory/store_memory tools, distinct from working (session) memory that resets on demand. Unlike mem0, it is bundled with a second, separate concern — a Context Retriever that exposes live business data through auto-generated MCP tools — rather than shipped as a standalone memory library.

memoryos (2026) is a second, closed-source vendor-preview instance: a local SQL database (14 collections, laptop or user’s own Supabase) for Claude Code/Codex-class agents, also bundled with a second, separate concern — a “brain health” diagnostic scanner (45-check scan, context-engineering pattern scores) rather than shipped as a standalone memory library. Its paid tier adds confidence-scored storage and decay detection, a commercial parallel to this vault’s own [[memory-lifecycle]] staleness-flagging concept.

3. Graph/retrieval-first

The system focuses on better retrieval and synthesis over large corpora. GraphRAG, LightRAG, and HippoRAG are examples. Update means incrementally adding new nodes and edges to a knowledge graph or rebuilding a vector index.

Memory Retrieval Patterns

A multi-stage hybrid retrieval pipeline that fuses semantic search (embeddings), BM25 keyword matching, Reciprocal Rank Fusion (RRF), cross-encoder re-ranking, and MMR diversity filtering. Each stage runs independently and catches what the others miss: semantic search finds meaning matches, BM25 catches keyword-exact matches, re-ranking filters false positives, and MMR reduces redundant results. Reported to improve recall by 15–30% over single-method retrieval.

When to use: large memory stores (100+ entries) where single-method vector search misses keyword-dependent matches or returns repetitive results. Skip it: small stores (<50 entries) or real-time chat where sub-50ms latency matters — the full pipeline adds 200–500ms per query. See memory-retrieval-patterns and memory-retrieval-patterns-vs-wiki-query for the full comparison with this vault’s compile-time query approach.

Implications

The three families are not tiers of progress — they are design choices trading human legibility, session continuity, and retrieval accuracy against each other. The vault deliberately chose artifact-first; the other families remain valid support layers for navigation and retrieval when needed.

Open Questions

• At what memory-store size does the full Memory Retrieval Patterns pipeline stop being worth its latency cost? The source says <50 entries is too small, but the exact threshold across domains is untested.
• Can the vault’s ingest-time compilation absorb any of the re-ranking stages so that query-time search gets the same recall gains at zero per-query latency? The vault’s hybrid_query_helper.py already runs RRF over BM25+vector+PageRank; MMR-style diversity filtering is not yet applied at query time.
• How does HyDE (hypothetical document embeddings) map onto the artifact-first model? In the runtime pipeline, HyDE rewrites the query; in a wiki, the query is a natural-language question, so query transformation would be an agent-side step, not a retrieval-index step.

Relationship to LLM Wiki

LLM Wiki is not just “memory.” It is memory made legible as an editable knowledge artifact. That makes it especially suitable for a personal second brain or research vault, because the user can inspect, correct, and reorganize the compiled knowledge.

The trade-off is discipline. A wiki can decay if ingest, query, lint, sources, and links are not maintained. That is why this vault uses AGENTS.md, _schema.md, index.md, and log.md as governance files.

LightRAG and HippoRAG

lightrag and hipporag are useful because they clarify two different paths inside the graph/retrieval-first family. LightRAG emphasizes practical graph-enhanced retrieval with dual-level search and incremental updates. HippoRAG emphasizes associative memory: using a knowledge graph and Personalized PageRank to retrieve across multi-hop relationships.

For Synaptic Lattice, this distinction matters because the vault is currently artifact-first. These systems are not replacements for the wiki; they are possible future support layers for navigation, retrieval, and inferred connections.

Related

• eva-brain-desktop-app — Eva-brain — Desktop App for LLM Wiki

• llm-wiki — artifact-first implementation of persistent agent knowledge.

• rag — retrieval-time approach that LLM Wiki contrasts with.

• knowledge-graph — structural approach that can support richer retrieval.

• llm-wiki-vs-memory-and-graph-rag — comparison of these families.

• lightrag-vs-hipporag — focused comparison of two graph-enhanced RAG systems.

• cognee — production memory engine (ECL pipeline, 14-tool MCP, 38+ sources)

• rightmemory — typed-edge graph memory for coding agents

• mem0 — production memory layer for agents (60.6k⭐)

• redis-iris-agent — Redis-managed memory-first vendor demo bundling agent memory with auto-generated MCP data-retrieval tools

• memoryos — local SQL memory-first vendor product for coding agents, bundling memory with a “brain health” diagnostic scanner

• qmd — hybrid BM25+vector search for scaling wiki retrieval past index.md

• rank-ecossistema-backlinks-relacoes — ranking of the ecosystem by backlinks, relations, and new-knowledge generation

Sources