Memory Systems
How agents remember. Six architectures, one shared context layer, three human-editable substrates.
Orthogonal Components
Six systems, five contributions: 1) Zero-infrastructure markdown (Arizuko/NanoClaw/Muaddib), 2) Hybrid retrieval (OpenClaw), 3) Horizontal scaling (ElizaOS), 4) Multi-channel fusion + graph relations (Hindsight), 5) Write-path optimization (ContextLattice). Production: markdown-first scales to $2.5B revenue (Claude Code). PostgreSQL+pgvector is the only path for 1000+ concurrent users.
What Each System Adds
Markdown-First: Zero Infrastructure
Storage: diary/YYYYMMDD.md + facts/<topic>.md + episodes/
Retrieval: ripgrep → LLM context
Embeddings: None
Contribution: Deterministic retrieval with zero infrastructure. Git-versioned, human-readable, portable. No database, no embedding API costs, no vector index.
Production: Claude Code ($2.5B revenue), OpenClaw (310k stars), Manus ($2-3B Meta acquisition). With prompt caching, reading markdown costs less than embedding + vector search for <10k files.
Implementations: Arizuko (diary/facts/episodes), NanoClaw (CLAUDE.md per group), Muaddib (3-tier chronicles).
OpenClaw: Hybrid Retrieval
Storage: SQLite + sqlite-vec + FTS5
Retrieval: 70% vector + 30% BM25, RRF merge
Embeddings: OpenAI, Gemini, local, content-hash cached
Contribution: Hybrid search catches exact keywords that pure vector misses. "That Redis migration conversation" needs BM25. Configurable weights (default 70/30).
Trade-off: Single SQLite file = zero servers but single-process bottleneck. File watcher syncs memory/ directories. No multi-process sharing.
ElizaOS: Horizontal Scaling
Storage: PostgreSQL + pgvector (or PGLite WASM)
Retrieval: Vector only (no keyword)
Embeddings: 256-3072 dims, pluggable providers
Contribution: Multi-tenancy via PostgreSQL replication. Room/world scoping, relationship tracking, multi-agent coordination (WorldEngine). Only system for 1000+ concurrent users.
Trade-off: Vector-only misses exact keywords. No BM25. PostgreSQL overhead (WAL, vacuum, pooling) vs SQLite simplicity.
Hindsight: Multi-Channel Fusion + Graph Relations
Storage: FAISS/ChromaDB + epistemic networks
Retrieval: 4-channel (semantic + BM25 + graph + temporal) → RRF
Performance: 91.4% LongMemEval
Contribution: Graph spreading activation. Epistemic networks separate world facts from experience and opinions. Configurable decay per hop. Disposition-aware synthesis (CARA: skepticism/literalism/empathy 1-5).
Novelty: ~5-8k LOC custom architecture. Temporal weighting, graph boost, 4-channel RRF fusion. Single-agent research system, not multi-tenant.
ContextLattice: Write-Path Optimization
Storage: Mongo + Qdrant + PostgreSQL-pgvector + MindsDB
Retrieval: Dual-path (fast p50: 450ms-2s + async deep)
Protocol: MCP-native (100 msgs/sec)
Contribution: Async fanout optimized for write latency → context freshness. Most systems optimize read path (retrieval precision); ContextLattice optimizes write path (queue pressure, sink freshness, staleness under load).
Architecture: Admission control → fast sinks (rollups, Qdrant, pgvector) + deep sinks (MindsDB, Letta, memory-bank). Fail-open degradation. Learning reranking via feedback.
Trade-off: Complexity: Go/Rust/Python (41 files, 212KB gateway). Complex workloads: p50=21s, 33% timeouts. On-prem/single-tenant best; multi-tenant risks noisy neighbors. → Full analysis
Convergence Pattern
All systems converge on human-readable storage (markdown, JSON, SQL text). The differentiator is retrieval: keyword (grep), hybrid (vector + BM25), pure vector (pgvector), or multi-channel (graph + temporal + semantic + keyword).
Not Differentiators
Markdown: Universal (Arizuko, NanoClaw, Muaddib, Claude Code, OpenClaw).
Embeddings: Pluggable providers are table stakes.
Git versioning: Natural consequence of text files.
Orthogonal Contributions
Hybrid retrieval (OpenClaw): Vector + keyword catches exact matches.
Horizontal scaling (ElizaOS): PostgreSQL for 1000+ users.
Graph relations (Hindsight): Spreading activation, epistemic networks, disposition synthesis.
Write-path optimization (ContextLattice): Staged retrieval for context freshness under load.
Zero infrastructure (markdown): Production-validated (Claude Code $2.5B). Costs less than vector search with caching for <10k files.
Constraint-Based Selection
| Constraint |
Pick |
| 1000+ concurrent users |
ElizaOS (PostgreSQL) |
| Exact keyword matching |
OpenClaw (70% vector + 30% BM25) |
| Graph + temporal context |
Hindsight (4-channel, 91.4% LongMemEval) |
| High write load |
ContextLattice (100 msgs/sec) |
| Zero infrastructure, <10k files |
Markdown (Claude Code $2.5B) |
Technical Trade-offs
Prompt Caching vs Embeddings
Markdown + caching < embedding + vector for <10k files. Beyond: embeddings ($0.02/M) beat LLM reads ($0.30/M cached). Breakeven: read frequency × context size.
Single-Process vs Horizontal Scaling
SQLite = zero servers, single-process bottleneck. PostgreSQL = ops overhead (WAL, vacuum, pooling) but horizontal scaling. Architecture determines max users.
Hybrid vs Pure Vector
Pure vector misses exact keywords. Hybrid (70% vector + 30% BM25) catches semantic + precise terms. Trade-off: BM25 index overhead.
Production Validation
Markdown-first: Claude Code ($2.5B), OpenClaw (310k stars), Manus ($2-3B Meta). MEMORY.md, ripgrep, zero database.
Multi-channel: Hindsight 91.4% LongMemEval (4-channel RRF). Research, not multi-tenant.
Horizontal scaling: ElizaOS PostgreSQL + pgvector. Only 1000+ concurrent system. Web3-native (20K+ stars, $20B+ ecosystem).
Shared Context Layer
The architectures above define how agents store and retrieve memory internally. Shared context layers sit upstream: they aggregate external context (meetings, conversations, tool outputs) and feed it into agent memory systems via protocols like MCP.
Memory Store: Organizational Memory Fabric
Architecture: Cross-tool aggregation for team organizational memory. Syncs Fathom (meetings), Slack (conversations), Granola (notes), Claude/Codex AI outputs. Background organization by project, person, decision. MCP protocol distribution — record in Claude, recall in Codex.
Contribution: Multi-source capture from real work streams. Shared recall across agents and human tools. Memory portable across model/client boundaries. SaaS, 1-12 users. YC P26 (2026).
Distinction: Memory Store is adjacent infrastructure that feeds context into agent memory, not a storage/retrieval architecture. Complements existing systems (OpenClaw, ElizaOS) by providing cross-tool passive ingestion layer.
Use if: Team coordination, passive tool sync (Fathom/Slack/Granola), MCP clients (Claude/Codex/Cursor), organizational knowledge fragmentation.
Do not use if: Self-hosted required, single-agent focus, local-only episodic memory, or need control over storage layer.
memory.store | Setup guides
Human-Editable Memory Substrates
All memory systems store human-readable formats. Question: can humans edit without breaking the agent? "Breaking" = parse errors, referential inconsistency, or behavioral drift. Three patterns for transparent external memory (directly inspectable and editable files containing durable facts, notes, task context) compared to non-editable systems (vector stores, opaque DBs):
LLM Wiki
Pattern: Hierarchical markdown (directory tree + explicit links), agent-driven writes
Write safety: No built-in locking, schema enforcement, or conflict resolution
Sync: Manual, no automatic merge; concurrent edits may overwrite
Generic wiki for agent knowledge (durable facts, notes). Human edits possible. Agent may attempt to repair inconsistencies; requires validation, diffs, human review to avoid silent corruption or hallucinated repairs.
Use if: Single-user, infrequent edits, low-stakes use case where occasional inconsistency acceptable
Do not use if: Multi-user, compliance-sensitive, or deterministic workflows required
IWE (Iterative Wiki Example)
Pattern: Workflow automation (orchestration, not memory substrate)
Write safety: N/A (delegates to git)
Sync: Git-based, workflow-specific checkpoints
Document workflow (research → draft → review), not persistent memory. Edits are workflow checkpoints, not durable state. Different use case from memory substrates.
Use if: Document pipelines, structured workflows, version control required
Do not use if: Need persistent agent memory or arbitrary human edits
files.md Convention
Pattern: Predefined schema (user.md, goals.md, work.md) + file contracts
Write safety: Sync primitives (push/pull), conflict detection via timestamps
Sync: Bidirectional merge, explicit protocol
Structured memory with defined parsing contracts (users.md = profiles, diary.md = append-only log). Sync guarantees: conflicts observable, no silent overwrites. Anti-Second-Brain: bounded memory, no note sprawl.
Use if: Co-editing, write-safety needed, predictable layout required
Do not use if: Need freeform note-taking or vector-based retrieval
Substrate Comparison
| Axis |
LLM Wiki |
IWE |
files.md |
| Readability |
Markdown |
Markdown |
Markdown |
| Editability |
Direct, no guardrails |
Workflow checkpoints |
Direct + sync |
| Write Safety |
No built-in protection |
Git (external) |
Timestamp-based conflict detection |
| Retrieval |
Grep or agent |
Workflow-specific |
Grep + known paths |
| Provenance |
Git (if used) |
Git per step |
Git (if used) |
| Schema |
Freeform |
Workflow-enforced |
Predefined contracts |
| Portability |
Text (max) |
Text + git |
Text + sync |
files.md Contribution
Predefined structure: File contracts (user.md, work.md, goals.md, diary.md) with known schemas and parsing contracts. Agent knows what to expect in each file. Not wiki sprawl.
Sync primitives: Explicit push/pull protocol, timestamp-based conflict detection, merge strategies (append-only vs overwrite per file). Concurrent writes detectable, not silently lost.
Anti-Second-Brain: Bounded memory. No unlimited notes. Implementation-specific details (exact parsing, ownership boundaries, write protocol) vary by system.
files.md in Arizuko
Arizuko implements files.md at /home/node/:
| File |
Purpose |
Write |
users/<id>.md |
Profiles, preferences, context (frontmatter + notes) |
Append notes, merge frontmatter |
work.md |
Tasks, blockers, next steps (session checkpoint) |
Overwrite on exit |
diary/YYYYMMDD.md |
Daily log (immutable after date) |
Append today, read-only past |
facts/<topic>.md |
Research (verified_at, sources) |
Upsert if stale |
goals.md |
Objectives (human-written, agent-read) |
Human only |
Sync (success case): User edits goals.md at 14:00. Agent run at 14:01: /resolve reads new goals, appends diary/20260519.md. No conflict—different files, append-only.
Conflicts (detection): User edits users/alice.md at 14:00. Agent edits same file at 14:01 (cached read from 13:59). Agent sees timestamp mismatch on write → surfaces conflict to operator. Unlike LLM Wiki (silent overwrite), conflicts observable.
When Editability Matters
Database (ElizaOS, ContextLattice): SQL queries or admin tools. Not directly inspectable in text editor. Opaque to casual inspection.
Files (Arizuko, OpenClaw, Claude Code): vim diary/20260519.md. Directly inspectable and editable. Transparent.
Trade-off: PostgreSQL joins (relational queries, ACID, scale) vs vim facts/rust-hiring.md (direct edit, grep-based retrieval, single-user). Pick the constraint that matches your use case.