Hermes Agent ships nine external memory providers (the docs still say eight) and lets exactly one be active at a time, alongside the built-in MEMORY.md/USER.md pair. Combining two stores and ranking across them is issue #24418, open since 12 May, with an implementation PR #70390 filed on 23 July. For a self-hosted home lab across Health/Work/Home/Finance, run one Hermes profile per domain (each profile is its own HERMES_HOME with its own memory, cron jobs, and state DB) and start with the zero-dependency Holographic SQLite provider. And the “AI doom loop” of broken cron jobs plus false claims of a fix is a reliability problem that no backend fixes: turn checkpoints on, because they ship off.
A user on r/hermesagent asked the practical version of the question everyone building a personal assistant eventually asks: which memory provider, and can I run two and rank the results? They wanted a self-hosted assistant accumulating knowledge across Health, Work, Home, Finance, and Personal. They had already tried Honcho and given up after cron jobs quietly stopped working and the agent kept claiming it had fixed them.
Two questions are tangled there. One has a short answer. The other has a better one.
Nine providers, and the docs can’t count them
The Memory Providers page opens by promising “8 external memory provider plugins” and then lists nine in its own comparison table. Memori arrived and nobody updated the sentence. That is a fair preview of how fast this surface is moving.
For a home lab, the split that matters is what runs without a vendor:
| Provider | Self-hosted story | Notable trait |
|---|---|---|
| Holographic | Local SQLite, no dependencies at all | FTS5 search, trust scoring, contradict action for detecting conflicting facts |
| OpenViking | Own server, AGPL-3.0, from Volcengine (ByteDance) | Tiered loading, L0 ~100 tokens → L1 ~2k → L2 full |
| Mem0 | OSS mode in-process with Qdrant or pgvector + Ollama | Server-side LLM fact extraction |
| Hindsight | Local mode on embedded PostgreSQL | hindsight_reflect cross-memory synthesis |
| Supermemory | npx supermemory local on port 6767 | Context fencing, so recalled memories are stripped before capture |
| Honcho | Self-hostable, baseUrl to localhost | Dialectic user modelling, three cadence knobs |
| ByteRover | Local knowledge tree via brv CLI | Extracts insights before context compression discards them |
| RetainDB | Cloud only, $20/month | Delta compression |
| Memori | Cloud only | Tool-aware structured recall |
Holographic is the one I would start with, and the one nobody advertises, because it has no company behind it. It is a SQLite file at $HERMES_HOME/memory_store.db with features the paid ones lack: probe for entity-specific recall, reason for compositional queries, asymmetric trust feedback (+0.05 helpful, -0.10 unhelpful). Zero infrastructure, zero egress, greppable on disk.
The one-slot problem
The answer to “can I combine two and rank results” is currently no. memory.provider takes a single value, and the built-in memory always runs alongside it: MEMORY.md capped at 2,200 characters and USER.md at 1,375, injected as a frozen snapshot at session start.
The request to lift that has a clear-eyed write-up in issue #24418, filed on 12 May by a user who wanted OpenViking’s session archival next to Holographic’s structured facts: “They complement each other perfectly, but you can only pick one.” PR #70390 landed in review on 23 July with an ordered memory.providers list, after sweeping nine separate write sites where a setup hook could write the singular field while a stale list silently overrode it. It gives you ordered activation. Ranking across stores stays out of scope.
Issue #67896 shows why people want this badly enough to hack around it. A user running two agents against one Qdrant wanted a dirty catch-all store feeding a curated clean one, but retention policy is tied to the provider instance rather than to a bank inside it. Their mem0 auto-extractor produced 182 duplicate and junk entries, including literal User:/Assistant: fragments and mood states, and they wrote a “cognitive purge” script to clean the collection by hand.
Domain scoping happens at the profile
For Health/Work/Home/Finance, skip the provider question. Use profiles. A profile is a separate HERMES_HOME with its own config, SOUL.md, memories, sessions, skills, cron jobs, and state database, and creating one gives you a command: hermes profile create health gets you health chat. Four domains, four memory stores, four independent cron sets, no cross-contamination in the prompt.
Two caveats. Profiles are not sandboxes; on the default local backend the agent keeps your user’s full filesystem access. Isolation has also been leaky in practice: #6320 reported session_search returning results from a hermes-finance instance inside a general one.
If you want one identity across domains rather than four strangers, Honcho’s peer model fits best: one user peer, one AI peer per profile, one shared workspace. Supermemory does the lighter version with container_tag: "hermes-{identity}".
The doom loop was never about memory
“Doom loop” now means two different things. Liquid AI published research on 7 July on the decoding kind: a model emits “Wait” or “Alternatively”, then repeats the span until the context window dies. Their Final Token Preference Optimization cut looping on an LFM2.5-2.6B checkpoint from 10.2% of completions to 1.4%. Good work, and irrelevant here.
The OP hit the agentic kind: cron jobs silently broken, changes that break things, apologies, claimed fixes that didn’t hold. The first half is a documented Hermes bug class. Forty-nine issues in the repo carry both “cron” and “silently” in the title, including #70294 from this week, where top-level delegate_task results are dropped while the job reports ok, and #64333, where the desktop cron ticker was dead on arrival from one missing import. No memory backend fixes a ticker that reports success and delivers nothing.
The second half has real machinery in Hermes and most people never enable it:
- Checkpoints are opt-in and default to off. Enable them with
checkpoints.enabled: trueand you get automatic snapshots beforewrite_file,patch,rm,sed -i, andgit reset, into a shadow git store that never touches your project’s.git. Then/rollback diff <N>answers “did it actually change what it said it changed” without asking the agent. - The verification claims gate. PR #56556 wired stop nudges to an explicit claims gate with a verified-evidence contract, where an edit after a passing check marks the evidence stale. Trust that record over the agent’s own account of what it did.
- Cron with
deliver=localwrites to~/.hermes/cron/output/. A job that fires and delivers nowhere still runs, so an empty output directory is your signal.
Memory that confidently remembers the wrong thing
An empty store is harmless. A confidently wrong one costs you hours. Holographic’s auto_extract matches “I prefer / I like / I want” with a regex and writes the entire matched message, truncated to 400 characters, into the fact store as a fact (#22907). Session-end extraction has been forwarding raw runtime artifacts (silence markers, tool directives, special tokens) into durable memory; the sanitizer went up yesterday. And hermes memory status will report mem0 as “available” when the SDK is not installed (#70979).
My favourite is #66888. Recalled memory gets wrapped in a [System note: ... Treat as authoritative reference data] block, and on the gateway path that block arrives inside user-role message content. An operator who had hardened their persona against prompt injection watched the agent correctly identify its own memory subsystem as an attack, refuse the task, and file an intrusion report. It stayed wedged until they wrote a carve-out for their own memory layer.
The Yolo-Auto memory guide has the right line: “A system that quietly remembers the wrong thing is worse than no memory.” Turn auto_extract off. Let the agent write memories on purpose.
What I would actually run
Holographic plus a memory/ directory of markdown, one profile per domain, checkpoints on, auto_extract off, cron delivering to local with a daily heartbeat job whose absence you will notice. A weekend of setup, no vendor, no embedding pipeline, no egress. Add semantic retrieval when grep genuinely stops finding things, which takes longer than the vendors would like you to believe. Letta’s LoCoMo result, covered here previously, is still the field’s most useful data point: an agent with four filesystem tools scored 74.0%, beating Mem0’s best graph variant at 68.5%.
On the HN thread for Hermes’s persistent memory, someone posted the obligatory “looks inside MEMORY.md” joke and got the correct reply: click next on that doc link and you find nine providers. Both are right. The providers are real, and the markdown file is still doing most of the work.
Sources
- Hermes Agent docs: Memory Providers · Persistent Memory · Honcho Memory · Profiles · Checkpoints and /rollback · Cron Troubleshooting
- GitHub: #24418 multiple simultaneous providers · #70390 implementation PR · #67896 dual-store write policies · #6320 memory contamination · #22907 auto_extract raw dump · #66888 memory context as injection · #70409 transcript sanitizer
- Liquid AI: Reducing Doom Loops with Final Token Preference Optimization · antidoom-mix-v1.0 dataset
- Yolo-Auto: Memory Options for Hermes-Agent and OpenClaw-Style Agents
- Providers: Honcho · Mem0 · Supermemory self-hosting · Hindsight · ByteRover
Coverage and discussion
- Reddit: Which Hermes memory do you recommend? (r/hermesagent)
- HN: Reducing Doom Loops with Final Token Preference Optimization
- HN: Hermes Agent: open-source AI agent with persistent memory
- HN: Ask HN: Mem0 stores memories, but doesn’t learn user patterns
- HN: Agent Rigor: stop your AI coding assistant from doom-looping
Related on this blog