Hermes Agent + Obsidian: Shared Memory Explained

Hermes Agent is the MIT-licensed, self-improving agent from Nous Research. Its README describes a closed learning loop: agent-curated memory with periodic nudges, autonomous skill creation, FTS5 session search with summarisation, and optional Honcho user modelling. Our complete Hermes Agent guide covers the whole product. This article zooms in on memory, because that is what the latest wave of videos is about.

• Built-in memory is small on purpose. Two files, 2,200 and 1,375 characters, injected into the system prompt once per session.
• Obsidian is a skill, not magic. The bundled skill reads and writes markdown files with ordinary file tools, using the vault path you provide.
• Providers are separate. Only one external memory provider can be active at a time, alongside the built-in files.
• Shared memory needs care. The docs say not to share one Hermes home between agents, and to use a provider or a shared vault instead.
• The "OS" branding is not Nous Research's. See our analysis of the Agent OS videos.

Bottom line: an Obsidian vault is an excellent shared, human-readable knowledge layer for Hermes, provided you treat it as a library the agent consults rather than as memory it can hold in its head.

According to the official documentation, Hermes has bounded, curated memory that persists across sessions. Two files make it up, both stored in ~/.hermes/memories/:

Those limits are tiny, roughly a page and a half of text between them, and that is deliberate. The documentation says character limits keep memory focused. Memory does not auto-compact: when a write would exceed the limit, the memory tool returns an error and the agent has to consolidate or remove entries itself in the same turn before retrying. Even a patch that lengthens an entry can overflow.

The memory tool

The agent manages memory through a single tool with three actions: add, patch and remove. There is no read action. The contents are placed in the system prompt, so the agent simply sees them. Every call names a target, memory or user, and patch and remove use short unique substring matching rather than full entry text. Entries are separated by a section sign and may span several lines.

Session search fills the gaps

Everything that does not fit in 3,575 characters lives in past conversations, which Hermes can search with a session_search tool. The docs describe the whole design as built around the moment a session ends: the two files carry the essentials forward and session search recovers detail once the old context is gone. This is the first thing to understand about Obsidian integration. The vault does not replace these files. It extends the agent's reach beyond them.

Memory is injected into the system prompt once, at session start, and never changes mid-session. The documentation says this is intentional because it preserves the model's prefix cache for performance. When the agent adds or removes an entry, the change is written to disk immediately but only appears in the prompt the next time a session starts. Tool responses always show the live state.

This has a practical consequence on messaging platforms such as Telegram and Discord. A chat there is deliberately one continuous session that survives restarts and reboots, so it can run for weeks. That is convenient, but it becomes expensive because compaction runs repeatedly over an ever-longer history, and the forget, recall and search loop rarely gets a chance to run. The documentation's advice is to run /new at natural boundaries: a finished task, a change of topic, the start of a day. On the command line every invocation is already a new session.

If you have ever told a Hermes bot something important and found it missing the next day, the frozen snapshot, an unsaved write or a profile mismatch is far more likely than a bug. We cover the diagnostic order in the troubleshooting section below.

Obsidian is a markdown note-taking app that stores notes as plain files in a folder called a vault. That design is exactly why it suits agents: there is no proprietary database, and a vault is just files you can read, edit, back up and put in Git.

What the bundled skill does

Hermes lists an obsidian skill in its note-taking catalogue. The documentation shows it as bundled and installed by default, version 1.0.0, authored by Teknium and the Hermes Agent team, MIT licensed and available on Linux, macOS and Windows. Its instructions describe filesystem-first vault work: reading notes, listing notes, searching note files, creating notes, appending content and adding wikilinks.

• Vault path: the documented convention is the OBSIDIAN_VAULT_PATH environment variable, for example set in ~/.hermes/.env. If unset, the skill falls back to ~/Documents/Obsidian Vault.
• Path hygiene: file tools do not expand shell variables, so the agent must resolve the vault path to a concrete absolute path first. Paths with spaces are a reason to prefer file tools over shell commands.
• Reading and searching: read_file for notes, and search_files for both filename and content searches, restricted to markdown with a glob.
• Writing: write_file for new notes, and anchored patch edits for appends, which the skill prefers over shell heredocs.
• Links: the agent is told to use [[Note Name]] wikilinks so notes stay connected in Obsidian's graph.

Notice what is absent: nothing in the skill gives the agent a semantic index of your vault. Retrieval is keyword and file search. That works well for a vault with clear filenames and headings, and poorly for a sprawling one. If the agent cannot find a note by name or phrase, it effectively does not know the note exists.

Third-party claims about a dedicated provider

A widely shared guide on DEV Community says Hermes v0.14, released on 16 May 2026, added a first-class Obsidian memory provider configured with hermes memory setup --provider obsidian --path ~/vaults/work, plus optional add-ons such as the Obsidian Local REST API plugin on port 27123 and an MCP server for the vault. The official documentation we read lists RetainDB and ByteRover as the bundled providers and describes Obsidian as a skill, though the docs' sitemap does include an obsidian-memory plugin page that we could not read in full. Treat the one-command setup as plausible but unverified, and check hermes memory setup on your installed version to see which providers it actually offers.

Beyond the two files, Hermes supports external memory provider plugins that give the agent persistent, cross-session knowledge. The documentation says two ship with Hermes, RetainDB and ByteRover, and others such as Honcho, Hindsight, Supermemory, mem0, OpenViking and Holographic are available from the plugin catalogue. Key rules:

• Only one external provider can be active at a time. The built-in memory is always on alongside it.
• Additive, not a replacement. The built-in MEMORY.md and USER.md continue to work exactly as before.
• Automatic plumbing. An active provider injects context into the system prompt, prefetches relevant memories before each turn in the background, syncs conversation turns after each response, extracts memories at session end, mirrors built-in memory writes, and adds its own search and store tools.
• Commands: hermes memory setup for an interactive picker, hermes memory status to check what is active and hermes memory off to disable the external provider.

Honcho, maintained by Plastic Labs, is the multi-agent option the docs highlight, with cross-session user modelling and a shared workspace identifier. It can run on Honcho Cloud or be self-hosted. It is the closest thing in the documentation to genuinely shared multi-agent memory, and it needs an API key or your own instance.

The headline claim in the Agent OS videos is that several agents can run against one shared memory. The documentation has a direct warning that cuts across this: do not point two agent processes at the same Hermes home directory. Memory writes are automatic and load back into the system prompt at session start, so two writers sharing one home will compound each other's entries into state that neither of them, nor you, authored. Memory is scoped per profile by design. The documented answer is to give a second agent its own profile and, if they need shared memory, to use an external memory provider.

A pattern that respects the rules

A shared Obsidian vault is compatible with that advice, because the vault is not the Hermes home. A sound design uses three layers:

1. Private agent memory. Each agent keeps its own profile, with its own MEMORY.md and USER.md for preferences and compact facts.
2. A shared vault. One folder of markdown that every approved agent can read, holding research, logs, design notes and decisions. Third-party guides describe this as a library the agents consult rather than a brain they memorise.
3. Write discipline. Give each agent its own subfolder to write into, keep a human-owned folder that agents may read but not edit, and let agents propose changes to shared notes rather than overwrite them.

That last point matters because the Obsidian skill has no locking or merge logic: it simply writes files. Two agents appending to the same note at the same moment can overwrite each other, so partitioning folders is the cheapest protection. Putting the vault in Git gives you history and an undo button for free.

Commands below follow the official README and skill documentation. Check them against your installed version.

1. Install Hermes. The README gives curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash for Linux, macOS and WSL2, and a PowerShell installer for native Windows. Read any install script before you run it.
2. Create a vault. Make a folder such as ~/vaults/work and open it in Obsidian. Add top-level folders like inbox, projects, decisions and agents.
3. Tell Hermes where it is. Set OBSIDIAN_VAULT_PATH in ~/.hermes/.env to the absolute path. The docs note that variables in .env are settings, not memory, so the agent will not recall the path unless the skill reads the variable.
4. Save the habit, not the path. Ask the agent to use the memory tool to record a single line such as "Project notes live in the Obsidian vault; use the obsidian skill before answering project questions." Then confirm the line landed in ~/.hermes/memories/MEMORY.md.
5. Start a new session. Run /new so the updated snapshot loads.
6. Add a provider only if you need one. Run hermes memory setup, pick one, and check with hermes memory status.
7. Give each additional agent its own profile. Use separate profiles rather than a shared Hermes home, and point them all at the same vault with agent-specific write folders.

Julian Goldie published a run of Hermes videos between 23 and 24 October 2026, including Hermes Agent OS: Run AI Agents With Shared Memory, Hermes Agent Gets UNLIMITED Memory With Obsidian and Hermes Obsidian Just Got Better. Bart Slodyczka also published a quick Hermes setup guide using LM Studio and the Honcho memory provider earlier in October. We cannot verify the contents of paid courses or private communities referenced in video descriptions, so this comparison relies on public documentation.

None of this makes the approach a bad idea. A vault is a very good way to give an agent durable, inspectable knowledge, and our coverage of the v0.20.0 Herald release shows how fast the product is moving. The point is to set expectations accurately before you build a workflow around it.

Giving an agent write access to a folder of personal notes is a real decision. A few points from the documentation and common sense:

• Secret scrubbing is partial. The docs say everything handed to a memory provider, including turns, tool output and mirrored writes, passes through a secret scrub that masks recognisable keys. Credentials with no recognisable shape, such as an arbitrary password, are not detected. Do not keep passwords in the vault.
• Write approval exists. Setting write_approval: true holds memory writes outside the interactive command line for review. Use /memory pending and /memory approve all to manage them.
• Prompt injection. Anything the agent reads, including a note an agent wrote earlier or text pasted from the web, can contain instructions. Keep a human-only folder for sensitive material and avoid giving agents access to it.
• Folder-level permissions. Third-party guides suggest scoping agents to the folders they need. Hermes itself does not enforce this inside a vault, so use operating-system permissions or separate vaults for anything sensitive.
• Sync and backup. If the vault syncs to a cloud service, the agent's writes sync too. Keep Git history so you can roll back a bad edit.

The documentation describes the most common complaint precisely: you tell the agent where a vault lives, it says it will remember, and a fresh session has no idea. Work through these in order:

1. Did the write happen? Memory only persists when the model actually calls the memory tool. Open ~/.hermes/memories/MEMORY.md and look. Small local models, roughly under 30 billion parameters, often claim a save they never made. Ask explicitly for the memory tool and confirm the entry.
2. Was the write staged? With write_approval: true, writes outside the interactive command line wait for approval.
3. Are you reading the same profile? Memory is per profile. A command-line session and a Telegram bot on different profiles do not share notes. hermes profile list shows what exists.
4. Is memory enabled? Setting memory.memory_enabled to false removes the tool entirely.
5. Did you start a new session? The snapshot is frozen, so a fact saved now is visible next session.

Two things that do not make the agent remember: variables in .env, and facts mentioned in passing without asking for them to be saved. For a location the agent needs on every run of a recurring task, the docs suggest a skill is often a better home than a memory entry, because it loads only when relevant and does not compete for the 2,200-character budget.

Against Claude's memory: Anthropic's approach is hosted and account-bound, as we describe in Claude memory everywhere. Hermes plus a vault is self-hosted, inspectable and portable, but you carry the operational burden.

Against Gemini Notebook: Google's notebook product, covered in NotebookLM is now Gemini Notebook, offers grounded answers over your sources inside Google's product. A vault is more open but needs you to maintain the structure.

Against other coding and agent tools: most mainstream agents keep memory in a project instruction file. Hermes adds agent-curated memory, session search and providers. For a wider tool comparison see our best AI coding agents guide and our Hermes Agent tool page.

Hermes Agent plus an Obsidian vault is a strong, open and inspectable way to give an agent a long-term library. It is not unlimited memory, and it is not a licence to point several agents at one Hermes home. Keep the built-in files tiny and sharp, put the bulk of your knowledge in a well-structured vault, give each agent its own profile and write folder, and use /new to let the memory loop do its job.

Do that, and the idea behind the videos works. Skip it, and you will mostly be debugging an agent that forgot something it never saved.