"Vox Memory System"

Vox Memory System

The memory system combines Codex (VoxDB) for structured, queryable data with workspace files for human-edited logs and optional exports. There is no single on-disk file for “all memory”; use the table below to pick the right tier.

Tiered persistence (SSOT by concern)

ConcernPrimary storeNotes
Structured memory facts (vox_memory_save_db, agent_memory / related tables)Codex (VoxDb) — user-global or workspace journey per how-to-voxdb-canonical-storeResolved like other Codex data (VOX_DB_*, .vox/store.db default for repo MCP).
Tool-facing flat store (vox_memory_storememory/MEMORY.md)Markdown under workspace memory/Human-readable; not a substitute for relational queries.
Daily narrative logs (vox_memory_log)memory/logs/YYYY-MM-DD.mdAppend-only prose; retention is operator-managed.
Orchestrator MCP sessions (replay)Codex when a DB handle is attachedSee database-nomenclature RAM vs DB matrix.

For RAM vs database vs JSONL tradeoffs across the whole stack (A2A, sessions, training corpora), use Database nomenclature — agent SSOT.

Architecture (high level)

┌─────────────────────────────────────────────────────────────┐
│  Codex (VoxDB): structured memory, knowledge, sessions      │
│  (tier: canonical vox.db vs repo .vox/store.db — see how-to)│
└────────────────────────────┬────────────────────────────────┘
                             │
              ┌──────────────┴──────────────┐
              ▼                             ▼
    ┌──────────────────┐         ┌─────────────────┐
    │ MemoryManager    │         │ SessionManager  │
    │ (markdown logs)  │         │ (Codex events)  │
    └────────┬─────────┘         └─────────────────┘
             ▼
   memory/MEMORY.md, memory/logs/*.md

MCP Tools

ToolDescription
vox_memory_storePersist a typed memory fact to workspace markdown (MEMORY.md path)
vox_memory_recallRetrieve a fact from long-term memory by key
vox_memory_searchUnified retrieval pipeline: hybrid (BM25+vector) when available, with deterministic fallback to BM25-only and lexical substring scan
vox_memory_logAppend an entry to today's daily memory log
vox_memory_list_keysList all section keys from MEMORY.md
vox_knowledge_queryQuery the knowledge graph for related concepts
vox_memory_save_dbPersist a typed memory fact to Codex (agent_memory and related tables)
vox_memory_recall_dbRecall typed memory facts from Codex

Usage

#![allow(unused)]
fn main() {
// From Rust
use vox_db::VoxDb;

let db = VoxDb::open("path/to/db.sqlite").await?;

// Store a memory
db.store_memory("user_preference", "Use tabs for indentation").await?;

// Recall it
let val = db.recall_memory("user_preference").await?;

// Search
let results = db.search_memories("indentation").await?;
}

Compaction

When context gets large, use vox_compaction_status to check token budget. The CompactionEngine supports three strategies:

  • Summarize — condense history into a summary block
  • Drop Oldest — drop oldest entries until under budget
  • Hybrid — summarize, then drop if still over

Persistence (summary)

  • vox_memory_store → flat text in memory/MEMORY.md (workspace).
  • vox_memory_logmemory/logs/YYYY-MM-DD.md.
  • vox_memory_save_db / DB-backed tools → Codex relational tables for structured queries and search.

Storage and domain persistence

Prefer Arca-governed VoxDb operations in crates/vox-db for gamification (vox-ludus), schedules, and telemetry rather than duplicating state in unstructured logs. Markdown remains appropriate for human-curated narratives alongside Codex.