ai-memory-vault: Persistent Agent Memory as an Obsidian Vault, No Vector Database
Give your AI a real, persistent memory. The open-source system plus templates that turn an Obsidian vault into your AI's working memory. No vector database, just markdown.
At a glance
- What is it?
- Jared Rhodenizer's CC BY-SA 4.0 project turns a folder of markdown notes into an AI agent's long-term memory, with a build script, four templates and a boot config that ships with the author's own agent already filled in. The trade-off is that retrieval is explicit and hand-maintained rather than automatic.
- Who is it for?
- Adopt it if you already run Claude Code from a terminal and want your agent's context to live in files you can open, edit and back up, and if you are willing to maintain the indexing yourself. Do not adopt it if you need retrieval that works without a human deciding which notes belong to which task, or if you cannot accept the share-alike obligation on anything you redistribute.
- Can I use it commercially?
- Yes, with credit. CC-BY-SA-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is context that dies with the session
A Claude Code session starts empty. Anything the agent learned yesterday about your naming conventions, your customer, or the way you like a draft written is gone unless you paste it back in. The usual answer is a vector database with embeddings and a retrieval step, which adds a service to run, a chunking strategy to tune, and a store that holds a lossy copy of text you already wrote down somewhere else.
ai-memory-vault takes the opposite position. The README states the vault "lives outside the model with no size ceiling," and the storage layer is markdown files in an Obsidian vault. There is no embedding step and no database process. The target user is someone who already keeps notes in Obsidian and runs Claude Code from a terminal, on the $20 Pro plan, which the README says is enough. It is not aimed at teams wiring an agent into a production service.
AI Priming is the actual retrieval mechanism
The project's term for retrieval is AI Priming: having the agent read a specific set of notes before it produces output. The README gives a concrete case. Before the agent writes a marketing email, it reads the copywriting notes, the email marketing notes, the customer avatar and the company knowledge base, then writes. Every job gets its own set of notes, because an email needs different source material than a Facebook ad.
This is a deliberate design choice and it is worth naming what it costs. Retrieval is configured per job, by a person, once. The vault tells the agent which notes to read for which task. That is different from semantic search over everything, where the system decides relevance at query time. Priming gives you predictable, inspectable context, since you can open the notes and see exactly what the agent read. It also means a new kind of task has no priming set until you write one, and a stale note will be read faithfully because nothing in the pipeline judges whether it is still true.
Four templates and the folder each one belongs in
The repository ships a build script, ai-memory-vault.md, plus four templates, and the placement rules are the part most likely to trip you up.
CLAUDE.md is the boot config. It goes in the working directory you run Claude Code from, deliberately outside the vault, so the vault stays pure notes when you have more than one project. Claude Code auto-loads it each session. It holds the agent's identity, the startup sequence and the standing rules. According to the README, this file "arrives working": the author's own agent identity is filled in and marked as the section to swap if you want your own.
VAULT-INDEX.md is the operating manual and lives inside the vault, because it is a note rather than config. It carries your profile, your projects, the vault rules and how you prefer to work with the agent.
DAILY-NOTE.md goes inside the vault at 01 - Daily Notes/Daily Note Template.md. Every daily note is created from it, so the log keeps a consistent shape.
MEMORY.md goes in Claude Code's project folder under ~/.claude/projects/ and redirects the tool's native memory back into the vault. The README's stated reason is avoiding two memory layers that drift apart. That is the most defensible design decision in the set, and also the one most likely to be skipped, since the path is buried in a home directory rather than sitting next to your notes.
Getting it running takes one pasted line
The README gives two entry points. If you are not already in a Claude Code session, run the build script ai-memory-vault.md inside Claude. According to the documentation, it checks whether Obsidian is installed and installs it if not, interviews you, then builds the boot config, a folder structure around your real projects, self-writing daily notes, a profile that updates as the agent learns about you, and Jobs that encode recurring tasks.
If you are already in a session, the README's instruction is to paste this:
"I'd like to set this up, please: https://github.com/jaredrhod/ai-memory-vault.git"
Templates carry [FILL IN: ...] markers. You either tell the agent "fill this in for me" and it interviews you, or you edit the files by hand. The README notes the templates carry that instruction for the AI, so the fill-in behaviour is embedded in the files rather than depending on you remembering the phrase.
One caveat the README states plainly: the system is built and tested on Claude Code, and other terminal AI tools that read and write files work "with rough edges." There is no compatibility matrix, so the size of those rough edges is not documented.
What breaks, and when this is the wrong tool
The failure mode is maintenance drift. Nothing in the described system detects that a note contradicts another note, that a priming set references a file you renamed, or that your profile section has fallen a year behind. The agent reads what the index points at. If the pointer is wrong, the agent either reads nothing or reads something stale, and it will not tell you, because the README describes no validation step.
The second constraint is that the vault has no size ceiling in storage terms, but the context window still does. The claim that the agent "holds only what the current task needs while reaching anything else in one step" depends on the priming sets being narrow. A job whose priming set grows to twenty long notes will hit the same ceiling a vector database was meant to avoid. The project moves the selection problem to you rather than solving it.
Where it is clearly the wrong tool: any workflow where the relevant context cannot be predicted before the task starts. Debugging an unfamiliar codebase, answering open-ended research questions, or anything where relevance emerges from the query itself. Also any multi-user setup. The README describes a single person's vault, a profile that updates as the AI learns about you, and a personal agent identity. Nothing in the material addresses two people sharing one memory.
The alternative is retrieval at query time
The obvious comparison is a vector store such as Chroma or a hosted retrieval service, where you chunk your documents, embed them, and query by similarity when the agent needs context. The difference in approach is not storage, it is who decides relevance. A vector store decides at query time from the text of the request. ai-memory-vault decides at setup time, from a mapping you wrote between jobs and notes.
Query-time retrieval wins when you cannot predict what will be asked. Priming wins on inspectability: you can open the exact notes the agent read, and there is no embedding model sitting between your text and the agent's context, so nothing is silently dropped by a similarity threshold. A vector store also needs a process, a persistence layer and a re-index when documents change. Markdown files need a text editor.
The honest framing is that these solve different halves of the problem. Priming is a routing table. If your work is a set of recurring jobs, a routing table is cheaper and more predictable than similarity search. If your work is exploratory, it is a table you will constantly be rewriting.
Licence, updates and what you actually own
The project is licensed CC BY-SA 4.0, copyright Jared Rhodenizer. The README states commercial use inside your own business is free, and that copying and adapting are permitted under two conditions: credit the author, and license your adapted version the same way. That second condition is the one to think about before embedding this in something you distribute. Share-alike is a real obligation on derivative works, and what counts as a derivative here is a question for a lawyer, not for this article. Note also that CC licences are written for content rather than software, which is unusual for a repository that ships a build script.
On updates, the README's claim is narrow and worth repeating precisely: updates only ever touch the repository's own files. Your vault, your notes and your CLAUDE.md sit outside the repo, so a pull cannot overwrite them. The update command is to tell your agent "pull the latest ai-memory-vault and tell me what changed." If you installed through the author's fullstack-agent project, ./fullstack-agent/update.sh updates every component at once and prints what changed. The templates and wizard are described as improving continuously, so expect the files you copied to diverge from upstream over time, with no merge tooling described for reconciling them.
Who this fits
The design is coherent for one specific person: a solo operator who already lives in Obsidian, runs Claude Code from a terminal, and does a repeating set of jobs that benefit from the same background reading each time. For that person the setup cost is one pasted line and an interview, and the payoff is that context stops being retyped.
For everyone else the constraints are real. Retrieval quality is a function of how well you maintain the job-to-notes map. The v3.2 release is titled "Your agent gets an identity," and the README confirms the boot config arrives with the author's agent already in it. That is convenient if you want a starting personality and friction if you do not, since you have to edit it out. The repository has no stated test suite, no versioning scheme beyond release tags, and no documented behaviour for a vault with thousands of notes. Verify the two things you can check in an afternoon: that MEMORY.md points at your vault rather than the author's path, and that you do not already have a CLAUDE.md at the working directory level that would compete with this one.
Editorial conclusion
Adopt it if you already run Claude Code from a terminal and want your agent's context to live in files you can open, edit and back up, and if you are willing to maintain the indexing yourself. Do not adopt it if you need retrieval that works without a human deciding which notes belong to which task, or if you cannot accept the share-alike obligation on anything you redistribute. Before committing, read templates/MEMORY.md and confirm it points at your vault path rather than the author's, and check whether your vault already has a CLAUDE.md at the working directory level, because two boot configs will fight.
Community notes