RRememorio Blog

Source notes · Seven project articles

Long-term memory is more than vector search

An agent should not pour all history back into its prompt. It needs to know who stores raw history, user profiles, graph relationships, workflow state, and current model input; when each is written; and how each returns. The series asks those same questions of eight projects.

How to read: begin with the route notes and its five boxes, then move project by project. For system selection, ask where history lives before asking how clever retrieval is.

Agent Memory reading map: Mem0, Letta, Graphiti, LangMem, TencentDB, OpenViking, and the combined Cognee / Supermemory chapter.

Reading route

Build a shared map, then inspect each project's boundary

Part 0 is an introduction outside the seven project articles; it supplies the same terms and decision questions for every comparison.

Agent Memory reading map: Mem0, Letta, Graphiti, LangMem, TencentDB, OpenViking, and the combined Cognee / Supermemory chapter.Part 0 · IntroductionAgent Memory: Long-term memory is more than vector search

Use five boxes to separate raw history, extracted memory, relationships, workflow state, and current model input.

Read the route notes → Mem0 stores extracted memory records, then retrieves and ranks a small selection for the current turn context.01 · Mem0From mutable memories to ADD-only writes

Follow the algorithm from extraction and conflict updates to append-only storage and hybrid retrieval.

Read Part I → Letta V1 state and context: memory_blocks belong to AgentState and Memory.compile() builds the system prompt; successful steps checkpoint message_ids and state.02 · LettaWhat returns when an agent resumes

Separate archived V1 Block and AgentState recovery from the current Letta Code local backend, which compiles Git-committed memory for later turns.

Read Part II → Graphiti temporal facts and provenance: episodes supply evidence; valid_at and invalid_at delimit fact validity, retaining invalidated history for explicit time filtering.03 · GraphitiPreserving history when facts change

Use a temporal graph to retain both what used to be true and what is true now.

Read Part III → LangMem execution paths: in-turn manage_memory and search_memory use BaseStore, background reflection is app-scheduled, and a separate checkpointer stores thread state.04 · LangMemWhen to write memory now or process it later

Separate hot-path task progress from background memory organization and their different latency budgets.

Read Part IV → TencentDB Agent Memory evolves from the v1 local plugin and v1.0 Gateway to v2 Team Memory, separating MemoryCore, Memory Hub, MemoryProxy, ACL, and Agent Loadout.05 · TencentDBFrom local memory to a team memory server

Follow Context Offload, Gateway, Memory Hub, and Memory Proxy as experience becomes permissioned, loadout-ready team assets.

Read Part V → OpenViking organizes resources, memories, and skills under viking:// and selects L0, L1, or L2 reading depth to assemble context.06 · OpenVikingMemory, resources, and Skills in one context tree

Follow reading depth, budgeted context assembly, and two-phase session commits through one resource tree.

Read Part VI → Cognee turns source material into a searchable knowledge layer through cognify; Supermemory memory can build profiles while superrag supports retrieval only.07 · Cognee / SupermemoryKnowledge processing versus shared memory service

Compare turning many sources into a knowledge graph with serving memory to multiple agents through a context API.

Read Part VII →