Agent Memory Providers Compared: Capture Policy and Self-Hosting

Updated September 2026: added Mnemosyne and Memori, expanded Honcho and Hindsight configuration, and added a capture-policy comparison alongside the original infrastructure table.

Modern assistants still forget everything when you close the tab unless something persists beyond the context window. Agent memory providers are services or libraries that hold facts and summaries across sessions — often wired in as plugins so the framework stays thin while memory scales.

This guide compares the memory backends that ship as Hermes Agent external memory plugins — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne, and Memori — and explains how they fit into broader AI systems stacks. The same vendors appear in OpenClaw and other agent tooling via community or official integrations. The AI Systems Memory hub lists this article alongside Cognee and related guides.

For Hermes-specific bounded core memory (MEMORY.md and USER.md), freezing behaviour, and triggers, see Hermes Agent Memory System. For context on how Hermes’s native memory providers contribute to its growing adoption advantage over OpenClaw — including GitHub stars, OpenRouter token rankings, and ecosystem size comparisons — see OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026.

There is another axis that matters just as much as retrieval quality: memory governance. Providers differ dramatically in what they capture automatically, whether assistant-generated output can become durable memory, whether reflections get stored as facts, how contradictions are resolved, and whether a human can review a write before it becomes future context. For long-running agents, those differences can matter more than another few points on a recall benchmark — see Self-Reinforcing Memory Loops in AI Agents for why automatic capture can turn a generated conclusion into a future premise, and Mnemosyne for Hermes Agent: Local Memory Quickstart for a worked conservative configuration.

Hermes Agent lists ten external memory provider plugins for persistent, cross-session knowledge — the original eight plus Mnemosyne and Memori. Only one external provider can be active at a time. Built-in MEMORY.md and USER.md stay loaded alongside it — additive, not replacement.

External dependencies. Every external provider except Holographic requires at least one external service call — an LLM for memory extraction, an embedding model for semantic search, or a database like PostgreSQL for storage. These dependencies have direct implications for privacy, cost, and whether your memory stack can run fully self-hosted. Hindsight, ByteRover, and Mnemosyne bundle or eliminate the most dependencies; Honcho, Mem0, and Supermemory require the most moving parts. Where a provider supports Ollama or any OpenAI-compatible endpoint, you can route LLM and embedding calls to a local model and keep data off third-party servers entirely.

Activation with Hermes Agent

Command-line steps below mirror the tables in the Hermes Agent CLI cheat sheet.

hermes memory setup   # Interactive picker + configuration
hermes memory status  # Check what's active
hermes memory off     # Disable external provider

Or manually in ~/.hermes/config.yaml:

memory:
  provider: openviking  # or honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

Provider Comparison

Capture policy and governance

Storage and dependencies answer “can I run this?” The table below answers a different question that matters just as much for long-running agents: what gets written without being asked, and can a human or policy intervene before it becomes durable? See Self-Reinforcing Memory Loops in AI Agents for why this axis matters.

These are architectural risk categories, not quality scores — a carefully configured sophisticated provider can be safer in practice than a badly configured simple one.

Detailed Breakdown

Honcho

Best for: multi-agent systems, cross-session context, user-agent alignment.

Honcho runs alongside existing memory — USER.md stays as-is, and Honcho adds an additional layer of context. It models conversations as peers exchanging messages — one user peer plus one AI peer per Hermes profile, all sharing a workspace.

External dependencies: Honcho requires an LLM for session summarisation, user-representation derivation, and dialectic reasoning; an embedding model for semantic search across observations; PostgreSQL with the pgvector extension for vector storage; and Redis for caching. The managed cloud at api.honcho.dev handles all of this for you. For self-hosted deployments (Docker, K3s, or Fly.io), you supply your own credentials. The LLM slot accepts any OpenAI-compatible endpoint, including Ollama and vLLM, so inference can stay on-premises. The embedding slot defaults to openai/text-embedding-3-small but supports configurable providers via LLM_EMBEDDING_API_KEY and LLM_EMBEDDING_BASE_URL — any OpenAI-compatible embedding server works, including local options like vLLM with a BGE model.

Tools: honcho_profile (read/update peer card), honcho_search (semantic search), honcho_context (session context — summary, representation, card, messages), honcho_reasoning (LLM-synthesized), honcho_conclude (create/delete conclusions).

Key config knobs:

• contextCadence (default 1): Minimum turns between base layer refresh
• dialecticCadence (default 2): Minimum turns between peer.chat() LLM calls (1-5 recommended)
• dialecticDepth (default 1): .chat() passes per invocation (clamped 1-3)
• recallMode (default ‘hybrid’): hybrid (auto+tools), context (inject only), tools (tools only)
• writeFrequency (default ‘async’): Flush timing: async, turn, session, or integer N
• observationMode (default ‘directional’): directional (all on) or unified (shared pool)

Observation modes and self-modeling. directional, the default for fresh configurations, lets both the user and AI peers observe themselves and each other — richer dialectic reasoning, but it also means AI-authored messages contribute to Honcho’s model of the AI itself. unified is the more conservative option: the AI models the user from user messages without building the matching self-observation loop from its own output. Anyone specifically concerned about generated conclusions feeding back into future reasoning — see Self-Reinforcing Memory Loops in AI Agents — should treat unified as the safer default.

Architecture: Two-layer context injection — base layer (session summary + representation + peer card) + dialectic supplement (LLM reasoning). Automatically selects cold-start vs warm prompts.

Multi-peer mapping: Workspace is a shared environment across profiles. User peer (peerName) is a global human identity. AI peer (aiPeer) is one per Hermes profile (hermes default, hermes.<profile> for others).

Setup:

hermes memory setup  # select "honcho"
# or legacy: hermes honcho setup

Config: $HERMES_HOME/honcho.json (profile-local) or ~/.honcho/config.json (global).

Profile management:

hermes profile create coder --clone  # Creates hermes.coder with shared workspace
hermes honcho sync                   # Backfills AI peers for existing profiles

OpenViking

Best for: self-hosted knowledge management with structured browsing.

OpenViking provides a filesystem hierarchy with tiered loading. It’s free, self-hosted, and gives you full control over your memory storage.

External dependencies: OpenViking requires a VLM (vision-language model) for semantic processing and memory extraction, and an embedding model for vector search — both are mandatory. Supported VLM providers include OpenAI, Anthropic, DeepSeek, Gemini, Moonshot, and vLLM (for local deployment). For embeddings, supported providers include OpenAI, Volcengine (Doubao), Jina, Voyage, and — via Ollama — any locally served embedding model. The openviking-server init interactive wizard can detect available RAM and recommend suitable Ollama models (e.g. Qwen3-Embedding 8B for embeddings, Gemma 4 27B for VLM) and configure everything automatically for a fully local, zero-API-key setup. No external database is required; OpenViking stores memory in the filesystem.

Tools: viking_search, viking_read (tiered), viking_browse, viking_remember, viking_add_resource.

User memory versus agent memory. OpenViking’s identity model can separate the user’s memory namespace from an optional assistant peer. That separation matters for memory hygiene: facts about the user and experience generated by the agent do not need to share the same retention policy, which is a useful property if you want to isolate assistant-authored state from user-authored state.

Setup:

pip install openviking
openviking-server init   # interactive wizard (recommends Ollama models for local setup)
openviking-server
hermes memory setup  # select "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Best for: hands-off memory management with auto extraction.

Mem0 handles memory extraction server-side via an LLM call on every add operation — it reads the conversation, extracts discrete facts, deduplicates, and stores them. The managed cloud API handles all infrastructure. The open-source library and self-hosted server give you full control.

External dependencies: Mem0 requires an LLM for memory extraction (default: OpenAI gpt-4.1-nano; 20 providers supported, including Ollama, vLLM, and LM Studio for local models) and an embedding model for retrieval (default: OpenAI text-embedding-3-small; 10 providers supported, including Ollama and HuggingFace for local models). Storage uses Qdrant at /tmp/qdrant in library mode, or PostgreSQL with pgvector in self-hosted server mode — both can run locally. A fully local, zero-cloud Mem0 stack is achievable: Ollama for LLM, Ollama for embeddings, and a local Qdrant instance, all configured via Memory.from_config.

Mem0 is fundamentally an extraction system: an LLM transforms conversational material into discrete memories and performs deduplication and update logic. That is convenient, but it means extraction provenance matters — a generated assistant conclusion can become structurally indistinguishable from a user-stated fact unless the capture path filters it out before extraction runs.

Tools: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # select "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Best for: knowledge graph-based recall with entity relationships.

Hindsight builds a knowledge graph of your memory, extracting entities and relationships. Its unique reflect tool performs cross-memory synthesis — combining multiple memories into new insights. Recall runs four retrieval strategies in parallel (semantic, keyword/BM25, graph traversal, temporal), then merges and re-orders results using reciprocal rank fusion.

External dependencies: Hindsight requires an LLM for fact and entity extraction on retain calls, and for synthesis on reflect calls (default: OpenAI; supported providers include Anthropic, Gemini, Groq, Ollama, LM Studio, and any OpenAI-compatible endpoint). The embedding model and cross-encoder reranking model are bundled inside Hindsight itself — they run locally within the hindsight-all package and require no external API. PostgreSQL is also bundled with the embedded Python installation via a managed pg0 data directory; you can alternatively point Hindsight at an external PostgreSQL instance. For a fully local, zero-cloud setup, set HINDSIGHT_API_LLM_PROVIDER=ollama and point it at a local Ollama model — retain and recall work fully; reflect requires a tool-calling-capable model (e.g. qwen3:8b).

Tools: hindsight_retain, hindsight_recall, hindsight_reflect (unique cross-memory synthesis).

Setup:

hermes memory setup  # select "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Auto-installs hindsight-client (cloud) or hindsight-all (local). Requires >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud or local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (default)

Local UI: hindsight-embed -p hermes ui start

For conservative memory hygiene, setting auto_retain=false while leaving auto_recall=true is worth considering — semantic recall stays available, but completed turns no longer enter long-term memory automatically. Treat reflect output as derived knowledge synthesized across memories, not as an independent observation with the same evidentiary weight as the memories it was built from.

Holographic

Best for: privacy-focused setups with local-only storage.

Holographic uses HRR (Holographic Reduced Representation) algebra for memory encoding, with trust scoring for memory reliability. No cloud dependency — everything runs locally on your own hardware.

External dependencies: None. Holographic requires no LLM, no embedding model, no database, and no network connection. Memory encoding is done entirely through HRR algebra running in-process. This makes it unique among every provider in this comparison — it is the only one that operates with zero external calls. The trade-off is that retrieval quality is lower than embedding-based semantic search, and there is no cross-memory synthesis like Hindsight’s reflect. For users where privacy and zero-dependency operation are non-negotiable, Holographic is the only option that delivers that unconditionally.

auto_extract defaults to false, so Holographic can operate primarily as a small explicit fact database with trust scores rather than an autonomous transcript-to-memory pipeline. Combined with its zero dependencies, that makes it one of the two simplest options — alongside Mnemosyne — for readers who deliberately do not want automatic capture.

Tools: 2 tools for memory operations via HRR algebra.

Setup:

hermes memory setup  # select "holographic"

RetainDB

Best for: high-frequency updates with delta compression.

RetainDB uses delta compression to efficiently store memory updates and hybrid retrieval (vector + BM25 + reranking) to surface relevant context. It’s cloud-based with a $20/month cost, with all memory processing handled server-side.

External dependencies: RetainDB’s LLM calls, embedding pipeline, and reranking all run on RetainDB’s own cloud infrastructure — you supply only a RETAINDB_KEY. Memory extraction uses Claude Sonnet server-side. There is no self-hosting option and no local mode. All conversation data is sent to RetainDB servers for processing and storage. If data sovereignty or offline operation matters for your use case, this provider is not suitable.

Tools: retaindb_profile (user profile), retaindb_search (semantic search), retaindb_context (task-relevant context), retaindb_remember (store with type + importance), retaindb_forget (delete memories).

RetainDB’s Hermes integration has grown beyond a remote memory database — it now includes dialectic synthesis and an agent self-model, which puts it architecturally closer to Honcho than to a simple vector store. That is useful for continuity but also raises the importance of separating source facts from generated interpretation, the same concern that applies to Honcho’s directional mode.

Setup:

hermes memory setup  # select "retaindb"

Mnemosyne

Best for: local-first memory with granular retention controls, inspectable SQLite storage, structured facts, temporal memory, and configurable consolidation.

Mnemosyne is not one of Hermes’ original bundled memory providers — it ships as a separate Hermes provider plugin but integrates through the same MemoryProvider interface. Its main advantage is control: conversation autosave can be restricted by role or disabled entirely with sync_roles: [], tool-result logging is off by default, explicit remember/recall/forget operations remain available regardless, and newer versions include optional self-echo suppression around context-compression boundaries.

External dependencies: None for the core install; the embeddings extra adds local vector search. Storage is local SQLite with FTS5 and optional vector retrieval. The system also maintains working memory, episodic memory, structured facts, temporal triples, canonical facts, and consolidation.

Mnemosyne also implements provider-specific staged writes for Hermes memory.write_approval, although external-provider approval is not yet standardized across Hermes, so this path should be tested against the exact versions being deployed. The additional sophistication has a cost: derived memory creates more lifecycle states to inspect and clean up. Recent Mnemosyne releases have specifically tightened conflict validation, delete behavior, and self-echo handling — see Self-Reinforcing Memory Loops in AI Agents for the production audit that motivated the conflict-validation change.

Setup:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

For full installation and a conservative configuration walkthrough, see Mnemosyne for Hermes Agent: Local Memory Quickstart.

Memori

Best for: agents where execution history matters as much as conversation history.

Memori is a newer Hermes integration focused on tool-aware structured memory. It captures completed turns together with available execution context — tool usage, workflow steps, decisions, outcomes, and constraints — which is excellent for remembering operational work but also creates a larger feedback surface, since actions, model decisions, and tool outcomes can all become durable structured memory.

Unlike providers that primarily inject a large memory block before every turn, Memori exposes explicit recall and recall-summary tools, letting the agent retrieve operational context when it actually needs it rather than on every prompt. That reduces prompt pollution but does not remove write-side feedback risk on its own — completed turns and execution traces can still be captured automatically in the background, so Memori suits users who want an agent to learn from previous work more than it suits installations requiring strict explicit-only retention.

Setup:

pip install hermes-memori
hermes memory setup  # select "memori"

ByteRover

Best for: local-first memory with human-readable, auditable storage.

ByteRover stores memory as a structured markdown context tree — a hierarchy of domain, topic, and subtopic files — rather than embedding vectors or a database. An LLM reads source content, reasons about it, and places extracted knowledge into the right location in the hierarchy. Retrieval is MiniSearch full-text search with tiered fallback to LLM-powered search, with no vector database required.

External dependencies: ByteRover requires an LLM for memory curation and search (18 providers supported, including Anthropic, OpenAI, Google, Ollama, and any OpenAI-compatible endpoint via the openai-compatible provider slot). It requires no embedding model and no database — the context tree is a local directory of plain markdown files. Cloud sync is optional and used only for team collaboration; everything works fully offline by default. For a fully self-contained local setup, connect Ollama as the provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) and no data leaves your machine.

Hermes exposes auto_extract: false for disabling automatic curation hooks, which puts ByteRover close to Holographic and Mnemosyne in the group of providers where automatic capture is opt-in rather than default.

Tools: 3 tools for memory operations.

Setup:

hermes memory setup  # select "byterover"

Supermemory

Best for: enterprise workflows with context fencing and session graph ingest.

Supermemory provides context fencing (isolating memory by context) and session graph ingest (importing entire conversation histories). It automatically extracts memories, builds user profiles, and runs hybrid retrieval combining semantic and keyword search. The managed cloud API is the primary deployment target.

External dependencies: Supermemory’s cloud service handles all LLM inference and embedding server-side — you supply only a Supermemory API key. Self-hosting is available exclusively as an enterprise plan add-on and deploys to Cloudflare Workers; it requires you to provide PostgreSQL with the pgvector extension (for vector storage) and an OpenAI API key (mandatory, with Anthropic and Gemini as optional additions). There is no Docker-based or local self-hosting path — the architecture is tightly coupled to Cloudflare Workers edge compute. For users who need full data sovereignty without an enterprise contract, this provider is not the right choice.

The current Hermes integration writes a full session through Supermemory’s conversation endpoint as a unit, buffering the conversation and ingesting it at session end, reset, or compression. That produces richer entity and profile context than isolated fact writes, but it also means generated assistant text is part of the material presented to the memory extraction pipeline, not just user statements.

Tools: 4 tools for memory operations.

Setup:

hermes memory setup  # select "supermemory"

How to choose

Rather than picking one global winner, match the provider to the job:

• Simplest local explicit memory: Holographic — zero dependencies, auto_extract off by default
• Local memory with richer lifecycle controls: Mnemosyne — SQLite, granular retention, self-echo suppression
• Graph-heavy synthesis: Hindsight — knowledge graph plus reflect
• Peer or user modeling: Honcho — dialectic reasoning, unified mode for conservative self-modeling
• Filesystem-style knowledge: OpenViking — tiered viking:// hierarchy
• Hands-off automatic extraction: Mem0 — zero-config LLM-based fact extraction
• Operational/tool-aware memory: Memori — turn and execution-trace capture
• Human-readable, auditable, no embedding pipeline: ByteRover — plain markdown context tree
• Enterprise context fencing: Supermemory — session graph ingest, Cloudflare-hosted
• High-frequency updates, no self-hosting needed: RetainDB — delta compression, dialectic self-model

For full profile-by-profile provider configurations and real-world workflow patterns, see Hermes Agent production setup.

The wider third-party Hermes memory ecosystem

Hermes documents a package/plugin interface for external memory providers, including user-installed directories and Python entry points, so the ecosystem now extends past the providers with full sections above. A few are worth knowing about without adding a full section each:

• Scope Recall treats SQLite as durable truth while keeping raw conversation capture scoped separately, with an optional turn-closure-audit companion for conservative post-turn review — it separates raw journal evidence from durable semantic memory instead of treating every captured turn as immediately equivalent long-term knowledge.
• Cognee is a knowledge-graph / ECL ingestion pipeline rather than a Hermes conversational-memory plugin. It excels at structured project or institutional memory but is more automatic than an explicit fact store; see the Self-Hosting Cognee quickstart and Choosing the right LLM for Cognee rather than treating it as a drop-in Hermes provider.
• AgentMemory emphasizes source events, auditability, and deletion semantics — relevant after the orphaned-derived-record issues discussed for Mnemosyne above.
• XMemo ships conservative defaults: automatic timeline capture can stay off, and deletion can be constrained. Adoption is still early enough that it does not yet warrant a full section.

Related guides

• AI Systems Memory hub — scope of this subcluster and links to Cognee guides
• Self-Reinforcing Memory Loops in AI Agents — why capture policy and approval gates matter, in depth
• Mnemosyne for Hermes Agent: Local Memory Quickstart — full installation and conservative configuration for the Mnemosyne provider covered above
• Hermes Agent Memory System — core two-file memory before plugins
• Hermes Agent production setup — profile wiring for providers in practice