HHermes Explained

Memory

Memory Provider

A backend that stores or retrieves memory records for the agent.

Importance 4/52 backlinks1 source refs

Memory Provider

What it is

A backend that stores or retrieves memory records for the agent.

In plain terms

A memory provider is the actual storage business working behind the scenes, the way a restaurant hands a coat to its coat-check counter instead of running its own storage room. Hermes defines a standard shape any such counter must offer — accept an item, hand it back on request, close up cleanly — and services like mem0 or Honcho each build their own version of that counter.

Why it matters

Behind the memory abstraction sits an actual storage backend — Hermes ships plugins for services like mem0, honcho, and openviking, each implementing its own retrieval logic differently. MemoryManager treats all of them interchangeably at the orchestration layer, so switching providers is a plugin swap rather than a rewrite of how memory gets used elsewhere in the agent. That separation is what lets a solo user run the lightweight built-in store while a team deployment points at a hosted provider instead.

How it works

A memory provider is any class that implements the MemoryProvider interface (agent/memory_provider.py): methods for checking whether it’s configured (is_available), connecting at startup (initialize), recalling relevant context before a turn (prefetch), and writing a finished exchange afterward (sync_turn), plus any tool schemas the model can call directly. Optional hooks let a provider react to session boundaries — on_session_end for end-of-session summarizing, on_pre_compress to preserve insights before old messages get discarded, on_memory_write to mirror something the built-in store just saved. Hermes ships plugins that fill in this interface differently: mem0 does server-side LLM fact extraction with deduplication, Honcho builds cross-session user models answerable through its own Q&A (plugins/memory/honcho/plugin.yaml), and Hindsight keeps a knowledge graph with entity resolution.

A concrete example

A household running Hermes on a small VPS decides the built-in notes file isn’t enough and installs the Honcho plugin as its memory provider.

  1. Honcho’s is_available() check confirms it’s configured (an API key, in this setup), so it activates alongside the built-in store.
  2. Before each turn, Honcho’s prefetch() pulls back a fact it inferred about the user weeks earlier, such as a recurring project deadline.
  3. When the session ends, on_session_end() flushes any turns not yet sent to Honcho’s servers, so its own cross-session modeling stays current — independent of whatever the built-in memory tool separately wrote. Swapping this plugin for mem0 later needs no changes anywhere else.

How it connects

This note belongs to the Memory family. Its closest neighboring concepts are: Memory Manager, Long-Term Memory, Agent Runtime, Personal OS.

Source evidence

  • vendor/hermes-agent/agent/memory_manager.py:505-515#MemoryManager.prefetch_all — Verified Source Map evidence for MemoryManager. MemoryManager calls prefetch on each registered provider in order, skips empty results, isolates individual provider failures, and merges the remaining text.

Workflows

  • No first-pass workflow mapping yet; this concept still appears in the vault graph through articles and source evidence.
  • Why Hermes Feels Different: Memory, Self-Improving Skills, and an Agent That Keeps Working