Saved X post research on Hermes memory systems (Kevin Simback) as a new file for future discussion.

2026-05-24 02:28:03 +00:00
parent 0b014e3e9c
commit 9801e8670e
1 changed files with 72 additions and 0 deletions
@@ -0,0 +1,72 @@
 # X Post Research: Hermes Memory Systems (Kevin Simback)
 **Source:** https://x.com/ksimback/status/2058262328496554021  
 **Author:** Kevin Simback (@KSimback)  
 **Date saved:** 2026-05-24  
 **Context:** Saved from Telegram discussion for future reference alongside the Memory-optimization-plan repo.
 ---
 ## Core Thesis
 Memory is the most important part of turning a stateless chatbot into a compounding agent. Without it, every session starts from zero. Hermes treats memory as **first-class pluggable infrastructure** with a clean 3-layer architecture.
 ---
 ## The 3-Layer Memory Stack
 ### Layer 1: Native (ships with every install, always on)
 - Two small markdown files in `~/.hermes/`:
  - **MEMORY.md** (~2,200 char cap): Project context, technical decisions, key facts.
  - **USER.md** (~1,375 char cap): Your preferences, working style, role.
 - Both files are **pasted in full** at the start of every session.
 - Managed via the `memory` tool (`add`/`replace`/`remove`).
 - **hermes_state.db** (SQLite + FTS5): Full archive of every session, tool call, reasoning step, and cost. Not injected into prompts — only searched when needed.
 - Mental model: Markdown files = always-visible sticky notes. Database = deep archive you query.
 ### Layer 2: Official MemoryProvider plugins (only one active at a time)
 Run `hermes memory setup` and pick one. They replace/augment the native layer.
 - **Honcho (Plastic Labs)**: Models *how you think* and your reasoning patterns. Builds evolving user profiles. Popular in the Hermes Discord.
 - **Mem0**: Easiest setup (API key). Automatic fact extraction + semantic search. Strong ecosystem (powers AWS Strands).
 - **Hindsight (Vectorize.io)**: Benchmark leader (91.4+ on LongMemEval). Uses four memory networks (world facts, events, opinions, observations) + multi-strategy retrieval + a "reflect" tool.
 - **Holographic**: Fully local, zero dependencies, air-gapped. Uses Holographic Reduced Representations in SQLite. Extremely fast.
 - **OpenViking**: Memory as editable files in a directory tree with tiered loading (summary → paragraph → full content). Good for cost-sensitive or human-readable memory.
 - **RetainDB**: Cheapest convenient cloud option. "Memory Router" mode for transparent operation.
 - **ByteRover**: Memory as a git repo (branch, merge, rollback). Very low token use. Strong at preventing memory loss on restarts.
 - **Supermemory**: Built for scale and low latency (sub-300ms at massive volume). Uses custom vector graph engine + "context fencing".
 ### Layer 3: Community extensions
 These are additive or alternative.
 - **GBrain (by garrytan)** — Simback's personal choice. Not a traditional MemoryProvider. It's an 8-layer knowledge engine that builds a self-wiring knowledge graph from markdown vaults (Obsidian/Logseq/Notion compatible). Features epistemology tracking, dream cycles (autonomous overnight synthesis), hybrid search, and versioned chunking. Excellent for world facts and "company of agents" setups.
 - **Mnemosyne**: Strong fully-local MemoryProvider alternative. Tiered cognitive architecture (working/episodic/scratchpad memory) with time-aware recall.
 - Others: Ladybug (importance scoring), yantrikdb (explainable retrieval), hermes-agentmemory (true deletion/privacy), PLUR (cross-agent memory sharing), FlowState-QMD (predictive warming).
 ---
 ## How to Choose & Warning Signs
 Simback recommends starting simple (often just Layer 1 is enough) and only adding complexity when you have a clear need.
 **Watch for overkill:**
 - Noticeable latency
 - Rising costs without increased usage
 - Agent contradicting itself
 - Context overflow errors
 - No measurable improvement in output quality after weeks
 ---
 ## Relevance to This Repo
 This X post research directly informs the **Three-Tier Memory System** documented in this repo's `readme.md`:
 - Hot Memory ≈ Layer 1 native + per-session injection
 - Vault Living Files ≈ Layer 3 vault-style systems (GBrain/Obsidian-style)
 - Daily Notes ≈ Searchable timeline + hermes_state.db style archiving
 The implementation using SilverBullet + Hermes native memory + cron pipelines is a practical, self-hosted realization of these concepts.
 ---
 *Research captured via x_search tool on 2026-05-24. Saved to Gitea for persistent reference.*