Obsidian Company Brain: The Folder Structure I Use

A Folder Replaced My Tech Stack

I've tried ClickUp, Notion, Trello, Asana, Monday, and a half-dozen CRMs. Every single one did too much, charged per seat, and owned my data. In 2023 I moved everything into Obsidian — a local-first markdown editor with no cloud dependency. Two years later, it runs my entire agency.

50+ clients. Sales pipeline. Proposals. Processes. Finance. Blog strategy. Product specs. Client one-pagers. All of it lives in a single vault on my machine. Backed up to Git. Queryable by AI via Cortex. No subscription. No API rate limits. No vendor lock-in.

That vault is my company brain. This post is the exact file structure I use, why each folder exists, and how I turned it into a deployable product for clients.

What Is an Obsidian Company Brain?

An Obsidian company brain is a single vault that holds how your business actually runs — clients, processes, pricing, decisions — as linked markdown files that any person or AI can read cold. It is a second brain with a different owner: it belongs to the business, not to one person's thinking.

That difference changes what goes in it:

• A second brain captures ideas, reading notes, and half-formed thoughts. It only has to make sense to you.
• A company brain captures decisions, procedures, and the current state of every client. It has to make sense to someone who wasn't in the room — a new hire, a contractor, or an AI session starting from zero.

The test is simple: if you disappeared for two weeks, could someone open the vault and keep the business running? If the answer lives only in your head, your email, or a SaaS tool you can't export from, it isn't in the brain yet. Everything below is built to pass that test.

Why Obsidian Over Everything Else

The pitch for every SaaS tool is the same: "We'll organize your business." The reality is also the same: you spend more time configuring the tool than doing the work. Then the pricing changes, the API breaks, or they get acquired and sunset your favorite feature.

Obsidian is different because:

• Local-first. Your data is markdown files on your machine. Not in someone else's database.
• No lock-in. Every note is a .md file. Move it anywhere. Read it with anything.
• Wikilinks. Double-bracket links between notes create a knowledge graph. Your notes connect to each other, and those connections become queryable.
• Zero recurring cost. The app is free. Sync is optional. Plugins are community-built.
• AI-compatible. Markdown is what LLMs read best. Your vault is already structured for AI retrieval — you just need something to walk the graph.

The File Structure

Here's the actual folder structure I use. Not a template — the real thing. Every folder earned its place by being used daily, weekly, or monthly. If it wasn't pulling its weight, I archived it.

CLAUDE.md            # Loads first in every Claude Code session — routes it
_CONTEXT.md          # Full company context, one read
Tags Index.md        # Tag taxonomy — keeps tagging consistent

Company/             # Mission, model, positioning, site overview
Clients/             # One-pager per client (status, stack, notes)
Sales/               # Pipeline, objection handling, pitch decks
Proposals/           # Drafts, sent, signed — mirrors CRM states
Finance/             # Pricing, invoices, retainers, projections
Processes/           # SOPs, delivery runbooks, checklists
Product/             # Product strategy and specs
Highlander/ Doon/    # One folder per product's docs — the code
Gateway/ ...         #   repos symlink in here

Marketing/           # Content calendar, outreach, campaigns
Blogs/               # Blog strategy, drafts, ideas
SEO/                 # Keyword research, ranking tracking
Brand/               # Brand kit, colors, voice guidelines

Security/            # Threat intel, audit reports, incident logs
Research/            # Industry research, competitive analysis
Templates/           # Reusable templates (proposals, reports, briefs)

Notes/               # Inbox — tag and move when stable
Archive/             # Deprecated notes — never delete, just archive
      

A few things to notice:

• CLAUDE.md is the front door. Claude Code loads it automatically at the start of every session in the vault, so it's the one file guaranteed to be read. It says what the business is and where to look, and points to _CONTEXT.md for the full picture.
• Notes/ is an inbox, not a folder. New thoughts go here. When they're stable, they get tagged and moved to a permanent folder. This prevents the "where does this go?" paralysis.
• Product docs live in the vault, and the code links in. Each product has a folder here, and its code repo holds a symlink pointing at that folder. The docs are written once, searchable alongside business notes, and readable from inside the codebase.
• No plugins required. This structure works with zero community plugins. Wikilinks, tags, and folders are all you need.

The Context File Pattern

Every vault needs one place that answers what an AI (or a human) would ask in the first 5 minutes of looking at your business. In mine that's _CONTEXT.md, and it covers:

• Who & what — company name, founder, model, client count, core product
• Positioning — the one-line pitch and key differentiators
• What we sell — offerings table with price anchors
• Vault entry points — where to start, so a session opens the right note instead of reading everything
• Key files by task — "If you need to do X, go to Y"
• Vault rules — what's read-only, what's an inbox, how tags work

When I open a Claude Code session in the vault, CLAUDE.md loads before I type anything, and it points the session at the context file and the right notes. Cold start time drops from 10 minutes of explanation to zero. The AI knows who I am, what I'm building, and where to find everything.

Claude Code + Obsidian: Should Every Folder Get a CLAUDE.md?

No. Put one at the top of each unit of work: a codebase, a client project, a tool with its own rules. Not in every folder.

Here's how Claude Code actually reads them, according to Anthropic's documentation on Claude Code memory:

• At launch: the CLAUDE.md in the folder you start in, and one in every folder above it, all load immediately.
• On demand: a CLAUDE.md in a subfolder loads the first time Claude reads or edits a file in that subfolder.
• Stacked, not replaced: every file that loads is added to the context. None overrides another, so two files that contradict each other leave Claude to pick one.
• Short: the guidance is under 200 lines per file. Longer files cost context and get followed less reliably.

Put those together and a CLAUDE.md in every folder of a vault is a bad trade. Each one loads as soon as Claude touches a nearby note, adds to the pile, and has to stay consistent with all the others. A knowledge vault doesn't divide into units of work the way a codebase does. It's one body of knowledge, already connected by links.

So the vault gets one CLAUDE.md, at the root, and its job is to route, not to hold. It says what the business is and which note answers what, so a session goes straight to the one note it needs instead of reading the whole vault. Hub notes and wikilinks do the rest. Codebases are different: each repo is its own unit of work and gets its own CLAUDE.md, and a subfolder gets one only when that part of the code has rules the rest doesn't.

vault/CLAUDE.md            # One, at the root. Routes to the right note.
client-site/CLAUDE.md      # One per codebase.
client-site/api/CLAUDE.md  # Only if this part has its own rules.
      

What about AGENTS.md? If other AI coding tools work in the same folder, keep the shared instructions in AGENTS.md and make the first line of your CLAUDE.md @AGENTS.md, which imports it. Claude Code only reads an AGENTS.md on its own when there's no CLAUDE.md, so with both present, the import is what keeps every tool on one set of instructions.

Wikilinks Are the Architecture

The folder structure organizes your vault spatially. Wikilinks organize it semantically. When a client note links to a process, and that process links to a template, and that template links to a product spec — you've built a knowledge graph without installing anything.

This is what makes it AI-queryable. Araptus Cortex walks these wikilinks as a graph. Ask Claude about a client's project, and Araptus Cortex follows the links from the client note → to the process → to the product spec — delivering structured context at configurable depth.

No embeddings. No vector database. No cloud. It starts from the connections you already made between your notes, and it can find the ones you haven't made yet.

Jake Van Clief puts the principle better than I can: "If you structure the data right, one model can become as many agents as you need as it navigates that data." He and David McDermott formalised it as a folder-based method with numbered stages and a contract for each one. I break down Van Clief's folder structure here. A company brain is the knowledge half of the same idea. The other half is what happens when several agents work at once, which is where parallel AI coding agents collide.

What Cortex Adds Over Plain Folders

Folders and wikilinks give you a vault a person can find their way around. The trouble starts at scale. Past a thousand notes, the answer to a question is often in a note nobody linked to it, and a session that guesses the wrong folder answers from the wrong note.

That's the gap Araptus Cortex closes. It adds three things plain folders can't:

• Search across everything. It indexes every note, link, embed and tag, so a session can find the note instead of guessing where it lives.
• Ranking that learns from use. Notes that keep getting opened together build stronger connections, and unused ones fade. The notes that actually answer questions rise to the top.
• Connections you haven't made. It suggests missing links between notes that belong together, so the graph gets more complete over time instead of only as complete as your linking habits.

It does all of this without embeddings or a cloud service. It's a single binary on your machine, reading the markdown you already have.

Turning It Into a Product

After running my business from this vault for two years, the question became obvious: why don't my clients have this?

Most small businesses run on a combination of sticky notes, email threads, Google Docs they can never find, and a CRM they barely use. Their institutional knowledge lives in the founder's head. When they're sick, on vacation, or scaling — that knowledge is unavailable.

So I productized the vault into a Client Business Brain — the deployable version of this is Araptus Cortex, our knowledge engine — same structure, adapted for their industry. We deploy it in a single Claude Code session on their machine:

• Vault Core — Company/, Processes/, Templates/, dashboards, _CONTEXT.md
• Blog Module — Blogs/ folder with templates and a /blog skill
• Press Release Module — newswire-format templates and a /press-release skill
• Marketing Module — content calendar, campaign planning
• Finance Module — invoice tracking, pricing summary
• Sales Module — pipeline, pitch materials, objection handling

Each module creates the folders, seeds the templates, and installs Claude Code skills so the client can generate blog posts, press releases, and reports from their own context — using their own business data.

They keep everything. We leave nothing behind except a working system. Their data never leaves their machine.

Principles That Make It Work

• One vault, one truth. Don't split across multiple vaults. One vault with clear folder boundaries beats three vaults you can't cross-reference.
• Inbox → permanent. Notes/ is the inbox. Everything starts there. When it's stable, tag it and move it to the right folder. This prevents decision paralysis on capture.
• Archive, never delete. Old notes aren't trash — they're history. Move deprecated content to Archive/. You'll search it someday.
• Tags in frontmatter. Use YAML frontmatter tags, not inline hashtags. They're queryable, filterable, and machine-readable.
• A context file is non-negotiable. Every vault needs a front door that tells a new reader (human or AI) what the business is and where everything lives. For Claude Code, that's a CLAUDE.md at the root. Update it monthly.
• Symlink, don't copy. Keep documentation in the vault and symlink it into the code repo that needs it. One source of truth, readable from both places.
• Earn your folders. Don't create folders speculatively. A folder earns its place by having 3+ notes in it. Until then, it lives in Notes/.

Getting Started

You don't need to build the whole structure on day one. Start with three folders and one file:

1. CLAUDE.md — Write down who you are, what you do, and where things live. One page. Claude Code reads it at the start of every session.
2. Notes/ — Your inbox. Everything goes here first.
3. Company/ — Move your mission, positioning, and team info here when it stabilizes.
4. Processes/ — The first time you explain how you do something, write it down here. It's now an SOP.

The vault grows with your business. In six months you'll have a system that no SaaS tool can replicate — because it's built from your actual workflows, not someone else's template.

Obsidian Company Brain: Common Questions

Do I need plugins to build a company brain in Obsidian?

No. Folders, wikilinks and YAML frontmatter tags are enough. Plugins can help later, but every one you add is something that can break or be abandoned. The structure should work without them.

How is an Obsidian company brain different from Notion?

Notion stores your pages in its database, on its servers, behind its pricing. An Obsidian vault is a folder of plain markdown files on your own machine. You can back it up with Git, read it with any editor, and hand it to any AI model. Nothing has to be exported, because it was never locked in.

Can AI tools read an Obsidian vault?

Yes, and that's the main reason to build one. Markdown is the format language models read best. Start with a single context file that says who you are, what you sell and where things live, and any AI session can pick up your business in one read.

Where should I start?

Small: one context file, an inbox folder, and a folder for processes. Write down a process the second time you explain it. The rest of the structure grows as the business uses it.

Where should CLAUDE.md go in an Obsidian vault?

At the root, once. Claude Code loads it when a session starts in the vault, so it should say what the business is and where things live, then send the session to the right note. Don't add one to every folder: a subfolder's CLAUDE.md loads whenever Claude touches a file there, and every one that loads stacks up in context. Save extra CLAUDE.md files for separate units of work, like a codebase.

Do I need AGENTS.md too?

Only if other AI coding tools work in the same folder. Then keep the shared instructions in AGENTS.md and import it from the top of CLAUDE.md with @AGENTS.md. Claude Code reads an AGENTS.md by itself only when there's no CLAUDE.md.

Can my whole team share one company brain?

Not comfortably in Obsidian alone. A vault lives on one machine, so a teammate who needs it gets files emailed or a git lesson. We're building the team version, Araptus Shared Brain, a shared second brain your people and your AI work in together, and it's open for early access.