Hermes Agent and a Second Brain: Give the Agent Your Context, Not Your Memory

Hermes Agent’s memory is not your second brain, and the fact that both are markdown files on disk is exactly why people conflate them. MEMORY.md is capped at roughly 2,200 characters. Your knowledge base should not be capped at all. One is the agent’s notes about itself. The other is your judgment about what matters, and the agent should read it, not own it.

I run Hermes Agent in production, with my second brain as something it reads for context, not a place it writes. This is the map: what Hermes actually remembers on its own, the bundled skill that gives it a filesystem-first Obsidian workflow, the one context file it loads per project, and the boundary I keep between a vault I curate and memory the agent writes about itself.

Hermes Agent Obsidian integration: a bundled skill, not a plugin

Hermes ships a bundled skill named obsidian that gives it filesystem-first access to an Obsidian vault: read a note, list notes, search by filename or content, create a note, append to one with an anchored patch, and add [[wikilinks]] when it creates something new. The vault path comes from an OBSIDIAN_VAULT_PATH environment variable, falling back to ~/Documents/Obsidian Vault if unset.

Read that list again and notice what is missing. There is no Obsidian REST API call, no plugin installed inside Obsidian itself, nothing that talks to the app at all. Hermes reads and writes markdown files in a directory. Obsidian is the editor that happens to render [[wikilinks]] as a graph and turn YAML frontmatter into Dataview queries on top of those same files. The skill works whether or not Obsidian is even open, because the vault is just a folder of text, and that is the whole point: markdown plus git is the actual interoperability layer, Obsidian is a very good viewer for it.

The llm wiki Hermes Agent ships with, and the one you should actually run

Hermes also bundles a second, related skill called llm-wiki, built on Andrej Karpathy’s LLM wiki pattern: a persistent, compounding knowledge base of interlinked markdown files, with an explicit division of labor. You curate sources and direct analysis. The agent summarizes, cross-references, and files pages into entities/, concepts/, and comparisons/ folders, with an index.md catalog and an append-only log.md. Unlike RAG, which re-derives an answer from scratch every query, the wiki compiles knowledge once and keeps the cross-references attached.

That skill is a legitimate reason to let an agent write into your wiki, and it is not the same thing as the self-learning memory loop writing about itself. The llm-wiki skill only runs when you ask it to ingest a source or answer a question from an existing wiki. It never fires on a timer. The three operations it offers (ingest, query, lint) are a good shape for a research corpus you are actively building with the agent’s help, sources, entity pages, a lint pass for orphaned pages and broken links.

What ships by default, checked against v0.21.5

2,200

chars, MEMORY.md cap≈800 tokens, the agent's own notes

1,375

chars, USER.md cap≈500 tokens, what it saved about you

7

external memory providersHoncho, mem0 and five others, one active at a time

2

bundled vault skillsobsidian (filesystem) and llm-wiki (Karpathy pattern)

Run your own research vault through the bundled skill if you want the agent actively building it with you. Run a vault you have already curated as pure context, and the rule changes: keep the agent out of the write path, and let it only read.

If you run both skills against the same vault, the docs say to point them at the same directory rather than maintaining two copies of your notes:

Point both vault skills at one directory

1. Obsidian skill

   $ echo 'OBSIDIAN_VAULT_PATH=/home/me/vault' >> ~/.hermes/.env

2. llm-wiki skill

   $ echo 'WIKI_PATH=/home/me/vault' >> ~/.hermes/.env

One project context file, and SOUL.md always

Point Hermes at a project directory and exactly one context file loads, first match wins: .hermes.md (or HERMES.md, walked up to the git root), then an AGENTS.md chain from the git root down to the working directory, then CLAUDE.md, then .cursorrules and .cursor/rules/*.mdc. SOUL.md from HERMES_HOME loads independently and always, because that slot is identity, not project context (agent/prompt_builder.py). This is the exact rule I use to decide what a vault exposes to an agent working inside it: an AGENTS.md at the vault’s root, or a .hermes.md if I want Hermes specifically to see something the other runtimes should not.

What a project folder can hand the agent

• your vault or repo/// only one of these loads, first found wins
  • .hermes.md1st// walked to the git root
  • AGENTS.md2nd// git root down to cwd
  • CLAUDE.md3rd
  • .cursorrules4th
• ~/.hermes/// independent of the project, always included
  • SOUL.mdalways// identity, not project context

That single-file rule is a feature, not a limitation. It means the vault decides, in one place, what an agent sees when it works there, instead of the answer depending on whichever file a given runtime happens to prefer. This is context engineering at the simplest possible point: one file, one decision, made once, by you.

Hermes memory vs a wiki you curate

The built-in memory is deliberately small. MEMORY.md and USER.md live under ~/.hermes/memories/, injected into the system prompt as a frozen snapshot at session start, and neither auto-compacts: a write past the character cap returns an error instead of silently dropping an old entry, so the agent has to consolidate or remove something itself before the new fact fits. Seven external memory providers, Honcho and mem0 among them, extend this with cross-session user modeling or semantic search, one active at a time alongside the built-in files. Past that, every session ever run is searchable through full-text search over SQLite with an FTS5 index and a CJK tokenizer.

None of that is a knowledge base. It is the agent’s working notes about itself and about you, bounded on purpose so it stays cheap to inject on every turn.

Two different jobs that happen to both be markdown

Both are files Hermes can read. Only one of them is your judgment.

	Hermes memory	A wiki you curate
Who writes it	The agent, about itself and you	You, with the agent's help on request
Size	Capped: 2,200 and 1,375 characters	Unbounded, split across as many pages as it needs
When it changes	Every turn, via the memory tool, automatically	When you ingest a source or run a worklog pass
Survives a model swap	Yes, but it is small and self-referential	Yes, and it is the part worth keeping forever

My setup: one engine, two wikis, context not memory

I run a personal LLM wiki and a separate work vault on the same engine, markdown and git underneath both, with skills for ingest, worklog capture, linting, and query. After a meeting, a worklog pass pulls decisions and ideas out of the conversation and files them into the vault. Agents read the vault as context. They do not get to decide what belongs in it.

At my day job, a Hermes cron job writes me a daily briefing of what is happening across the company, organized by a six-sense framework of mine: what already worked, what others are doing, where demand is moving, what just shipped elsewhere, what people are asking for, and what the people who depend on me actually need. I covered the mechanics in the daily briefing piece, including the detail that makes this article’s whole argument concrete: a cron run is a fresh, isolated session with no memory of the previous day’s run. It does not accumulate anything the way MEMORY.md does. Whatever it knows about who is who and which projects matter, it has to get from reading my second brain again, from scratch, every single morning, through the one context file this piece keeps coming back to.

The part that matters here: the job reads my second brain only as context, and it reads the live state of the company through MCP servers for Slack, Google Workspace, Git, and the issue tracker. It never writes a line back into the vault. The vault decides what the briefing already knows going in. The briefing never gets to revise that, and tomorrow’s run will not remember today’s either.

Why the agent should read your wiki, not write it

Here is the distinction worth keeping straight, because the bundled llm-wiki skill genuinely does let an agent write into a wiki, and that is not a contradiction of anything above.

An agent-maintained wiki

1. 01You ask it to ingest a source, explicitly, each time
2. 02The agent synthesizes, cross-references, and files pages
3. 03Good for a research corpus you are actively building together
4. 04The llm-wiki skill's ingest and lint passes keep it honest

A context-only vault

1. 01You curate it; a worklog pass, not the work agent, updates it
2. 02The agent reads it to know who is who, what matters
3. 03Good for the judgment a daily job should not get to revise
4. 04The context file at the project root decides what loads, not the agent

The mistake is not letting an agent write into a wiki. The mistake is letting the same unmonitored loop that writes MEMORY.md about itself, every turn, without being asked, also decide what belongs in the knowledge base you built your judgment into. One is procedural self-notes with a 2,200-character ceiling. The other is the thing you actually want to still be true next year. Keep the boundary at the project context file: an AGENTS.md or a .hermes.md the vault itself ships, deciding once what any agent sees there, instead of trusting a per-turn memory tool to get the line right by accident.

Setting OBSIDIAN_VAULT_PATH or WIKI_PATH does not enforce any of this by itself. Both skills are filesystem-first: once a directory is set, write_file and patch work against it exactly like any other path the agent can reach. The boundary lives in what you tell it, not in the env var.

How to talk to an agent sitting on top of a vault

1. 01

   Say ingest, not just 'use my notes', when you want it to write.

   A vague instruction, plus a model that already has write_file and patch, tends to resolve toward being helpful: filing a page nobody asked for.

   Instead of

   Just use my notes for context.

   Type this

   Treat the vault as background only. Don't create, edit, or append to any file there unless I say ingest this, explicitly.

2. 02

   Tell a read-only job to stay read-only, past the workdir.

   --workdir decides which context file loads. It does not, by itself, stop file tools from writing into that same directory if an instruction tells them to.

   Type this

   This job is read-only. Never call write_file, patch, or skill_manage against anything under this workdir.

Before you point Hermes at a vault

• ✓Required:
  Decide read-only vs ingest-enabled before you set the env var.OBSIDIAN_VAULT_PATH and WIKI_PATH both just point at a directory; nothing stops either skill from writing there.
• ✓Required:
  Put the boundary in the project context file, not in a prompt.An AGENTS.md or .hermes.md at the vault root loads once and decides for every session.
• ✓Required:
  Keep MEMORY.md for the agent's own notes, nothing else.It is capped at 2,200 characters on purpose. Do not fight the cap; respect what it is for.
• ✓Required:
  Let a worklog pass update the vault, not the agent that consumes it.The surface that reads your context and the surface that writes it should not be the same unmonitored loop.
• ✓Required:
  Version the vault in git either way.A wiki an agent can touch is a wiki you want a diff and a revert for.

Hermes Agent, memory and a second brain, quick answers

Does Hermes Agent work with Obsidian?+

Yes, through a bundled skill named obsidian that reads and writes vault files directly: notes, search, wikilinks. It talks to the filesystem, not to an Obsidian plugin, so it works whether or not Obsidian itself is open.

What is the Hermes Agent llm wiki skill?+

A bundled skill based on Andrej Karpathy's LLM wiki pattern: a persistent markdown knowledge base with entity, concept, and comparison pages, an index, and a lint pass. You curate sources; the agent synthesizes and cross-references on request.

Is Hermes Agent's memory the same as a second brain?+

No. MEMORY.md and USER.md are capped at 2,200 and 1,375 characters, written by the agent about itself and you, every turn, automatically.

A second brain is a wiki you curate, with no size ceiling, that the agent reads for context and writes to only when you ask it to.

Which file decides what Hermes loads for a project?+

Exactly one: .hermes.md first (walked to the git root), then an AGENTS.md chain, then CLAUDE.md, then .cursorrules. SOUL.md from HERMES_HOME loads independently and always, as identity rather than project context.

Can Claude Code and Hermes Agent read the same vault?+

Yes. Both read plain markdown and both resolve a project context file (AGENTS.md on both, among others), so a vault you curate for one works for the other without converting anything, as long as the context file at its root says what each runtime should see.