Choosing a Memory Provider: The Decision Criteria

Introduction

Hermes ships with a built-in file-based memory system, but it also integrates with eight external memory providers (Honcho, Hindsight, Mem0, OpenViking, Holographic, RetainDB, ByteRover, Supermemory). Each provider implements a different retrieval pattern. Instead of memorizing eight feature lists, learn the three axes that separate them, and you can pick correctly even when a new provider lands.

Key Concepts

• Recall fidelity: How accurately the provider returns the right fact when asked.
• Storage cost: Both literal dollars (vector DBs) and operational cost (running a service vs editing a file).
• Latency: How long retrieval takes per turn.
• Lossiness: Whether the provider preserves original text or only a derived form.

Real World Context

A solo developer needs persistent memory across a week of work. They do not need vector search across millions of facts; they need their five preferences to be available at every session start. A consulting team building a customer support agent needs to retrieve any prior conversation by topic similarity across thousands of users. These are different problems, and they call for different providers. Picking the wrong one wastes either money or recall.

Deep Dive

The decision tree boils down to three questions:

1. How much information are you storing? Five preferences fit in a Markdown file. Five million chat turns do not.
2. How will you retrieve it? By topic similarity, by recency, by exact match, by summary?
3. What is the cost ceiling? Are you happy paying for a vector DB, or do you need this to be free and offline?

The three archetypes Hermes supports map cleanly to those three questions:

The key insight: providers are not ranked from worst to best. They serve different problems. A file-based system is better than an embedding store for the case of "five preferences I want injected into every session". An embedding store is better than a file for "three thousand customer interactions I might want to retrieve by topic next quarter".

Hermes lets you set the provider in ~/.hermes/config.yaml under the memory.provider key, and providers integrate alongside the built-in file system rather than replacing it. That means you can run the file-based provider for your identity facts and an embedding provider for your conversation archive simultaneously.

Common Pitfalls

1. Adopting an embedding provider for the wrong reason: "It is more advanced" is not a reason. If your fact set is small, the file-based system wins on simplicity and latency.
2. Confusing memory with context files: AGENTS.md and the like are project context; memory providers handle long-term knowledge accumulation. Both have their place.

Best Practices

1. Start with file-based, upgrade when you outgrow it: Most users never need anything else. Switch only when the cap becomes painful.
2. Match the provider to the retrieval pattern: If you do not retrieve by similarity, you do not need embeddings. If you do not need to summarize long histories, you do not need Hindsight.

Summary

• Hermes supports file-based, embedding-based, and summarization-based memory patterns plus eight named external providers.
• Choose by answering three questions: how much, how retrieved, at what cost.
• File-based is the default and wins for small personal fact sets.
• Embedding-based wins for large, semantically retrieved fact sets.
• Summarization-based wins for long, ordered conversation histories.

# ~/.hermes/config.yaml
memory:
  memory_enabled: true
  provider: file           # default: built-in MEMORY.md / USER.md
  # provider: honcho       # embedding-based, similarity retrieval
  # provider: hindsight    # summarization-based, lossy compression