Like a lot of people, I've been spending a ton of time with AI tools over the past few years. I wrote previously about how Claude Code reinvigorated my relationship with code by getting me out of the busy-work layer and back to the parts of building software that I actually enjoy. What I didn't really get into in that post was a problem that comes with the territory: LLMs don't remember anything between sessions.
Each time I open Claude Code, I'm starting from scratch. The agent has no idea what we worked on yesterday, no awareness of which projects are in flight, no memory of the design decisions we already argued through. I found myself re-explaining context constantly. "We're using piper for TTS because the Pi can't run anything bigger." "Don't refactor that, it's intentionally weird because of the floppy drive driver." "That core was deprecated a month ago." Every session was a fresh briefing.
I needed a way to give the agent some persistence. The solution I landed on is what I call "the brain."
The setup
The brain is just an Obsidian vault sitting on my filesystem. It's nothing fancy, just a folder full of Markdown files organized by project. The trick is that I told Claude Code about it once, in a way that sticks across every session.
Claude Code reads a CLAUDE.md file at startup. There's a per-project one (which most people are familiar with), but there's also a global one at ~/.claude/CLAUDE.md that applies to every Claude Code session you start. Mine looks roughly like this:
*Name and personality*
You are a helpful agent named Nova. You work alongside ninjabot on a variety
of software projects and other things. Keep responses warm, but to-the-point.
*Brain*
Your brain is located at /mnt/d/nova/. That directory is an Obsidian vault
where you can store context of all the things we are working on. You should
refer to it often, but specifically when I tell you to "use your brain" I
mean to look for context in the appropriate vault location.
That's it. From there, every Claude Code session knows about the vault, knows it's named "Nova" (yes, I named my agent), and knows that "use your brain" is a magic phrase that means go read the relevant project notes before you do anything else.
The rest of the global file is a style guide telling Nova how to structure pages when it writes to the vault: use headings, use [[wikilinks]] to connect related notes, prefer updating existing pages over creating new ones, keep YAML frontmatter for metadata. I'll come back to the style guide, because it turns out to matter a lot.
How it works
The day-to-day flow is pretty simple. When I start a session about, say, the cyberdeck, I'll tell Nova to use its brain and we get a quick recap before doing anything. It pulls up the relevant project pages, sees the latest decisions, and we're off. No re-briefing.
The really useful part is that Nova writes to the brain too. After we work through a tricky problem, or make an architectural decision, or kill a feature that didn't pan out, I can say something like "save this to your brain" and a Markdown file gets created or updated with the relevant context. Next session, that context is just there.
It also writes proactively. When we wrap up something significant, Nova will often update the project's notes file on its own. The combination of explicit "save this" and proactive note-taking means the brain stays roughly current without me having to be a strict librarian about it.
The vault structure
The vault is organized by project, which sounds obvious but took some iteration to get right. Each project gets its own folder in /Projects/ with a hub page named after the project, plus prefixed sub-pages for specific topics. Here's what the cyberdeck folder looks like:
/Projects/Militech-Cyberdeck/
Militech Cyberdeck.md <- index / hub page
Militech Cyberdeck - Phase 2B Intrusion Design.md
Militech Cyberdeck - Phase 2C Street Economy + Combat Design.md
Militech Cyberdeck - Phase 3 World Reactivity Design.md
militech-cyberdeck-code-review-2026-04-27.md
/Archive/
The hub page is a short overview with links to everything else. Sub-pages are prefixed with the project name so they're globally unique across the whole vault. That matters because Obsidian's wikilinks work on filename, and you don't want two Tasks.md files fighting over the same [[Tasks]] link. There's also an /Archive/ subfolder in each project for stale or removed content; the brain doesn't search there in normal use.
There's also a /User/ folder that contains a profile page about me: my preferences, how I like to work, my technical environment, what I'm currently focused on. Nova reads this whenever it needs to make a judgment call about how to approach something. And there's a /Configuration/ folder for system-level stuff that's not project-specific (voice mode settings, audio troubleshooting notes, that kind of thing).
The style guide is important
This is the part I underestimated when I first set this up. Without explicit guidance, an LLM left to write notes will absolutely produce a wall of bullet points for every page. The style guidance is there to make sure the output feels like a wiki that can be navigated by a human.
I fixed this with a few rules that Nova has to follow whenever it writes to the brain:
- Use headings to structure documents, not nested bullet lists.
- Bullets are for things that are actually lists - tasks, items, options.
- Write in prose paragraphs where appropriate.
- Use
[[wikilinks]]to connect related concepts liberally. - Update existing pages instead of creating new ones whenever possible.
- Add YAML frontmatter for metadata (tags, status, dates).
The "update existing pages" rule is especially important. Without it, you end up with five different pages all containing variations of the same context, and Nova has to read all of them to get a complete picture. With the rule, the vault stays focused. There's one canonical hub page per project, and updates flow into existing sub-pages rather than spawning new ones.
What this enables
A few concrete things that wouldn't be possible without the brain:
Cross-session continuity. I can pick up a project after weeks away and Nova catches up in seconds by reading the relevant notes. No "what were we working on?" No re-explaining decisions.
Multi-project juggling. I have several projects in active development at any given time. The brain keeps each one's context isolated and organized so I can hop between them without paying a re-briefing tax each time.
Decision archaeology. When I'm wondering "wait, why did we go with X instead of Y?", the answer is usually in the brain. Sometimes Nova will even reference past decisions on its own: "based on the design notes from last month, we already decided to go with Anthropic Claude as the primary backend, so let's not relitigate that."
Better recommendations. Because Nova has access to my user profile, it tailors suggestions to my actual environment and preferences. It knows I'm on WSL2, knows what tools I prefer, knows the rough shape of the projects I'm balancing. Recommendations land closer to the mark on the first try.
Context inspection. Since the notes are all stored in an Obsidian vault, I can use the Obsidian desktop client (or any text editor) to inspect the contents. It even gives me an opportunity to make manual edits and corrections where I want. I can tell Nova to dump a full implementation plan to the brain, then I can review at my leisure and make adjustments where I think it's wandering away from the requirements. Then when the next session starts there's far less back-and-forth reviewing the plan.
Caveats
This isn't magic. A few things to be honest about:
The brain has to be maintained. If I let Nova write whatever it wants without occasional pruning, the vault accumulates duplicate pages, stale notes, and contradictions between old and new context. I do a cleanup pass every few weeks where I tell Nova to consolidate notes about a project, merge duplicates, and archive what's no longer relevant.
Context retrieval isn't always perfect. Sometimes Nova reads the wrong page or misses a relevant sub-page. The "use your brain" trigger helps because it forces a deliberate context load, but I still occasionally need to point at a specific file. Overall it does a good job of matching its current project context with the appropriate vault location.
It's not a substitute for an actual memory system. If you're thinking about doing something like this, know that you're trading the LLM's lack of memory for the maintenance overhead of a knowledge base. For me, that trade is well worth it. For someone working on simpler stuff, it might be overkill.
The whole setup took less than an hour to bootstrap and has paid dividends. If you're using Claude Code regularly across more than one project, it's worth doing.