Hermes Agent memory providers compared
A sourced comparison of the memory providers available to Hermes Agent: the built-in MEMORY.md store, Honcho, Mem0, Hindsight and MemorySync. Covers licensing, self-hosting, how each one scopes memory, and the failure modes worth testing before you commit.
Capabilities side by side
| Capability | Built-in (MEMORY.md)source | Honchosource | Mem0source | Hindsightsource | MemorySyncsource |
|---|---|---|---|---|---|
| Licence & hosting | Ships with Hermes | Open source, with a managed service | Open source, with a managed platform | MIT licensed, with Hindsight Cloud | Managed service |
| Self-host option | Yes — local files | Yes | Yes | Yes — Docker or pip | No |
| Managed option | No | Yes | Yes | Yes | Yes |
| What scopes a memory | The active profile | Peers | user_id, agent_id, run_id, app_id | bank_id | Tenant, project, end user |
| Search across past sessions | No — snapshot at session start | Yes | Yes | Yes | Yes |
| Usable outside Hermes | No | Yes — any model or framework | Yes — REST, SDKs, OpenAI-compatible | Yes — REST and framework plugins | Yes — REST and remote MCP |
Every cell states only what that project publishes about itself; each column header links to the source so you can check it. Capability tables age badly — if anything here is out of date or wrong, tell us at team@memorysync.io and we will correct it.
Which one fits your situation
- Built-in (MEMORY.md)
- One agent, one person, no search requirement. Genuinely the right answer more often than provider comparisons admit — there is no service to operate and the memory is a file you can read and edit yourself.
- Honcho
- Deep per-user profiles that evolve on their own. Its background reasoning builds a richer picture of an individual than fact extraction does, which suits assistants serving many distinct people.
- Mem0
- Teams who want one scoping model that works the same self-hosted and managed. Its user, agent and run identifiers map cleanly onto most application shapes, and being already in Hermes’ plugin tree makes it the lowest-friction provider to try.
- Hindsight
- Teams who want a fully open stack without giving up managed convenience later. It is MIT licensed and self-hosts via Docker or pip with embeddings and reranking running locally, so a self-hosted server needs no external calls — and Hindsight Cloud exists if you would rather not operate it.
- MemorySync
- Several tenants on one deployment, or anywhere you have to answer for what the agent knew and when. Row-level isolation and an immutable audit log are the reasons to accept a managed dependency.
Test these before you commit to any of them
Every failure below is one that passes a happy-path demo and shows up weeks later. None of them take more than a few minutes to check.
Writes lost silently at session teardown
Providers that extract facts on a background thread after the turn ends can have that work cancelled when the session closes, and it usually fails into a log line nobody reads. End a session immediately after a turn containing a distinctive fact, restart, then ask for that fact.
A new session reusing the previous one
Run /new on a messaging gateway, then ask about something from before it. If the agent still knows, sessions are being pooled and per-conversation isolation is not what you assumed.
Benchmark runs polluting real memory
Run a short prompt suite against a throwaway profile, then inspect what got stored. Test chatter that becomes long-term memory will resurface in real conversations weeks later.
Stale memory outranking current instructions
Put a distinctive rule in AGENTS.md, store a conflicting older memory, then ask for the behaviour. If the memory wins, retrieval has no notion of one fact superseding another.
One shared memory across separate conversations
Run the same agent in a private DM and a group chat. Mention something sensitive in the DM, then ask about it in the group. This is the failure that matters most and the easiest to check.
Why teams choose MemorySync
- Tenant isolation is enforced by Postgres row-level security, so a query that omits the tenant filter is refused by the database rather than silently returning another tenant’s rows.
- A superseded fact can be closed out explicitly, so retrieval stops returning it instead of ranking it against the current one by recency.
- Every read and write is recorded in an immutable audit log, which is what makes "what did the agent know, and when" answerable after the fact.
- One store serves Hermes, Cursor and Claude Code over REST and a remote MCP endpoint, so there is no per-client adapter to maintain.
Moving from Hermes Agent memory providers
- 1
Set `memory.provider` in your Hermes profile and supply the endpoint plus an API key.
- 2
Scope writes per end user with the `X-End-User-ID` header so one gateway serving several people does not pool their memory.
- 3
Backfill existing MEMORY.md and USER.md content as ordinary memories before switching over, so nothing is stranded in the old store.
- 4
Verify with a real restart: end the session, restart the gateway, and confirm the agent still answers a question that depends on the earlier turn.
Common questions
Do I need an external memory provider for Hermes Agent?
Not for single-user use. The built-in MEMORY.md and USER.md files are loaded from your active profile and handle preferences and project facts well. A provider earns its place once you want search across past sessions, separation between several people sharing one gateway, or a store that other tools can read too.
How do Hermes memory providers scope memory between users?
Each uses a different identifier: Honcho models participants as peers, Mem0 scopes by user, agent and run ids, Hindsight uses a bank id, and MemorySync scopes by tenant, project and end user. The built-in store is tied to the active profile, so one gateway serving a DM and a group chat shares memory unless you run separate profiles. Whichever you pick, test the boundary yourself before deploying beyond personal use rather than relying on the identifier name.
Can memory writes be skipped for evaluation runs?
This matters more than it sounds: running a prompt suite against a real profile writes every test prompt into that user's long-term memory, and those conclusions later surface in real conversations. Confirm your provider can suppress writes while still allowing reads, because an all-or-nothing switch means your benchmark no longer measures the configuration you deployed.
What happens to memory when a Hermes session ends?
It depends on whether extraction is synchronous. Providers that extract facts on a background thread after the turn completes can have that work cut short when the session tears down, and the loss is usually silent. Test it directly rather than trusting the happy path.
Comparisons
Move from Hermes Agent memory providers to MemorySync
Start on the free tier and evaluate retrieval, isolation, and governance against your own workload.
Start free. No credit card required.