1 karma · joined February 21, 2026
5-level lazy loading instead of flat RAG. On spawn, agents receive only L1 — one-line summaries of every memory entry.
When something looks relevant, they drill into L2, L3, etc. on demand. This keeps startup context small (~2k tokens
for 200 entries) while still having full verbatim detail available at L5.
Tab indentation maps directly to tree levels. No schema to think about — just write:
write_memory(prefix="L", content="Always restart MCP server after recompiling TS
Running process holds old dist — tool calls return stale results
Fix: kill $(pgrep -f mcp-server)")
Indented lines become children. Siblings at the same depth are siblings in the tree. append_memory adds children to
any existing node without overwriting.
Smart bulk-read selection. Not all L1 entries are shown equally. The V2 selection expands (shows children) for: newest
N entries per prefix, most-accessed M entries (time-weighted score), and all favorites. Everything else shows as a
compact title with a [+7 →] hint. This mirrors how human working memory works — recent and frequently-used things are
immediately accessible.
Obsolete, not deleted. When a lesson turns out wrong or a decision gets reversed, you mark it obsolete with a
correction reference ([E0076]). The old entry gets hidden from bulk reads but stays searchable. Past mistakes still
teach — you just don't pay tokens for them every session.
Per-agent isolation + optional shared store. Each agent has its own .hmem SQLite file. There's also a company.hmem
with role-based access control (worker/al/pl/ceo) for knowledge that should be shared across agents.
The whole thing is a single MCP server, ~3k lines of TypeScript, backed by SQLite with WAL mode. No vector embeddings,
no external services. Works offline.
OpenClaw users: you can integrate hmem directly by pointing your Claw at the GitHub repo — it'll figure out the rest.
npx hmem-mcp init gets you running in under a minute.Some background: I run a multi-agent AI system (orchestrator + specialized agents) across multiple machines. Two things kept biting me:
1. *Context dilution:* In long sessions, earlier context gets compressed or dropped. The agent "forgets" decisions made hours ago — not because the session ended, but because the context window silently pushed them out.
2. *Vendor/machine lock-in:* I switch between Claude Code, Gemini CLI, and OpenCode depending on the task. And I work on two PCs. CLAUDE.md only works in Claude Code, on one machine. There was no way to carry knowledge across tools or devices.
hmem solves both: it's a single .hmem file (SQLite) that any MCP-compatible tool can read/write. Same memory, any tool, any machine.
The lazy loading is key — the agent never reads the database directly. It makes tool calls and gets back only what it asked for. A typical session start costs ~20 tokens for the L1 overview. Drilling into one specific topic costs ~80 tokens. Compare that to a MEMORY.md that injects 3000-8000 tokens wholesale every time.
Technical details: - SQLite backend (better-sqlite3), one .hmem file per agent - 5-level hierarchy with dot-path addressing (e.g., L0003.2.1) - Entries are auto-timestamped, support time-range queries - Full-text search across all levels - Configurable category prefixes (defaults: P=Project, L=Lesson, E=Error, D=Decision, M=Milestone, S=Skill, F=Favorite) - Favorites are always loaded at depth 2 (pinned context) - Includes integrity checks — auto-backup on corruption detection
What's next: - Cloud sync between machines (encrypted, probably git-based) - Memory forks — think GitHub repos but for agent memories (fork a curated react-patterns.hmem as a starting point) - Better onboarding docs and a demo video
This is a genuine beta — I use it daily but it hasn't been battle-tested by others yet. If you try it, I'd love to hear what breaks or what's confusing about the setup.