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.

4.2 KiB Raw Blame History