Research report for Luci's persistent memory architecture • 7 April 2026
Why Luci keeps forgetting what she did.
Luci runs as a persistent Claude Code session with markdown memory files loaded into context. When MC tickets come in, worker sessions are spawned via mc_pickup.py. These workers complete tasks (build features, fix bugs) but never write back to the memory folder. The main session has no idea what was done.
18 markdown files loaded into context at startup. No search capability — everything goes into the context window. As memory grows, this eats tokens. No way to query "what did I do on MC-221?" without loading everything.
When Claude restarts (crash, update, session prune), only the markdown files survive. Conversation context is lost. The resumed session starts with a thin memory of who Elmar is and what's running, but no recall of recent work.
vault.db is more capable than most off-the-shelf memory solutions.
| Table | Purpose | Status |
|---|---|---|
| activity_log | What Luci did and when | Active |
| tickets / ticket_comments | MC ticket history with full conversation | Active |
| sessions | Session registry across all Claude instances | Active |
| task_runs | Scheduler execution history | Active |
| files / edges / tags | File index with relationships | Active |
| search_fts | Full-text search index (FTS5) | Active |
| heartbeats | Health monitoring | Active |
| memories (proposed) | Structured memory store for decisions, preferences, context | Missing |
8 tools researched. Ranked by fit for our scenario.
Build a thin HTTP API that wraps vault.db with memory_save, memory_search, memory_context, and session_log tools. Run on localhost. All sessions (main + workers) get memory access via MCP or HTTP.
Why: We already have the database. We just need to expose it. No new infrastructure, no learning curve, perfect fit.
Single binary, no dependencies. MCP server + HTTP API + CLI + TUI. Session tracking, project scoping, git sync between machines. Multi-session via HTTP API on port 7437.
Best for: If we want a polished, maintained tool without building from scratch. Could run alongside vault.db — engram for unstructured memory, vault.db for structured data.
Almost identical to Luci's architecture: persistent Claude Code, Telegram integration, scheduler, per-topic sessions. Rolling summaries, context re-injection, cross-platform sync.
Don't adopt: It wants to own the whole lifecycle. But read its architecture for the rolling summary + context re-injection pattern.
Lightweight (~50KB). Auto-capture via hooks. Hybrid search (FTS5 + TF-IDF). Token-budgeted context (2000 token knapsack). Secret scrubbing. But single-session only — no HTTP API for workers.
HTTP daemon on port 37800. Progressive disclosure (summary first, full on demand). Knowledge cards. Web dashboard. Multi-session via HTTP. But wants its own directory structure.
Git memory (commits as searchable history). Reasoning memory (stores WHY). HTTP control plane. More oriented toward coding decisions than operational memory.
Semantic vector search. Powerful but heavy — needs Qdrant (~2GB RAM) + Ollama for embeddings. Overkill when FTS5 covers 90% of search needs.
Built for multi-agent orchestration with shared DB. 50+ MCP tools. But overlaps heavily with our existing ticket system — would mean migrating or running in parallel.
| Solution | Multi-Session | HTTP API | SQLite | FTS5 | MCP Server | Hooks | Complexity |
|---|---|---|---|---|---|---|---|
| vault.db wrapper | Yes | Yes | Yes | Yes | Yes | Add | Low (~200 LOC) |
| Engram | Yes | Yes | Yes | Yes | Yes | No | Low (single binary) |
| Instar | Yes | Internal | Yes | Yes | No | Yes | High (full framework) |
| claude-mem-lite | No | No | Yes | Yes | Yes | Yes | Low |
| Awareness Local | Yes | Yes | Yes | Yes | Yes | No | Medium |
| Memorix | Yes | Yes | No | No | Yes | No | Medium |
| mem0 selfhosted | Partial | No | No | No | Yes | Yes | High (Qdrant+Ollama) |
| CAS | Yes | No | Yes | Yes | Yes | No | High (replaces infra) |
Every top-performing memory system shares these 5 components.
SQLite + FTS5: Fast, reliable storage with full-text search. No server needed. Concurrent reads via WAL mode.
MCP Tools: Claude queries memory on demand ("what did I do on MC-221?") instead of loading everything at startup. Saves tokens.
HTTP API: Worker sessions, scheduled tasks, and external scripts can all read/write the same memory store. Solves the multi-session problem.
Auto-Capture Hooks: SessionStart injects relevant context. Stop/PostToolUse auto-saves decisions and outcomes. No manual memory management.
Progressive Disclosure: Return summaries first (50 tokens), full content only when asked (500 tokens). Keeps context window lean.
Add a memories table to vault.db. Build a Python HTTP server (~200 lines) with MCP tools: memory_save, memory_search, memory_context, session_log. Run on localhost. Configure in Claude Code's MCP settings. Worker sessions automatically get memory access.
Claude Code hooks for SessionStart (inject relevant memories), Stop (auto-save session summary), PostToolUse (capture significant actions). This makes memory capture automatic instead of manual.
If vault.db wrapper isn't enough, add Engram alongside it. Single Go binary, zero dependencies. Use for unstructured memory and cross-machine sync (Luci <-> Lucienne). Keep vault.db for structured data.