72 lines
4.2 KiB
Markdown
72 lines
4.2 KiB
Markdown
# 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.* |