Design your vault for AI orientation, not just human navigation

Most writing about AI + Obsidian focuses on using AI to generate notes, summarize content, or search your vault. This is about the inverse: structuring the vault so it reliably orients an AI at the start of every session — without relying on the AI’s memory, which doesn’t persist, or your own working memory, which is unreliable.

**The core design move**

AI sessions are stateless. Each one starts fresh. If your vault is just a collection of notes with no orientation layer, every session begins with either a long briefing or a lot of wrong assumptions. The fix is to treat AI sessions as stateless workers and the vault as the persistent state layer.

**What that looks like in practice**

Three components make it work:

*Context files* — each active project or domain has a dedicated file in a `Working Context/` folder. These capture current state, open items, files in scope, and relevant cross-references. They’re written to be read by an AI at session start, not just by a human browsing the vault.

*Session start protocol* — at the start of every vault session, two files are read before anything else: a vault-level navigation file and a canonical action register. A third read is triggered if the session has a domain focus. This is encoded as a repeatable protocol, not left to inference.

*Handoff protocol* — at session close, a structured prompt is generated and written to a dedicated file in the vault root. The next session opens with this, bridging the gap. Format: what was completed, what needs human review in Obsidian, what was deferred, what comes next.

**Why this gets thorough**

I built this under real constraints — ADHD, unreliable working memory, no margin for gaps in the system. When working memory can’t cover for a missing piece, the missing piece gets filled. That maps directly onto evidence-based ADHD management: reduce working memory load by moving cognitive cargo into external systems. The vault does that for project state; the session protocol does that for session continuity.

I use Claude, and the session start protocol is encoded as a reusable skill so it runs consistently across sessions without relying on the AI to infer what to do.

**What I’m curious about**

Has anyone else approached vault design from this angle — building explicitly for AI orientation rather than just human navigation? The Promptfire plugin addresses a related problem (copying context to your clipboard before a session), but I’m interested in whether people are thinking about the structural design level, not just the tooling level.

Happy to share more detail on any of the components.

3 Likes

Thanks for this! I haven’t linked AI to my vault yet, but it’s something I know I’ll want to do once I have a good local option, so it’s good to begin thinking about how to better tailor the vault for AI consumption. I hope you and others can share more so when I get to the point of setting it up I’ll have some good perspectives to base my layout on!

If you have time, sharing a bit more about how you handle each of the components would be appreciated!

Hi!
The three components in practice:

Context files — I keep a Working Context/ folder with one file per active project. Each has a short header (what it is, current status, open questions) followed by relevant cross-references. The key discipline is keeping them current — I update them at session close, not as an afterthought.

Session start protocol — encoded as a reusable skill that runs automatically. It reads a vault-level nav file and an action register before anything else. If the session has a domain focus, it reads the relevant context file too. The whole thing takes ~30 seconds and means I don’t spend the first 10 minutes re-orienting.

Handoff — at session close, a structured prompt generates a file in the vault root: what was done, what needs human review in Obsidian, what was deferred, what’s next. The next session opens with this. It’s the piece that makes the whole system feel continuous even though each AI session is stateless.

On the local model question — I use Claude, but the structure works with anything that can read files. The protocols are what matter, not the model. That said, I struggled with this workflow until I brought Claude into it - Claude has a skill that assists with building new skills - after every several uses of my system I review what went well and what could be improved and then update the skill.

3 Likes

Another thing that I find useful is that my Claude vault management skill creates and updates links - this is really helpful for the memory issues that challenge me; looking at my graph view really helps to orient me in regards to things that I was working on that I totally forgot about. I’m sure other people have similar methods, but I’m a new Obsidian user and I went off and built something when maybe I should have looked at how others do it first! My current graph view -

Yes, I discovered Obsidian by asking Claude Desktop the best way to store notes. :slight_smile:

I have a folder named 000 - Rules.
In it I have the following files:
A-Meta rules
B-Summary
C-Decisions Log
D-TODO
E-Index

Claude helped write these, and starts every session by reading them to restore context. The Obsidian → Claude path works very well.

What hasn’t is the Claude → Obsidian path:

  • The Rest/MCP tools are very limited in scope and unreliable at times
    (Using “Local REST API”, “MCP Tools” and “Templater” - had to turn Smart Connections off, it was dragging things down even more)
  • Performance on note updates is terrible.
  • Refactoring is very painful (combination of the two things above)

I have resorted to having Claude write PowerShell scripts to do the updates via raw file opeations to bypass the MCP bottleneck. This is OK for some things, not great for others.

If anyone has suggestions for Vault techniques or better plugins to improve this, I’m all ears.

1 Like

You’re right to instinctively go for raw file ops - Local REST API overhead compounds fast with multiple writes. What worked for me was keeping Claude’s writes to plain markdown (new notes, logs, summaries) and letting Obsidian handle anything that needs plugin features like templates or dataview. I found that treating the vault as a filesystem rather than an app to control makes the write path way less painful.

1 Like

This maps closely to something I’ve been trying to articulate.

My sessions split into two modes. The first is what you’re describing — structured, domain-focused, protocol makes sense. The second is reactive: I’m in the middle of something, I hit a wall, and I reach for the LLM on instinct. No prep, no context loading.

I find the reactive ones are actually more frequent. And they’re where I feel the statelessness most painfully.

Curious whether others experience this split — and in reactive mode, do you manage to load any context before you start typing, or do you just go?

great tips Andre. I’m also an ADHD. I’m currently trying to setup a Hermes Agent as a to help me with my GTD system, so I’m migrating everything from my previous paid app (Nirvana) to a simple machine friendly GTD structure inside Obsidian. I’ll try to post here when I get it running smoothly.