Vault as operating system

What this is

A vault is one markdown folder structured to serve as your operational and strategic layer. CLAUDE.md (Foundations 01) is the project-level instruction file. Memory (Operating 03) is what carries forward across sessions. The vault is the substrate — where your decisions, meetings, people, research, agents, and venture-specific work all live.

The reason this matters: AI agents cannot effectively read across SaaS boundaries. Your agent can search Notion, query Asana, browse Drive, summarize Gmail — but it can't easily cross-reference them. Every Tuesday meeting you had this month produced notes that live in three different systems, and the agent sees only what you point it at.

Move it all into one markdown vault and several things change: cross-references become free, agents read everything in one pass, versioning is git, the operator owns the data unambiguously. The SaaS stack costs aren’t bad in absolute terms — they’re bad relative to what AI-augmented work needs.

This lesson is the structure that makes the vault scale. 13 numbered folders, the rules that route work, and the wiki + memory architecture that compounds.

The SaaS sprawl story

Six months ago I was running on Notion (docs), Asana (tasks), Google Drive (files), Slack (chat), Calendly (scheduling), Gmail (email), GitHub (code), Figma (design). Eight tools, all reasonable individually. Each tool had matured for years; their integrations existed; my team could learn each interface.

The problem wasn’t any individual tool. The problem was that my agent could only see one of them at a time. Every “what did we decide about X” question required me to stitch context across systems before the agent could even understand the question. Every meeting that mentioned a decision had the meeting notes in Notion, the action item in Asana, the email confirming it in Gmail. Three places, all partially correct.

The cost was hidden until I tried to scale. With one venture I’d work around it. With three ventures, the context-stitching cost became my bottleneck.

The rebuild took three weekends. Everything that wasn’t real-time-collaboration-critical moved into a single Obsidian vault, organized by the 13-folder convention this lesson teaches. Agents got dramatically more useful within a week. The compound effect over months is what made running multiple ventures sustainable for one operator.

Three ways vaults break

The vault works only if you respect the structure. Three patterns where vaults silently degrade. Hover any card to see the diagnosis.

The fix in all three: one concern per folder, the convention is the discipline. When you find yourself wondering “where should this go,” the convention is failing — usually because the folder boundaries are blurring.

The cross-reference test

The single best diagnostic for whether your vault is working: ask your agent to walk a typical question and tell you what files it has to read.

Pick a recent question I asked you about my work — anything from
the last week. Then walk through what files you'd need to read to
fully answer it.

For each file:
- Where in the vault does it live?
- Is the file the AUTHORITATIVE source for this concern, or is it a
  copy / derivative / mention from elsewhere?
- If it's not authoritative, where IS the authoritative version?

If you find a question that requires reading the same concern from
three different folders, that's a duplication problem — note it.
The vault is broken when one concern has multiple sources of truth.

If the agent answers a question by reading 1-3 files, your vault is working. If the answer requires reading the same concern from three different places, you have duplication — fix the routing before adding more content.

A healthy vault has roughly this read pattern for typical questions:

• People question: 1 file in 06-People/ + maybe 1 meeting note that links from there.
• Decision question: 1 file in 07-Decisions/ — that’s the authoritative source. Meeting notes link to it; they don’t duplicate it.
• Knowledge question: 1 file in 09-Research/ + the index. The wiki page synthesizes the source notes; the agent doesn’t need to scan source notes individually.
• Project status: 1 file in the venture folder + maybe 1 memory entry that points to it.

If your read pattern looks more like “agent reads 8 files to answer a basic question,” the structure is failing. Run the audit.

Annotated transcript

A real conversation with an operator coming off SaaS sprawl, asking how the vault model maps to what they had. Click any pinned annotation under an agent reply to expand the “why this turn matters” commentary.

The 13-folder convention

The structure that scales from one venture to many without restructuring.

You don’t need every folder for a small project. A solo operator with one venture might use 06 folders heavily and ignore 13. A multi-venture portfolio uses all 13. The convention is the priority order; you fill in what your work needs.

When you add a new venture, you add a new numbered folder. 14-Venture-C. The structure scales without restructuring because the numbering is non-contiguous when extending.

The five rules that scale

The convention works because of these rules, not because of the specific folder names. Steal the rules; rename the folders to match your work.

1. One concern per folder, never two. Decisions live in 07-Decisions/. Always. Not sometimes in venture folders.
2. Numbered top-level prevents alphabetical drift. “Strategy” and “Stuff” sort alphabetically; numbered folders sort by your priority.
3. 09-Research/index.md is mandatory. The agent’s knowledge load happens through this file. Without it, the wiki is invisible.
4. Source notes are immutable. Synthesis pages can be rewritten; raw captures stay as captured. This separation is what makes the wiki trustworthy.
5. Front-matter on everything. Templater-compatible YAML front-matter on every note. Enables Dataview queries, agent routing, downstream automation.

Together these rules are more important than the 13 folder names. If your work needs different folders, change the names; keep the rules. If you keep the names but break the rules, the vault degrades within weeks.

Three diagrams

Prompt kit

Three prompts for keeping the vault healthy. Save in your CLAUDE.md or a personal snippets file.

Pick a recent question I asked you about my work — anything from
the last week. Then walk through what files you'd need to read to
fully answer it.

For each file:
- Where in the vault does it live?
- Is the file the AUTHORITATIVE source for this concern, or is it a
  copy / derivative / mention from elsewhere?
- If it's not authoritative, where IS the authoritative version?

If you find a question that requires reading the same concern from
three different folders, that's a duplication problem — note it.
The vault is broken when one concern has multiple sources of truth.

Scan the vault root.
For each top-level folder, list 3 files inside it.

For each file, ask: does this file actually belong in this folder?
Or is it a duplicate / mention / wrong-place file that should live
elsewhere?

Flag anything that should be moved. Suggest the destination folder
and the reason.

The goal: every file has one obvious home, derivable from the
folder convention without thinking.

Scan 00-Inbox/ and 09-Research/Inbox/ for unprocessed captures.
For each, ask: is this a candidate for a synthesis page in 09-Research/?

Output a list of proposed wiki pages with:
- Title
- One-sentence summary
- Source captures it would synthesize from

If a topic appears in 3+ places without a synthesis page, it's
clearly missing. Flag those first.

Apply this — install and populate

60-minute exercise. The vault feels useful within an hour and natural within a month. Most operators bail in week 1-2 because the friction is real and the payoff is invisible. The lesson is to expect that.