ai-memory-vault: an Obsidian vault as your AI agent's persistent memory

What ai-memory-vault actually solves

An agent forgets. Each Claude Code session starts with the model holding only what fits in its context window, and anything you explained last week is gone unless you paste it back in. The common answer is a vector database plus an embedding pipeline, which introduces a second store to run, index and keep in sync with your notes. ai-memory-vault takes the other route: your notes are already files, so make the files the memory.

The target user is specific. You run Claude Code from a terminal, you keep notes in Obsidian, and you want the agent to know your projects, your writing voice and your recurring tasks without re-explaining them. The README says the $20 Pro plan is enough, which tells you the design assumes a modest context budget rather than a large one.

The README frames the payoff as priming: having the AI read a defined set of notes before it produces output. Before writing a marketing email, the example agent reads copywriting notes, email marketing notes, a customer avatar and a company knowledge base. The vault does not make the model smarter. It decides what the model sees first.

The four files and where each one lives

The system is a boot config, an index, a daily-note template and a memory pointer, and the placement of each is the part people get wrong.

CLAUDE.md is the boot config. It goes in the working directory you launch Claude Code from, deliberately outside the vault, so the vault stays pure notes when you have more than one project. Claude Code loads it every session, and it holds the agent's identity plus the startup sequence and the rules that cannot lapse. The README states this file arrives working: the author's own agent identity is filled in and marked as the one section to swap.

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 like to work with the AI. DAILY-NOTE.md goes inside the vault at 01 - Daily Notes/Daily Note Template.md, so every daily note is created from one consistent shape. MEMORY.md goes in Claude Code's project folder under ~/.claude/projects/ and redirects native memory back into the vault. That last file is the one that prevents two memory layers from drifting apart, and skipping it is the quiet way to end up with a system that contradicts itself.

Installing it and building the first vault

There is no package to install. The build script is a markdown file you hand to Claude, and the README says it checks whether Obsidian is installed and installs it if not, then interviews you and generates the boot config, the folder structure, daily notes, a profile and Jobs.

The README gives a paste-in path for anyone already inside a Claude Code session. The quoted instruction is:

I'd like to set this up, please: https://github.com/jaredrhod/ai-memory-vault.git

What you should see is the agent working through the interview, then writing the files. If you prefer to place templates by hand, the README names the locations. The daily-note template is the one with a fixed path:

01 - Daily Notes/Daily Note Template.md

Templates mark every spot that needs your information as [FILL IN: ...], and each carries an instruction telling the AI to interview you and write in your voice. The README also offers the manual route: fill them out yourself.

One warning before you start. The README says the system was built and tested on Claude Code, and that any terminal AI which reads and writes files works with rough edges. Treat the non-Claude path as unverified rather than supported.

What breaks, and when this is the wrong tool

The failure mode is priming drift. Every job gets its own set of notes, and the vault tells the AI which notes to read for which job. That mapping is configured once by hand. When you rename a note, move a folder or add a job, the list does not update itself. The agent then primes on notes that no longer exist or on the wrong set, and the output degrades without an error message, because a missing note looks the same as a note that had nothing to contribute.

The second limit is scale. The README's claim is that memory lives outside the model with no size ceiling, and that is true of storage. It is not true of attention. Loading twenty notes into a session costs context, and the design assumes the AI holds only what the current task needs while reaching anything else in one step. That step is a file read chosen by the model, not a similarity search. If your question needs an answer assembled from fifty scattered notes, a retrieval system will beat this.

The third case is the wrong-tool case: you do not use Claude Code and you do not want rough edges. The README is explicit that this is built and tested on Claude Code. Nothing here runs as a service, so there is no API to call from another stack.

How this differs from a vector-database memory layer

A vector-database memory layer, the shape used by most agent memory projects, embeds your documents, stores the vectors, and retrieves the nearest chunks at query time. The retrieval is automatic and fuzzy. You do not decide what the model reads; a similarity score does. It scales to a corpus you could never fit in a prompt, and it fails in ways that are hard to inspect, because the retrieved chunk is chosen by distance rather than by intent.

ai-memory-vault inverts both properties. Selection is explicit and curated: a human wrote down which notes belong to which job. Retrieval is a file read, so what the model saw is a path you can open. Nothing is embedded, so there is no index to rebuild and no second store to run. The README's phrase for the storage side is "no vector database, just markdown."

The trade is real. You gain inspectability and lose automatic recall. A vector store finds the relevant note you forgot you had. This system only finds what you told it to look for, plus whatever the agent decides to open on its own.

Updating, cost and the share-alike licence

Updates are pulled by asking. The README's instruction is to say "pull the latest ai-memory-vault and tell me what changed." The stated guarantee is that updates only touch the repo's own files, and that your vault, your notes and your CLAUDE.md are never inside the repo, so nothing you built can be overwritten. That separation is the strongest structural decision in the project, and it is the reason the placement rules in the templates matter. If you copy CLAUDE.md into the vault, you break the guarantee yourself.

If you installed through the author's fullstack-agent repository, ./fullstack-agent/update.sh updates every piece at once and prints what changed. That is the only update path with a command attached.

The licence is Creative Commons Attribution-ShareAlike 4.0 International. The README states commercial use inside your own business is permitted, with two conditions: credit the author, and license your own adapted version the same way. The second condition is the one to think about before you build a product on top of these templates, because it follows your derivative work. The repository does not spell out what counts as an adaptation, and this is a licence question rather than a technical one.

TROUBLESHOOTING.md and the maintenance you actually pay

The repository ships a TROUBLESHOOTING.md at the top level, alongside LICENSE, README.md, ai-memory-vault.md and the templates directory. The README does not document what is inside it or how it is organized, so the file is the first place to look when the build script produces something unexpected, and you should open it before assuming a bug.

The recurring cost is not software maintenance. The build script and templates are updated by the author, and the last push to the repository was on 2026-08-31, with v3.2 released on 2026-07-14 under the title "Your agent gets an identity." The cost you carry is curatorial: keeping the job-to-notes mapping accurate as your vault grows, and keeping daily notes flowing through the template rather than being written freehand. A vault that drifts from its index is worse than no index, because the agent will trust a stale map.

One structural note on the release. v3.2 shipped the author's own agent identity inside the boot config. That is convenient and it is also a default you should consciously accept or replace, since the README presents keeping it, renaming it and swapping it as equally valid choices.

Editorial conclusion

Adopt it if you already run Claude Code and want memory you can open, edit and back up as plain notes, and if you accept that every recurring task needs its own priming list maintained by hand. Do not adopt it if you need retrieval over a large corpus, if you work outside Claude Code without tolerating rough edges, or if a share-alike licence on your adapted templates is a problem for your business. Verify first that your daily notes actually land in 01 - Daily Notes, that your CLAUDE.md sits in the working directory rather than inside the vault, and that MEMORY.md points at the vault so you do not end up with two memory layers drifting apart.

Frequently asked questions

Official sources

1. jaredrhod/ai-memory-vault on GitHub
2. License: CC-BY-SA-4.0
3. Project website
4. README
5. Releases