LLM agents lack persistent memory, causing conversations to reset each session and preventing personalization over time. We present Lyzr Cognis, a unified memory architecture for conversational AI agents that addresses this limitation through a multi-stage retrieval pipeline. Cognis combines a dual-store backend pairing OpenSearch BM25 keyword matching with Matryoshka vector similarity search, fused via Reciprocal Rank Fusion. Its context-aware ingestion pipeline retrieves existing memories before extraction, enabling intelligent version tracking that preserves full memory history while keeping the store consistent. Temporal boosting enhances time-sensitive queries, and a BGE-2 cross-encoder reranker refines final result quality. We evaluate Cognis on two independent benchmarks -- LoCoMo and LongMemEval -- across eight answer generation models, demonstrating state-of-the-art performance on both. The system is open-source and deployed in production serving conversational AI applications.
Figures & tables
Figure 1: LoCoMo benchmark F1 scores across four question types. Cognis achieves the highest F1 in every category. Percentage labels show Cognis’s gain over the strongest baseline. Mem0 = Mem0 retrieval; Zep = Zep memory framework; Mem0g = Mem0 with graph memory enabled; Cognis = Lyzr Cognis (ours).
Figure 2: Cross-system accuracy on LongMemEval across six question types. Cognis (orange) leads on five of six categories, with the largest gains on preference recall (+33.3%) and temporal reasoning (+20.6%). SuperMemory leads only on SS-Assistant. Zep/Graphiti = Zep with Graphiti; SuperMemory = SuperMemory graph memory; Cognis = Lyzr Cognis (ours, best across answer models).
Store
Data Type
Purpose
OpenSearch
Documents
Primary store for memories and messages, native BM25 search with configurable text analysis, version history tracking
VDB
Vectors (768D + 256D)
Matryoshka semantic search with dual-dimension collections
Table 1: Dual-Store Data Distribution
Collection
Dimension
Purpose
*_768d
768D
Memory embeddings for accurate semantic retrieval
*_256d
256D
Memory embeddings for fast shortlisting (200 candidates)
immediate_recall_256d
256D
Raw message embeddings for immediate recall queries
Table 2: VDB Collection Structure
Figure 3: Dual-store architecture: OpenSearch (documents + native BM25) and VDB (Matryoshka embeddings at 768D/256D).
Figure 4: Two-panel ingestion pipeline. Left : Immediate storage enables recall before extraction. Right : Context-aware extraction retrieves similar memories, LLM decides ADD/UPDATE/DELETE, version tracking maintains history.
Figure 5: Context-aware extraction comparison. Left : Without context, the LLM creates conflicting memories (existing memory ignored). Right : With context retrieval, the LLM issues UPDATE operations maintaining consistency.
Operation
When Applied
ADD
New information not present in existing memories
UPDATE
New information supersedes or refines an existing memory (includes replaces_id to link versions)
DELETE
New information explicitly contradicts or invalidates an existing memory
NONE
Information is a duplicate or not worth storing (e.g., small talk)
Table 3: LLM Operation Decision Logic
Figure 6: Version chaining for memory history. Each UPDATE creates a new version linked via replaces_id . Historical versions have is_current=false , enabling time-travel queries that traverse the chain to retrieve complete evolution of facts.
Figure 8: Matryoshka two-stage retrieval: truncated 256D embeddings enable fast shortlisting (200 candidates in ∼ 5ms), followed by accurate 768D re-ranking ( ∼ 15ms) for final results.
Single-Hop
Multi-Hop
Open-Domain
Temporal
Method
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
LoCoMo
25.02
19.75
–
12.04
11.16
–
40.36
29.05
–
18.41
14.77
–
ReadAgent
9.15
6.48
–
5.31
5.12
–
9.67
7.66
–
12.60
8.87
–
MemoryBank
5.00
4.77
–
5.56
5.94
–
6.61
5.16
–
9.68
6.99
–
MemGPT
26.65
17.72
–
9.15
7.44
–
41.04
34.34
–
25.52
19.44
–
A-Mem
27.02
20.09
–
12.14
12.00
–
44.65
37.06
–
45.85
36.67
–
Table 4: Performance comparison on LoCoMo benchmark across question types. Metrics: F1 score, BLEU-1 (B1), LLM-as-a-Judge (J). Best in bold , second-best underlined . ( ↑ ) = higher is better.
Single-Hop
Multi-Hop
Open-Domain
Temporal
Embedding Model
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
Nomic Embed
50.23
41.26
69.15
29.02
21.17
52.08
50.72
41.48
68.61
60.48
52.69
72.59
Gemma Embed
40.94
30.88
71.88
23.22
14.72
69.23
44.85
33.37
58.33
54.01
42.46
70.27
Nomic V2
42.38
31.42
65.96
30.31
23.71
50.00
51.67
42.44
68.12
58.54
51.23
73.21
Jina V3
41.42
30.10
65.25
30.41
22.81
52.08
48.66
40.19
67.18
59.37
51.85
74.77
Table 5: Embedding model ablation on LoCoMo benchmark. All configurations use the same retrieval pipeline (RRF fusion + BGE-2 reranking + OpenSearch BM25). Best per-column in bold .
Single-Hop
Multi-Hop
Open-Domain
Temporal
Configuration
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
BGE-2 Reranker (MongoDB)
45.33
33.96
70.21
30.55
23.69
51.04
53.76
44.65
71.34
60.86
53.43
76.64
Zero Entropy Reranker
45.95
34.86
68.23
27.50
20.75
46.97
52.11
43.98
69.59
59.73
58.76
76.17
LLM Query Decomposition
44.73
34.86
69.52
29.50
21.09
50.79
46.11
37.73
68.45
60.75
57.65
77.15
BGE-2 + OpenSearch
48.66
35.76
71.99
31.51
23.22
51.04
54.77
45.12
85.85
62.68
58.95
77.26
Table 6: Retrieval pipeline ablation on LoCoMo benchmark. All configurations use the same embedding model. Best per-column in bold .
Single-Hop
Multi-Hop
Open-Domain
Temporal
Config (Vec/BM25)
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
F1 ↑
B1 ↑
J ↑
70/30
48.66
35.76
71.99
31.51
23.22
51.04
54.77
45.12
85.85
62.68
58.95
77.26
75/25
49.94
36.84
72.53
30.82
22.43
50.17
55.21
46.92
86.11
62.11
58.84
77.26
80/20
49.82
36.41
72.08
29.87
22.04
49.62
55.34
46.08
86.74
61.21
57.33
74.94
60/40
49.11
35.94
71.88
28.63
20.71
48.37
55.02
45.96
86.28
60.73
55.82
74.41
50/50
49.44
36.08
70.11
27.18
19.44
45.72
52.18
40.63
83.02
60.58
55.91
74.08
Table 7: RRF weight ablation on LoCoMo benchmark. Seven vector/BM25 weight configurations evaluated with all other pipeline components held constant. Best per-column in bold .
Question Type
Accuracy
Hit@K
MRR
NDCG
SS-User
100.0%
0.91
0.88
0.87
SS-Preference
93.3%
0.97
0.64
0.67
Knowledge Update
92.3%
0.94
0.75
0.79
SS-Assistant
87.5%
0.96
0.88
0.89
Multi-Session
86.5%
0.68
0.43
0.48
Temporal Reasoning
84.2%
0.80
0.53
0.57
Table 8: LongMemEval benchmark results by question type (GPT-4.1 judge). Accuracy measures end-to-end correctness; retrieval metrics assess whether relevant memories were retrieved. Best accuracy in bold .
Question Type
Zep/Graphiti
SuperMemory
Cognis
SS-User
92.9
97.1
100.0
SS-Assistant
80.4
96.4
92.9
SS-Preference
56.7
70.0
93.3
Knowledge Update
83.3
88.5
96.2
Temporal Reasoning
62.4
76.7
92.5
Multi-Session
57.9
71.4
87.2
Table 9: Cross-system accuracy (%) on LongMemEval. Cognis column shows the best result across all eight answer models for each question type (GPT-4.1 judge). Best per-row in bold .
Answer Model
SS-User
SS-Asst
SS-Pref
Know. Upd
Temporal
Multi-Sess
OVERALL
Gemini 3 Flash
97.1
80.4
50.0
92.3
85.0
78.2
83.4
GPT-4o
97.1
71.4
93.3
93.6
85.0
78.2
85.2
Claude Haiku 4.5
95.7
85.7
80.0
85.9
85.7
80.5
85.4
GPT-4.1
100.0
87.5
93.3
93.6
82.7
79.7
87.2
GPT-5-mini
98.6
87.5
90.0
89.7
90.2
83.5
89.2
Claude Sonnet 4.6
100.0
89.3
86.7
93.6
88.0
85.7
90.0
Table 10: Cognis accuracy (%) on LongMemEval across answer generation models (GPT-4.1 judge). Best per-column in bold .
Large Language Model (LLM) agents require persistent memory to maintain personalization, factual continuity, and long-horizon reasoning, yet standard context-window and retrieval-augmented generation (RAG) pipelines degrade over multi-session interactions. We present MemMachine, an open-source memory system that integrates short-term, long-term episodic, and profile memory within a ground-truth-preserving architecture that stores entire conversational episodes and reduces lossy LLM-based extraction. MemMachine uses contextualized retrieval that expands nucleus matches with surrounding context, improving recall when relevant evidence spans multiple dialogue turns. Across benchmarks, MemMachine achieves strong accuracy-efficiency tradeoffs: on LoCoMo it reaches 0.9169 using gpt4.1-mini; on LongMemEvalS (ICLR 2025), a six-dimension ablation yields 93.0 percent accuracy, with retrieval-stage optimizations -- retrieval depth tuning (+4.2 percent), context formatting (+2.0 percent), search prompt design (+1.8 percent), and query bias correction (+1.4 percent) -- outperforming ingestion-stage gains such as sentence chunking (+0.8 percent). GPT-5-mini exceeds GPT-5 by 2.6 percent when paired with optimized prompts, making it the most cost-efficient setup. Compared to Mem0, MemMachine uses roughly 80 percent fewer input tokens under matched conditions. A companion Retrieval Agent adaptively routes queries among direct retrieval, parallel decomposition, or iterative chain-of-query strategies, achieving 93.2 percent on HotpotQA-hard and 92.6 percent on WikiMultiHop under randomized-noise conditions. These results show that preserving episodic ground truth while layering adaptive retrieval yields robust, efficient long-term memory for personalized LLM agents.
Long-term conversational large language model (LLM) agents require memory systems that can recover relevant evidence from historical interactions without overwhelming the answer stage with irrelevant context. However, existing memory systems, including hierarchical ones, still often rely solely on vector similarity for retrieval. It tends to produce bloated evidence sets: adding many superficially similar dialogue turns yields little additional recall, but lowers retrieval precision, increases answer-stage context cost, and makes retrieved memories harder to inspect and manage. To address this, we propose HiGMem (Hierarchical and LLM-Guided Memory System), a two-level event-turn memory system that allows LLMs to use event summaries as semantic anchors to predict which related turns are worth reading. This allows the model to inspect high-level event summaries first and then focus on a smaller set of potentially useful turns, providing a concise and reliable evidence set through reasoning, while avoiding the retrieval overhead that would be excessively high compared to vector retrieval. On the LoCoMo10 benchmark, HiGMem achieves the best F1 on four of five question categories and improves adversarial F1 from 0.54 to 0.78 over A-Mem, while retrieving an order of magnitude fewer turns. Code is publicly available at https://github.com/ZeroLoss-Lab/HiGMem.
Shuqi Cao, Jingyi He, Fei Tan
East China Normal University, Shanghai, China · Shanghai Jiao Tong University, Shanghai, China
As large language models (LLMs) evolve into autonomous agents, persistent memory at the API layer is essential for enabling context-aware behavior across LLMs and multi-session interactions. Existing approaches force vendor lock-in and rely on injecting large volumes of raw conversation into prompts, leading to high token costs and degraded performance. We introduce Memori, an LLM-agnostic persistent memory layer that treats memory as a data structuring problem. Its Advanced Augmentation pipeline converts unstructured dialogue into compact semantic triples and conversation summaries, enabling precise retrieval and coherent reasoning. Evaluated on the LoCoMo benchmark, Memori achieves 81.95% accuracy, outperforming existing memory systems while using only 1,294 tokens per query (~5% of full context). This results in substantial cost reductions, including 67% fewer tokens than competing approaches and over 20x savings compared to full-context methods. These results show that effective memory in LLM agents depends on structured representations instead of larger context windows, enabling scalable and cost-efficient deployment.
Luiz C. Borro, Luiz A. B. Macarini, Gordon Tindall +2