VikingMem: Memory Base Management System

• VikingMem is a memory base management system that persistently manages evolving LLM states by selectively extracting high-value memories from diverse input streams.
• It employs schema-driven extraction and operator-based entity evolution to consolidate events into meaningful, actionable memory updates.
• Its directory-aware design using DSQ, DSM, and TrieHI enables filesystem-style organization and low-latency retrieval, enhancing AI agent performance.

VikingMem is a Memory Base Management System built on the VikingDB vector engine for stateful LLM-based applications, and, in OpenViking deployments, a directory-aware memory layer for AI agents. Across these formulations, it operationalizes a persistent, evolving memory substrate through selective extraction of high-value memories, Event–Entity abstractions, operator-based entity evolution, topic-wise temporal compression, and low-latency retrieval; in hierarchical settings, native directory semantics supplied by Directory-Semantic Query (DSQ), Directory-Semantic Maintenance (DSM), and the Trie-based Hierarchical Index (TrieHI) provide filesystem-style organization, directory-recursive retrieval, and efficient structural updates (Fu et al., 28 May 2026, Wang et al., 15 Jun 2026).

1. Memory Base paradigm and system scope

VikingMem is presented as a production-grade Memory Base Management System that manages the persistent, evolving state of long-lived LLM applications. The underlying Memory Base paradigm is defined as a dedicated substrate for the persistent, evolving record of experiences and interactions that shape future behavior of LLM applications. It is distinguished from ad hoc logs and stateless caches by explicit handling of memory lifecycle, including selective capture, consolidation, refinement, forgetting, provenance, and retrieval under latency constraints (Fu et al., 28 May 2026).

The system is organized around three core principles. First, it performs selective extraction of high-value memories from noisy, interleaved streams such as dialogue transcripts, meeting notes, and logs. Second, it treats memory as inherently stateful and evolutionary: discrete events progressively update and consolidate persistent entities, with correction, deduplication, temporal compression, and recency weighting. Third, it adopts a generalizable abstraction paradigm in which configurable schemas define types, properties, and update rules, enabling transfer across education, recommendation, social companionship, and agent memory without rebuilding the memory stack.

Operationally, VikingMem runs as a memory-management layer atop VikingDB. Its pipeline comprises ingestion, event-centric extraction, entity updates, storage and indexing, retrieval and recall, and summarization or compression. Raw session streams are accumulated, with a typical threshold of at least 20 messages, then transformed by one-pass schema-driven extraction into event instances and entity update payloads. Events, entities, and ancillary keyword associations are persisted in VikingDB, with dense embeddings and multi-vector representations precomputed for retrieval and reranking. This architecture implies that VikingMem is not merely a retriever or a vector store wrapper; it is a data-management layer that couples extraction, update semantics, indexing, and recall.

2. Event–Entity abstractions and update algebra

The core data model consists of events, entities, and operators. Events are discrete, timestamped, episodic records produced by selective extraction. They are constrained by schemas specifying EventType, Description, and a set of Properties, and they retain immutable metadata such as timestamps, topics, confidence, provenance, and optional instance-level importance weights. Entities are persistent, evolving state representations such as profiles, SOPs, and tool knowledge. Their schemas define EntityType, Description, Properties, and, for each property, an AggregateExpression that binds relevant EventType and PropertyName to an operator. Operators include SUM, COUNT, MAX, AVG, LLM_MERGE, and TIME_COMPRESS (Fu et al., 28 May 2026).

The paper formalizes entities as parametric views over event logs:

$$\text{entity} := \operatorname{SELECT}\ \mathsf{OP}\bigl(\text{event.content}\bigr)\ \operatorname{FROM}\ \text{Events}\ \operatorname{WHERE}\ \mathrm{filters}(\text{event})\ \operatorname{GROUP\ BY}\ \mathrm{keys}(\text{event}).$$

This formulation makes explicit that changing keys, filters, or operators produces different materialized entity views without changing the engine itself. A plausible implication is that VikingMem’s generality comes less from any single memory schema than from this algebra over event logs.

Event-centric memory extraction is one-pass and schema-driven. Rather than issuing one prompt per memory type, VikingMem compiles all event and entity schemas into a single comprehensive prompt and extracts multiple memory types in one LLM pass. Prefix-cache optimization reuses fixed prompt segments such as system instructions and schemas. Intelligent memory segmentation follows a two-phase LLM-driven procedure: semantic saliency filtering removes filler and low-value turns, and event-centric partitioning identifies precise start and end coordinates of coherent topics, outputting compact tuples; non-contiguous spans pertaining to the same topic can be merged into unified events.

Entity evolution combines deterministic and LLM-based mechanisms. For string fields, the Entity Update Algorithm (EUA) uses compact patches of the form <<<< SEARCH … ==== … >>>> REPLACE, retrieves a top-5 candidate set of existing entities via ANN over entity representations, finds the best approximate span via edit distance, and applies deterministic replacement. When more complex synthesis is required, LLM_MERGE performs textual synthesis, conflict resolution, and deduplication. Statistical operators update numeric properties directly. This operator library is central to VikingMem’s claim that memory should evolve rather than accumulate as an append-only archive.

3. Retrieval, temporal weighting, and compression

Retrieval in VikingMem is hybrid and multi-path. The primary path uses hybrid dense–sparse search from VikingDB, and an auxiliary keyword-graph path supplies complementary candidates for cases such as “What’s my nickname?” that may be underrepresented in dense embeddings. Each path is reranked separately, final quotas are allocated per path, and the results are merged. For reranking, VikingMem uses efficient multi-vector late interaction inspired by ColBERT, with token-level vectors stored per item and compression techniques such as quantization and token merging to keep storage overhead comparable to dense vectors while maintaining p99 latencies in the hundreds of milliseconds (Fu et al., 28 May 2026).

Temporal weighting and business priors modulate base retrieval scores. With age $\Delta = T - t_m$, a freshness tolerance window $\tau$, and decay rate $\lambda$, temporal scoring is defined as

$$S_{\text{time}}(m)= \begin{cases} 1, & \Delta \le \tau,\ e^{-\lambda (\Delta - \tau)}, & \Delta > \tau. \end{cases}$$

Larger $\lambda$ emphasizes recency, while smaller $\lambda$ increases long-tail persistence. Business importance can be supplied either by type-level weighting or by an instance-level numeric weight extracted into the event schema. The stated tuning guidance is explicit: increase $\lambda$ to emphasize recency, choose $\tau$ based on task dynamics, allocate higher $w_{\text{time}}$ for conversational continuity, and higher $\Delta = T - t_m$0 for business-critical memory prioritization.

Temporal compression is topic-wise. Events carry topic metadata derived during segmentation, and VikingMem groups them by topic and orders them chronologically to form timelines. TIME_COMPRESS maintains a recency window and an aging window; when older events exceed a count or time threshold, it synthesizes a summary via LLM_MERGE-style prompts, persists the summary, and assigns TTLs to low-level events. If later recalls cite older events, pruning can be deferred through reinforcement. The design goal is stated in human-memory terms: high-fidelity near-term memory and compact thematic long-term memory. This distinguishes VikingMem from systems that either retain full context or discard history without structured consolidation.

4. Directory semantics, TrieHI, and OpenViking realization

In OpenViking and related ByteDance infrastructure, VikingMem is also described as a directory-aware memory layer built atop ByteDance’s Viking vector search engine and its open-source derivative, OpenViking. The relevant formal model treats the namespace as a rooted directory tree $\Delta = T - t_m$1, where each directory node has a segment name and root is /. A path $\Delta = T - t_m$2 resolves to a node $\Delta = T - t_m$3 by following segment labels from root. Child(v) denotes immediate child nodes, Local(v) entries directly bound to $\Delta = T - t_m$4, and Inc(v) the inclusive set of entries in $\Delta = T - t_m$5’s subtree. TrieHI maintains the invariant

$\Delta = T - t_m$6

This invariant underlies directory-recursive retrieval and subtree-local maintenance (Wang et al., 15 Jun 2026).

DSQ and DSM are the two first-class operators. DSQ scopes vector search by a directory path and a recursion flag. For recursive DSQ, the candidate set is $\Delta = T - t_m$7; for non-recursive DSQ, it is $\Delta = T - t_m$8. In both cases, the candidate set and query vector are passed to Viking’s ANN executor, either PG or IVF; DSQ is explicitly independent of the ANN index. DSM handles structural updates such as [MOVE](https://www.emergentmind.com/topics/move), MERGE, insert, delete, and rename. For MOVE, a subtree rooted at $\Delta = T - t_m$9 is relocated to a new parent $\tau$0, parent pointers are updated, and ancestor aggregates are adjusted by removing the moved set from old-only proper ancestors and adding it to new-only proper ancestors. For MERGE, non-conflicting children move as whole subtrees, conflicting names are recursively merged, and ancestor aggregates are updated similarly.

Three implementation strategies are evaluated as pluggable directory-semantic modules above Viking’s ANN indexes. PE-Online stores only exact parent membership and resolves recursive scopes by query-time path expansion, yielding minimal ingestion and storage but high recursive DSQ latency and maintenance cost proportional to subtree path count. PE-Offline materializes ancestors at ingestion time, making recursive DSQ a single lookup but increasing ingestion and storage overhead and amplifying writes during maintenance. TrieHI stores topology as a prefix tree of directory segments; each node retains the segment name, parent pointer, children map, and inclusive_ids as Roaring bitmaps, plus an entry-to-node catalog. Recursive DSQ becomes path traversal followed by reading Inc(v(p)), and MOVE becomes topological relinking plus ancestor aggregate updates with complexity $\tau$1, independent of subtree path count.

OpenViking exposes these semantics as a viking:// URI-based virtual filesystem. Tiered entries such as L0 abstracts, L1 overviews, and L2 full content can be attached under shared directory scopes, allowing DSQ to retrieve L0/L1 first and recursively include L2 when evidence is required. The examples in the paper are concrete: a query q = "agentX payment bug triage" scoped to viking://projects/agentX/sessions/ with recursive = true retrieves coherent session-local context, while MOVE viking://projects/agentX/sessions/2024-06/ → viking://projects/agentX/archive/2024-06/ updates aggregates by removing set $\tau$2 from sessions’ old-only ancestors and adding it to archive’s new-only ancestors. This suggests that VikingMem’s directory layer is intended not only for organization but also for operational memory hygiene.

5. Benchmarks, latency, and end-to-end outcomes

The memory-management evaluation reported for VikingMem uses LOCOMO and LongMemEval_s. On LOCOMO, with GPT-4o-mini, VikingMem achieves an 88.83% overall LLM-Judge score with p50 approximately 0.20s and p95 approximately 0.39s; with GPT-4.1-mini, it reaches 90.12% overall. On LongMemEval, its overall score is 66.36% with GPT-4o-mini and 75.80% with GPT-4o, while latency remains low at p50 approximately 0.25s and p95 approximately 0.89s. The token-level F1-score on LOCOMO is 54.98%, compared with 53.03% for Full-Context. Ablations on LOCOMO, GPT-4o-mini, attribute a drop of 3.64 points to removing multi-vector rerank, 5.32 points to removing intelligent memory segmentation, 1.9 points to removing entity memory, and 1.91 points to removing the keyword graph. Compared to multi-pass extraction, cost changes from $\tau$30.11 for one-pass without EUA and to $0.07 for one-pass with EUA; extract time changes from 11.02s to 12.32s without EUA and to 7.42s with EUA; LLM-Judge scores remain approximately 88.8. On LongMemEval, VikingMem reduces storage tokens to 16.82% of Naive RAG, an 83.18% reduction, while increasing accuracy from 63.81 to 75.80 (Fu et al., 28 May 2026).

The directory-semantic evaluation is carried out inside ByteDance’s Viking engine using WIKI-Dir and ARXIV-Dir. WIKI-Dir contains 1.94M entries, 363,467 directories, average depth 11.95, 456 test queries, and 1,000 MOVE plus 1,000 MERGE operations with bge-m3 1024-D embeddings. ARXIV-Dir contains 2.76M abstracts with subject hierarchy average depth 2.19 and temporal hierarchy average depth 1.92, 1,000 queries, and mxb-ai-embed-large-v1 1024-D embeddings. The implementation is in C++, integrated into Viking, and evaluated on a 48-core Intel Xeon Silver 4310 @ 2.10GHz with 125GB RAM. On WIKI-Dir recursive DSQ, directory-only latency is 365,000.80 μs mean for PE-Online, 235.23 μs for PE-Offline, and 273.10 μs for TrieHI; on ARXIV-Dir recursive DSQ, the corresponding means are 1,089.20 μs, 0.12 μs, and 0.43 μs. On WIKI-Dir non-recursive DSQ, the means are 29.07 μs for PE-Online, 1,037.07 μs for PE-Offline, and 945.17 μs for TrieHI. Construction overhead versus the baseline vector index is reported as small, below 1.7% on WIKI-Dir PG, with similar behavior on IVF and ARXIV-Dir. Storage follows the expected ordering: PE-Online is smallest, PE-Offline is larger because of ancestor materialization, and TrieHI is largest because it stores trie topology and per-node aggregates (Wang et al., 15 Jun 2026).

OpenViking-based end-to-end outcomes extend these measurements into agent-memory and QA workloads. On user-memory QA with LOCOMO, OpenClaw rises from 24.20% to 82.08% accuracy, average query time drops from 95.14s to 38.8s, and total input tokens drop from approximately 392.6M to approximately 37.4M; Hermes changes from 33.38% to 82.86%, from 82.4s to 27.9s, and from approximately 79.2M to approximately 52.0M; Claude Code changes from 57.21% to 80.32%, from 49.1s to 20.4s, and from approximately 353.3M to approximately 130.0M. On HotpotQA, OpenViking top-20 records 91.00% accuracy, 12,533 tokens per QA, and 0.23s latency, whereas LightRAG records 89.00% accuracy, 28,443 tokens per QA, and 75s latency. The interpretation given in the paper is that directory scope constrains retrieval to coherent neighborhoods while adding more in-scope evidence as top-$\tau$4 grows without flooding prompts or incurring high latency.

6. Comparisons, limitations, and open directions

VikingMem is positioned against several families of systems. Relative to vector-only memory stores and Naive RAG, it is described as better suited to low-density, interleaved streams because event-centric segmentation and schema constraints yield higher-density memories, while temporal weighting and consolidation preserve long-term coherence with lower storage and token cost. Relative to Mem0 and Mem0-graph, the distinction is the Event–Entity algebra, operator library, and one-pass extraction, with graph construction overhead avoided under high-throughput writes. Relative to Zep, VikingMem is reported to achieve higher overall accuracy in the stated settings and lower latency through lightweight schemas, late-interaction rerank, and selective retention. Relative to Mirix, the contrast is explicit: Mirix may achieve comparable accuracy but incurs multi-second p95 latencies, whereas VikingMem is intended for interactive products. Relative to Full-Context, the critique is cost and irrelevant-context interference when histories become very long (Fu et al., 28 May 2026).

The directory-aware formulation introduces its own trade-offs. Expansion-based designs remain acceptable in specific regimes: PE-Online for small hierarchies, shallow queries, or minimal-storage deployments where recursive scopes are rare, and PE-Offline for frequent recursive queries in shallow, stable namespaces where ancestor updates are infrequent. TrieHI’s stated limitations are memory overhead from per-node aggregates and trie topology, non-recursive DSQ cost proportional to immediate fan-out $\tau$5, conflict-dependent MERGE cost, and bitmap operations along affected paths under very high churn, although these remain preferable to subtree-wide path remaps. On the memory-management side, identified risks include memory drift or contradictions, over-compression or information loss, noisy or interleaved dialogues, and latency-sensitive updates; the stated mitigations are schema constraints, intra-session deduplication, LLM_MERGE, intelligent segmentation, EUA, and reinforcement-aware TTL handling (Wang et al., 15 Jun 2026, Fu et al., 28 May 2026).

Both papers also provide tuning and design guidance. For memory quality, larger ingestion batches of at least 20 messages often yield better memories; TTL and compression cadence can be set weekly or monthly and tuned by topic volatility; provenance metadata and confidence support auditability and policy compliance. For directory design, shallow branches with bounded fan-out are preferred at top levels, archival namespaces such as /archive/ should be separated from active working sets, and overlapping DSM operations should be serialized with deterministic aggregate deltas and operation logs for rollback. Open questions include richer DSQ path predicates, wildcard segments, cross-directory constraints, cost-aware planning that mixes hierarchical constraints with scalar filters and hybrid dense–sparse signals, distributed TrieHI with cross-partition concurrency control, tighter vector-plus-directory indexes for path-aware pruning inside ANN, enhanced contradiction detection and automatic counterfactual updates, personalized temporal decay parameters, privacy-preserving memory with fine-grained access control and differential privacy, and schema libraries or induction tools for cross-application transfer.

Taken together, these formulations depict VikingMem as a layered memory system rather than a single algorithm: event-centric selective extraction and operator-based entity evolution define the Memory Base, while DSQ, DSM, and TrieHI provide a directory-semantic substrate for coherent retrieval and maintenance in OpenViking-style agent memory.