Hermes Agent already has memory, and that matters.

It keeps local context, it improves over time, and it works without forcing you into a cloud service. It also supports several external memory providers.

I still built hermes-mempalace, because none of the existing options fit my setup quite right.

I wanted something:

• local-first
• isolated by Hermes profile
• verbatim, not just extracted facts
• easy to inspect on disk
• simple enough to trust over time

That last part is the important one. I did not want a memory layer that turns conversations into an opaque pile of embeddings or summaries you cannot really audit. I wanted actual transcripts, mined into a readable structure, with no hidden server in the middle.

Why the existing options were not enough

Hermes already gives you a few paths:

• built-in memory and session context
• external providers for different use cases
• enough flexibility to adapt, if you are willing to bend your workflow around them

And to be clear, some of those options are good.

But ... I run Hermes on a headless machine at home. And I use separate profiles for different contexts. And I do not want conversation content depending on a cloud API or a separate service unless there is a very good reason.

So, the best fit had to check a few boxes:

• [x] no API key
• [x] no external server
• [x] no extra runtime I did not already want/install
• [x] storage isolated by HERMES_HOME
• [x] memory we can actually read later

That let to MemPalace, or https://mempalaceofficial.com/ (hopefully, that's the right one!)

What hermes-mempalace does

hermes-mempalace wires MemPalace into the Hermes memory provider interface.

It follows the same lifecycle as the rest of Hermes memory providers:

1. system_prompt_block() adds a short memory reminder to the prompt.
2. prefetch() can run a MemPalace search before the first model call.
3. sync_turn() buffers completed turns without slowing the chat loop.
4. on_session_end() writes buffered turns to markdown and mines them into the palace.
5. shutdown() flushes anything still waiting.

During a session, Hermes gets three tools:

• mempalace_search
• mempalace_wake_up
• mempalace_status

That gives the agent a simple pattern: find relevant past context, surface it early, and keep the full record available if you need to inspect it.

Storage is explicit

The plugin stores data under the current Hermes profile, not in some shared global bucket.

$HERMES_HOME/mempalace/palace/ # palace index
$HERMES_HOME/mempalace/conversations/ # mined transcripts as markdown
That was important to us. Profile isolation should be structural, not something you hope the config handles correctly.

Install

If you already use Hermes:

hermes plugins install abdallah/hermes-mempalace --enable
hermes memory setup

Install the MemPalace CLI:

uv tool install mempalace

Then verify everything is in place:

hermes memory status
hermes plugins list

What it feels like in practice

The main difference is not flashy.

It is that mempalace_wake_up gives Hermes useful context at the start of a session without turning the whole memory layer into a black box.

You can inspect the transcripts. You can search them. You can open the directory and see what happened. If you want to prune or review something, you are not fighting the system.

That is the part I cared about most.

Hermes still keeps its built-in memory. hermes-mempalace does not replace that. It adds an archival layer on top of it. One that feels a lot more like a real notebook than a hidden model feature.

If this sounds useful

If you are already happy with Hermes memory, you probably do not need this.

But if you want:

• local-first memory
• profile-scoped storage
• verbatim transcript mining
• a readable on-disk layout
• no extra server to babysit

then hermes-mempalace may be a good fit.

The plugin is MIT licensed, and the repo is here:

https://github.com/abdallah/hermes-mempalace