How to Make Hermes Agent Memory More Powerful with Membase

Hermes Agent gets the memory primitives right, but its built-in memory is intentionally small.

Hermes keeps persistent MEMORY.md and USER.md files, injects them into the system prompt at session start, gives the agent a memory tool for updates, and can search past conversations with session_search.

That is a useful foundation, but it is deliberately bounded. MEMORY.md is limited to 2,200 characters, and USER.md is limited to 1,375 characters. Hermes is designed to keep only the most important facts in prompt memory, not every decision trail, source, follow-up, and relationship from long-running work.

As your Hermes agent becomes part of real work, memory stops being only about keeping a few critical facts in context. The harder problem becomes recall: bringing back the right decision, source, relationship, and follow-up at the exact moment the agent needs them.

That is where Membase makes Hermes more powerful. Hermes stays your agent runtime and keeps its built-in memory. Membase adds a persistent memory provider that can recall connected context before the turn, capture new outcomes after the work, and mirror built-in memory writes into a durable backend.

The difference is easiest to feel in the answer:

• Hermes only: uses prompt memory and session search, then reconstructs the decision from the available context.
• Hermes with Membase: returns compact recalled context with the decision, source, related people, and next step before the answer.

How Hermes memory works today

Hermes' persistent memory docs describe built-in memory as bounded, curated memory that persists across sessions.

The core pieces are:

• MEMORY.md for the agent's personal notes, environment facts, conventions, and things learned, capped at 2,200 characters
• USER.md for user profile, preferences, communication style, and expectations, capped at 1,375 characters
• the memory tool for adding, replacing, and removing memory entries
• session_search for searching past CLI and messaging sessions stored in SQLite

Both memory files live under ~/.hermes/memories/ and are injected into the system prompt as a frozen snapshot at session start. That frozen snapshot is intentional: it keeps the prompt stable for performance. If the agent writes memory during a session, the file is updated immediately, but the prompt snapshot does not change until the next session.

Hermes also has a first-class external memory provider system. The memory providers guide is important because it shows the intended extension model: built-in memory always stays active, while a provider can inject context, prefetch relevant memories, sync conversation turns, extract memories at session end, mirror built-in writes, and expose provider-specific tools.

The strength is focus. Hermes keeps high-signal facts in bounded prompt memory, and it can search past sessions when needed. The tradeoff is capacity and continuity: deeper recall still depends on finding, summarizing, and reconnecting context at the right moment.

Limits of Hermes built-in memory for long-running agents

Imagine asking your agent:

"Can you continue from what we decided about the launch plan last time?"

That is not a simple memory lookup. The agent may need to recover:

• the original decision
• the people involved
• the project it belonged to
• the follow-up that happened afterward
• whether newer context changed the plan

Hermes can handle more than a simple markdown memory file. Its built-in memory is always available, and session_search can find past conversations with full-text search and summarization. But long-running agents often need more than a tiny prompt snapshot plus on-demand session search. They need the agent to know which decision matters now, where it came from, and what changed since then.

For built-in memory alone, three practical limits show up:

1. Prompt memory is tiny by design. Hermes keeps MEMORY.md around 800 tokens and USER.md around 500 tokens so the system prompt stays focused. That is good for critical facts, but not enough for every decision trail, source, and follow-up.
2. The prompt snapshot is frozen mid-session. If the agent writes memory during a session, the file changes immediately, but the injected prompt memory does not update until the next session.
3. Session search is on-demand recall, not working memory. It can find old conversations, but the agent still has to search, summarize, and reconstruct the answer from fragments.
4. Structure has to be inferred again. People, projects, facts, decisions, and follow-ups are not automatically maintained as a reusable graph inside built-in memory.

This is not a weakness in Hermes. It is exactly why Hermes supports external memory providers. Built-in memory and provider-backed long-term memory solve different parts of the same problem.

What Membase adds to Hermes

Membase extends Hermes through the memory provider model without replacing Hermes memory.

The hermes-membase plugin adds:

• Auto-Capture for storing conversation context to Membase
• Auto-Recall before AI turns when enabled, with a maxRecallChars budget and skip logic for casual or very short messages
• Auto Wiki Recall for stable factual references when enabled
• Mirror Built-in so Hermes MEMORY.md writes are mirrored to Membase
• dedicated tools such as membase_search, membase_store, membase_profile, and wiki tools
• source, date, and timezone filters for more precise retrieval
• graph-backed memory for entities, relationships, facts, and episodes
• OAuth login through PKCE, so users do not need to manage raw API keys

The important point is that Membase does not ask you to give up Hermes' native memory model. Hermes still owns the agent runtime, prompt memory, session search, tools, skills, and workflow. Membase adds a stronger backend for the context that should survive longer, connect across sources, and return automatically when relevant.

If you already use Hermes every day, this is where Membase starts to pay off: keep built-in memory for high-signal facts, keep Auto-Capture on, enable Auto-Recall when you want context injected before responses, and let the agent build a connected memory layer while you work.

For the broader memory-system framing, our guide to agent memory beyond RAG explains why long-running agents need more than vector search. We also break down the vector-plus-graph model in Membase hybrid memory.

Better recall, structurally

Hermes built-in memory answers "What critical facts should always be in context?"

Membase helps answer "What context does this task need right now?"

Instead of treating every memory as flat text, Membase recalls episodes, facts, entities, and relationships. That matters when the agent needs to remember that a launch decision came from a meeting, that a person owned the next step, or that a later follow-up replaced the original plan.

More context across sessions, agents, and sources

Hermes already has cross-session search through its session database. Membase extends that into a provider-backed memory layer that can be reused beyond a single Hermes session.

That is useful when your context does not live in one place. A decision may start in Hermes, continue in another agent, and get clarified in a Slack thread, email, calendar event, or document later. When those sources are connected to Membase, Hermes can retrieve source-aware context instead of relying only on what was written into its small local memory.

Less manual upkeep

Membase also changes how memory gets updated.

Auto-Capture buffers conversation context and flushes it to Membase at session end, after 5 minutes of silence, or after 20 buffered messages. It also skips tiny one-off messages and only captures the primary Hermes agent context, so subagents and background contexts do not pollute long-term memory. Mirror Built-in keeps Hermes MEMORY.md writes from staying isolated in local markdown. Auto-Recall, when enabled, searches memory and wiki context before AI turns. The loop becomes less manual: the agent no longer has to rely only on what fits in prompt memory or what it remembers to search.

How Hermes and Membase work together

The best mental model is a loop:

1. Before the turn, Auto-Recall can search Membase memory and wiki context when enabled.
2. During the turn, Hermes works with its built-in prompt memory, session tools, and recalled Membase context.
3. After the turn, Auto-Capture stores the new outcome into Membase.
4. When built-in memory changes, Mirror Built-in can copy MEMORY.md writes into Membase.
5. In the background, Membase digests the captured content into episodes, entities, relationships, and facts.
6. On the next task, the updated memory can be recalled again.

That is the shift from bounded prompt memory to continuously improving working memory.

Hermes remains the agent runtime. Membase becomes the durable memory layer behind it.

Hermes only vs Hermes with Membase

Hermes is already designed to support provider-based memory extension. Membase is for the next stage: when your agent needs to remember people, projects, decisions, sources, and follow-ups across longer time horizons.

Getting started

If you are already using Hermes for real work, Membase gives it the memory layer it needs to keep getting better.

Install the Membase provider for Hermes:

uv tool install hermes-membase && hermes-membase install

Then check the connection:

hermes-membase status

For the detailed setup flow, OAuth login, Auto-Recall settings, Auto-Capture behavior, and built-in memory mirroring, read the Membase Hermes setup guide.

Create or sign in to your Membase account at app.membase.so, connect Hermes, and let your agent start building durable memory as you work.