Jonathon's AI Wiki

Hermes MemoryKit — duclamvan's 8-Layer Memory Stack for Hermes (v0.2.0, claimed 100/100 A+)

14 min read

Source: duclamvan-hermes-memorykit-readme-2026-05-22.md — full README + companion benchmark repo link, fetched 2026-05-22. Repo: github.com/duclamvan/hermes-memorykit. Version: v0.2.0 (released 2026-05-19). Stars: 1. License: MIT. Language: Python (100%). Author: duclamvan. Companion benchmark repo: github.com/duclamvan/hermes-memory-benchmarks.

Practical memory toolkit for Hermes Agent users — addresses the failure mode “my agent stops remembering after long chats, cron runs, tool calls, and context compression.” Extends Hermes’s existing three-tier memory model (Core Memory in Context / Session Search FTSS / External Memory Providers) with an opinionated 8-layer stack — LCM raw transcript → native memory → QMD/markdown wiki → entity graph → hybrid RRF router → focus brief → regression tests → nightly maintenance. Ships a Hermes-native plugin wrapper exposing four tools (memory_stack_status, memory_stack_route, memory_stack_focus_brief, memory_stack_regress) plus config templates for .env, ~/.hermes/config.yaml, and cron prompts. Author claims via companion benchmark repo: 100/100 A+ score, 27/27 retrieval checks passed, 35 Hermes profiles verified. Adoption signal caveat: 1 star, 0 forks, 5 commits, 3 days old at ingest — extremely early. Benchmark claims are self-reported. Worth tracking but not yet community-validated.

The 8-layer stack

The toolkit’s central design — quoted verbatim from the README:

raw transcript → durable notes → searchable docs → entity graph → RRF router → focus brief → regression tests → nightly maintenance
#LayerWhat it stores / does
1LCM raw transcript storeExact conversation history (Hermes’s existing LCM SQLite)
2Native memoryCompact durable facts (Hermes’s existing Core Memory)
3QMD or Markdown wikiSearchable project / user / system docs (e.g., this Karpathy-style wiki)
4Entity graphLinks people, projects, topics, files, sessions (extracted from layers 1+3)
5Hybrid RRF routerRanks candidates across all 4 sources via Reciprocal Rank Fusion
6Focus brief builderTurns ranked recall into a short, cited task brief
7Retrieval regression harnessCatches memory drift over time
8Nightly maintenanceUpdates indexes, runs health checks

The novel layers vs Hermes’s native memory model are 4 (entity graph), 5 (hybrid RRF router), 6 (focus brief), 7 (regression harness), 8 (nightly maintenance). Layers 1-3 are wrappers around Hermes primitives that already exist. The toolkit’s value is the routing layer on top.

Key Takeaways

  • The 8-layer model is the load-bearing contribution. Hermes ships layers 1-3 natively (LCM + native memory + plus-optional-Obsidian-or-Notion external memory). MemoryKit adds 4-8 — the routing and regression layer. The framing is: agents have memory features but no retrieval router and no drift detector. That gap is real and matches the operator pain points surfaced in the user-stories catalog.
  • Hybrid RRF (Reciprocal Rank Fusion) over four sources, not vector search. The router (layer 5) ranks across LCM, native memory, QMD, and the entity graph — explicitly not a single vector DB. Matches the Karpathy LLM-wiki thesis that hybrid keyword+structure beats vector-only at the hundreds-of-docs scale this wiki sits at.
  • Focus brief, not raw retrieval. Layer 6 turns ranked recall into a cited task brief — not a list of documents. That matches Anthropic’s Best Practices framing on context-as-prompt (give the agent a focused context payload, not a dump). Cites are the discipline anchor — the brief is verifiable against its sources.
  • Regression harness is the differentiator. Layer 7 — “catches memory drift” — is a primitive most agent memory toolkits don’t ship. The “we trained an eval set” discipline applied to retrieval. Without this, you can’t tell if a new memory write silently degraded retrieval quality. Pairs with the eval-first methodology from Lucas’s Code-with-Claude London talk.
  • Hermes plugin wrapper exposes 4 native tools. Once installed (install_hermes_plugin.py --hermes-home ~/.hermes --repo "$PWD" --force), the toolkit registers memory_stack_status / memory_stack_route / memory_stack_focus_brief / memory_stack_regress as Hermes-native tools. Available to skills, cron prompts, and ad-hoc invocations.
  • Promotion policy lives in docs/skills-and-memory.md. The toolkit ships an explicit doc on when to keep a fact in LCM, when to save native memory, when to write docs, when to create a skill. That’s the hardest discipline in any memory architecture — having a written rule helps. Pairs with Hermes Skill Bundles (which makes skills explicit at the bundle level).
  • Nightly cron is the maintenance heartbeat. Layer 8 runs via Hermes cron with a specific prompt template the README provides: “Run preflight token refresh first. Then run Hermes MemoryKit nightly maintenance from the repo. Summarize failures only, and include report paths.” Matches the cron daylight-savings self-correction pattern from Nate Herk’s course.
  • Hermes config snippet is small and opinionated. Two short files: ~/.hermes/config.yaml (4 lines — memory_enabled + user_profile_enabled + LCM engine + compression) and ~/.hermes/.env (4 LCM env vars — large-output externalization at 12K char threshold, transcript GC off, context threshold 0.70). Worth reading even if you don’t install the toolkit — it’s a baseline-config reference for any Hermes operator.
  • Adoption is unproven. 1 star / 0 forks / 5 commits / 3 days old at ingest. Benchmark claims (100/100 A+) are self-reported in a companion repo by the same author. Treat the architecture as a thoughtful proposal to track, not a battle-tested toolkit. Tier-1 refresh recommended in 30 days to recheck adoption signal.
  • Public-safety note is unusually thoughtful. README explicitly warns: “Do not publish your raw LCM database, private notes, session IDs, Telegram topic names, secrets, or local profile paths. Publish redacted reports and aggregate benchmark numbers only.” That’s the right anti-pattern guard for a memory-tooling project — surface-area for accidental data exfil is high if you push raw memory to GitHub.

Where this fits

Topic surfaceDescriptionRelationship
Hermes Agent topic landingPublic landing pageMemoryKit is a new operator-side surface added here
Hermes Skill BundlesSlash-command-driven skill compositionComplementary — bundles solve skill-invocation probabilism, MemoryKit solves retrieval-routing
Hermes Skins (joeynyc)Visual themes for Hermes CLIUnrelated — skins are cosmetic; MemoryKit is behavior + retrieval
Hermes Codex App-Server RuntimeRuntime delegation to Codex CLIMemoryKit tools work regardless of runtime
Karpathy’s LLM-Wiki TechniquesThe LLM-wiki patternSame retrieval-routing problem at a different layer — Karpathy pattern uses Claude Code wiki; MemoryKit packages similar discipline as Hermes plugin
Claude Code Memory Architectures ComparedBuilt-in vs memarch vs HermesAdjacent companion — that article is the Claude Code version of this comparison; MemoryKit is a specific Hermes implementation

Try It

  1. Smallest install (read-only): clone the repo, read docs/skills-and-memory.md for the promotion policy (LCM → native memory → docs → skill). Useful even without installing the toolkit — gives you a written rule for memory hygiene.
  2. Full install with verify: follow the README’s Quick Start — clone, venv, pip install -e .[dev], copy .env template, run memory_stack_verify.py --hermes-home ~/.hermes --workspace ~/my-hermes-workspace. Verify reports stack health before you depend on the toolkit.
  3. Try one query: python scripts/memory_stack_router.py "what did we decide about memory?" --json — outputs the ranked routing across LCM/native/QMD/graph as JSON. Sanity-check before installing the plugin wrapper.
  4. Install the Hermes plugin wrapper: python scripts/install_hermes_plugin.py --hermes-home ~/.hermes --repo "$PWD" --force. Add the printed MEMORY_STACK_REPO=... line to ~/.hermes/.env. Restart Hermes (/reset). Then call from any Hermes session.
  5. Wire nightly maintenance: add the README’s cron prompt to a Hermes cron job (token refresh → maintenance → failure-only summary + report paths). Pairs with the cron-creation pattern from Nate Herk’s course.
  6. Verify the toolkit’s benchmark claim: clone the companion benchmark repo and run it against your own Hermes deployment. The author claims 100/100 A+ — does it actually score that against your data? Surface any divergence as feedback.

Reddit signal — community memory-provider bake-off surfaces a NEW recommendation (Mnemosyne) (2026-05-25)

[Reddit signal — r/hermesagent 2026-05-25] Source: raw/reddit-1tms3g6.md (171 score, 76 comments, OP Lorian0x7, Memory & Context flair). OP tested every available Hermes memory provider end-to-end and lands on a recommendation that’s not currently covered by this wiki: Mnemosyne. Lorian0x7’s qualitative shake-out reads:

  • Cloud providers — rejected as a class (vendor lock-in + data retention concerns)
  • Hindsight — technically the best memory quality, but too heavy (many API calls, costly even on cheap models, hidden config knobs, “too many bugs”)
  • OpenViking — pain to set up; OP dropped halfway
  • Holographic — speed was fine, but quality was not there (“I’m still unsure if it was doing something”)
  • Hancho — pain to set up; pretty good at profiling but same heaviness issues as Hindsight
  • Mnemosyne (the OP’s winner) — “the easiest to setup, lightweight, fully local, and it’s the best balanced between quality and speed.” Stack: SQLite-based persistence (truncation cuts further detail). Not built-in by default — OP explicitly thinks it should be.

Note on MemoryKit (this article’s subject). MemoryKit is not on the OP’s tested list — Lorian0x7’s thread predates broad community awareness of duclamvan’s v0.2.0 release (toolkit was 3 days old at the wiki ingest 3 days before this signal). Don’t read the omission as a negative comparison; read it as “the field is now bigger than this thread captures.” The hybrid-RRF + entity-graph + regression-harness architecture MemoryKit ships is orthogonal to the bake-off dimensions Lorian0x7 ranks on (setup pain, weight, quality, speed) — both could co-exist or compose, with MemoryKit acting as the router on top of whatever native memory provider the operator picks.

Implication for the wiki. Mnemosyne is a tracked-but-uncovered provider as of the 2026-05-25 refresh. Worth a Tier-1 research pass to surface: (a) Mnemosyne’s repo + license + maintainer; (b) the exact SQLite schema + retrieval contract; (c) whether MemoryKit’s memory_stack_route can fuse Mnemosyne as one of its 4 sources, or whether it expects Hermes-native Core Memory specifically. Falsification candidate for this article: if Mnemosyne’s standalone performance materially exceeds MemoryKit’s claimed 100/100 A+ on the same benchmark, the value proposition of the 8-layer routing stack weakens — re-test on refresh.

Strict-bar caveat. Lorian0x7 is a self-reported operator, not a benchmark publisher. The ranking is qualitative (“kinda sucks”, “pain to setup”, “I liked the speed”). 171 score + 76 comments signals community interest in the question, not validation of the verdict. Treat as a triage map of providers worth investigating, not a tier list.

Reddit signal — Honcho as a community-built hybrid memory provider (2026-05-26)

[Reddit signal — r/hermesagent 2026-05-26] Source: raw/reddit-1to3req.md (13 score, 23 comments, OP MrGandalfSG, Setup & Installation flair). A second uncovered memory provider — Honcho — shipped as a fully-local, hybrid Gemini-orchestrated setup driving zero-token retrieval. Adjacent to the Mnemosyne signal above but a different architecture entirely. OP runs:

  • Orchestrator: Gemini-3-Flash (high-level reasoning + subagent delegation) → DeepSeek v4 Flash fallback
  • Local memory store: Honcho in Docker on WSL2 (Ubuntu), same host as Hermes
  • Local chat/reasoning: Gemma-4-e2b via LM Studio with n_parallel=2 (load-bearing — Honcho runs two processes, the API and the Deriver background-distillation worker, so single-parallel deadlocks)
  • Embeddings: EmbeddingGemma-300M at 768 dimensions, with pgvector modified from default 1536 → 768 dims to match the local embedder
  • Hardware: Legion Go + OneXGPU eGPU

The headline claim — “Zero-Token Memory: 100% locally on my machine. No internet calls, no Token fees for API retrieval” — is the load-bearing operator pitch. Worth tracking against MemoryKit’s claimed 100/100 A+ score: Honcho is a standalone provider, MemoryKit is a router on top — they could compose (Honcho as one of MemoryKit’s 4 layer-5 RRF sources) rather than compete. Falsification candidate: does MemoryKit’s memory_stack_route already support Honcho as a source, and if not, what’s the integration surface? Add to Open Questions on next refresh.

Adoption signal caveat. 13 score / 23 comments — significantly lower than the Lorian0x7 bake-off (171 / 76). Single operator with a specific hardware setup (Legion Go + eGPU + WSL2) that doesn’t generalize cleanly to most Hermes deployments. Treat as a worked configuration worth lifting patterns from (pgvector dim-matching, LM Studio n_parallel=2, Honcho’s API+Deriver dual-process architecture), not a community-validated provider recommendation.

Pointer — community setup walkthrough covering Mnemosyne and Hindsight (2026-08-07)

[Reddit signal — r/hermesagent 2026-08-07] Source: raw/reddit-1vi133v.md (31 score, 4 comments, OP u/_wanderloots, “Guide” flair). A link post to a YouTube walkthrough — “Hermes Memory Provider Setup + Agentic AI Memory Theory (Mnemosyne & Hindsight Examples & Workflows)” — at youtube.com/watch?v=R1TNGOZAOZs.

Recorded as a pointer only. The Reddit post carries no body, and the video transcript has not been pulled, so nothing about its actual content is claimed here beyond the title. It is filed because Mnemosyne is the provider the community bake-off above surfaced as its end-to-end-test recommendation, and a setup walkthrough for it is the missing practical companion to that finding — this article documents which provider people landed on, not how to stand it up.

Next action if this is worth more than a pointer: add the video to the wiki-inbox playlist so the transcript pipeline picks it up, then re-ingest. Do not cite claims from it before then.

Reddit signal — a provider-selection cheat sheet, and the checkpoint/memory distinction (2026-08-11)

raw/reddit-1vlhws0.md (r/hermesagent, 8 pts) is low-engagement but unusually clear-headed, and it answers the question this article’s 8-layer stack does not: which provider do I actually pick? The poster’s decision table, after comparing options directly:

If you want…Provider
Save user facts and preferencesMem0
Hermes to learn reusable routines from old sessionsMemU
A few important facts visible in every promptLetta
Already building around LangGraphLangMem
Relationships that change over timeGraphiti
The graph approach without self-hosting itZep

Two observations worth carrying, independent of the table:

  • “A checkpoint isn’t really long-term memory.” A checkpoint can resume a broken task, but that does not mean the agent should carry everything from that task into future conversations. This is a genuine category error the 8-layer stack above can invite, and naming it is the post’s most useful contribution.
  • Retrieval is the easy part. The poster argues the hard production questions are governance, not search: what happens when a stored fact is wrong, who is allowed to retrieve it, and can it actually be deleted? Those map onto correctness, access control, and the right to erasure — none of which any provider comparison above resolves.

Their own recommendation is conservative and matches this article’s bias: start with scoped retrieval plus task checkpoints, add graph memory only when there’s a real reason. Graph memory is called “probably overkill” for ordinary project notes and preferences.

Caveat: this is one practitioner’s comparison with no benchmark, no methodology, and no disclosure of how deeply each provider was tested. Treat the table as a starting hypothesis for your own evaluation, not a ranking.

Open Questions

  • Reproduce the 100/100 A+ benchmark. Author runs it against their own data; community has not verified. First refresh cycle should attempt reproduction or surface the benchmark methodology.
  • LCM internals. The toolkit explicitly references LCM (Long Context Memory) primitives in Hermes — LCM_LARGE_OUTPUT_EXTERNALIZATION_* env vars + engine: lcm config. Worth a dedicated wiki article on Hermes LCM if/when ingested from primary docs — current coverage is implicit.
  • Entity-graph extraction quality. Layer 4 extracts an entity graph from Markdown and LCM SQLite transcripts. What entity types, what disambiguation strategy, what schema? Unspecified in the README; would need a docs/entity-graph.md deep-dive on first refresh.
  • Hybrid RRF tuning. Layer 5 fuses ranked lists from 4 sources via Reciprocal Rank Fusion. Default RRF constant? Per-source weight tuning? Affects retrieval quality materially. Worth pulling from scripts/memory_stack_router.py on refresh.
  • Comparison against synthadoc. The synthadoc IngestAgent + Pass 3 contradiction tracking is another opinionated retrieval-discipline toolkit operating in the same problem space. Are they composable, competing, or solving subtly different problems? Worth a side-by-side once both mature further.
  • Versioning + breakage risk. v0.2.0 at fetch. The toolkit depends on Hermes-internal LCM API surface — any Hermes upstream API change could break it. Worth checking compat matrix on each Hermes release.

Graph View

Backlinks