§

Why I Run My Consulting Practice on Obsidian and Claude

Jason

·

Most consulting practices run on a stack: a CRM for pipeline, Notion or Google Docs for project notes, Slack for client comms, ChatGPT for synthesis, a series of vendor tools each storing one slice of the institutional memory. The setup looks normal. It works fine until you try to add an AI coworker into the loop, and then the seams show.

The reason the seams show is that every layer between the model and the underlying bytes is a tax. An LLM working in your workspace can do three things well: read files, write files, and search files. The more layers of database abstraction, API rate limits, and OAuth handshakes sit between the model and the actual content, the less useful the model is. A folder of plain markdown files turns out to be the cleanest workspace I have found for working with Claude as a coworker. I run mine in Obsidian.

This post is the first in a short series about why. The worked examples in this and the follow-up on PARA come from Not Really Wines, our fictional demo winery at NunnCurtis Labs — a brand we built precisely so we can show this kind of workflow without surfacing real client information.

Why a SaaS Stack Breaks Down When You Add an AI Coworker

Three problems hit consulting practices that try to staple an LLM onto a normal SaaS stack:

Retrieval falls off the back of every chat. A useful synthesis happens inside a ChatGPT or Claude conversation. The chat scrolls. Next week, the model has no memory of what you discussed. ChatGPT projects help a little. They do not solve the underlying issue, which is that the model's working memory and the place your knowledge actually lives are two different surfaces.

Context handoff is forty-five minutes of copy-paste. Drafting an audit, a proposal, or a strategic memo for a client typically requires pulling from three to six places: the client's interview transcript, their analytics export, your running notes, your scoring rubric, screenshots of whatever you are evaluating. Each of those lives in a different tool. Getting them into one place so the model can actually help means more setup time than the actual thinking takes.

You don't own the data. A consultant's most valuable long-term asset is the accumulated reasoning behind the deliverables — which approaches worked for which kind of client, which assumptions kept failing, which patterns are now reliable. That reasoning gets scattered across vendor databases the firm does not own and cannot export cleanly. When you decide to leave a tool, you lose it.

A single workspace where the work lives, where you own the data outright, and where Claude can read and write into the same files you read and write into — that is the shape the problem wants. Obsidian fits the shape.

Why Obsidian, Specifically

Obsidian is a markdown editor with a plugin ecosystem and a strong norm: every note is a plain text file on your disk. That property is the entire point. A vault is just a folder. Notes are just .md files. Metadata lives in YAML frontmatter at the top of each file. Links between notes are wiki-style brackets that resolve to filenames.

This sounds unsophisticated until you see what falls out of it:

  • Anything that reads a file can read your notes. No API. No OAuth. No webhook.
  • Anything that writes a file can write a note. Including Claude, via the filesystem MCP server.
  • Anything that searches files can search the vault. ripgrep works. git grep works. Spotlight works.
  • You own the data. If Obsidian disappeared tomorrow, the workflow does not move. The same folder opens in VS Code and the work continues.

Notion is a prettier product. It is also a black box of opaque blocks living on someone else's database, retrievable only through a rate-limited API that does not natively map to the way LLMs read files. Notion is fine for teams that need shared collaborative documents. For a knowledge worker who wants an AI coworker reading and writing alongside them, every layer of database abstraction between the model and the bytes is a tax.

How the NRW Vault Is Organized

The structural argument is easier to see in a worked example. The Not Really Wines vault — which we run as a public demo at NunnCurtis Labs — is organized around a PARA core with a few practical extensions for AI-coworker use:

/1_Projects/    — active, deadline-bound work
/2_Areas/       — brand, people, DTC, wholesale, ops — ongoing functions
/3_Resources/   — compliance, market intel, SEO reports, pulse archive
/4_Inbox/       — incoming items waiting for triage
/5_Calendar/    — week-at-a-glance by ISO week
/6_Skills/      — reusable Claude skills (brand voice reviewer, SEO auditor)
/7_Schedules/   — recurring task definitions

The folders are scaffolding. The real organization happens at the file level via frontmatter. Every project note carries fields like status, started, due, owner, contributors, and related-areas. Every meeting note carries date, attendees, decisions, and followups. The Dataview plugin queries those fields to generate the pages a human actually looks at: an active-engagements board, an open-followups list, a queue of areas that have not been reviewed in fourteen days. None of these views require Claude. They run on plain text.

The thing the metadata buys you when an LLM is in the loop is precision. Claude does not have to guess what a file is for. It reads the frontmatter and proceeds accordingly. This is a project, status active, due in three weeks tells the model an entirely different thing than this is an Area note last reviewed eight months ago. The folder structure and the YAML headers together do most of the work that a long system prompt would otherwise have to do.

Where Claude Plugs In

Claude shows up inside the vault two ways, and they serve different purposes.

Claude Desktop with the filesystem MCP server pointed at the vault. MCP — the Model Context Protocol — is the open standard Anthropic shipped for letting Claude read and write external resources without bespoke integrations. The filesystem MCP server runs locally, gets read-write access to the vault, and Claude treats it the way a person would: it lists files, opens the ones it needs, edits them in place, creates new ones, and threads them together. When a client emails a question, paste the email into Claude, point it at that client's project folder, and Claude returns a draft response that has actually read the three most recent meeting notes and the last audit. No copy-paste setup. No re-uploading transcripts. The vault is the context.

Claude Code, run from the terminal inside the vault directory. This is the shape worth reaching for when the task is real work rather than answering email. Drafting a long-form audit that pulls from a stack of reference notes. Synthesizing a sequence of client check-ins into a quarterly review. Producing a first-pass scorecard from a folder full of raw screenshots and notes. Claude Code can read many files in parallel, hold them in context together, and return a draft to edit rather than a draft to rewrite.

One rule worth keeping strict: Claude writes drafts; I publish. Every file Claude creates inside the vault opens with a status: draft frontmatter line. Nothing leaves the vault for a client without me reading it first. The model is fast. It is not always correct. The point of a coworker is not to remove judgment from the loop. It is to remove the friction around the judgment so judgment is where the time actually goes.

Why the Mechanism Matters

"What does this actually let you do?" is the question worth answering. It removes the copy-paste tax that sits between thinking and writing. The mechanism behind that has three pieces.

One: the model has memory because the filesystem has memory. Opening a client conversation with Claude does not start from zero. The model reads the client folder, surfaces the relevant prior decisions, and the conversation picks up where it left off — even if "last time" was four months ago and a different chat session.

Two: thinking and writing share a surface. Notes taken during a client call are the same notes Claude reads to help draft a follow-up. The follow-up is the same file Claude reads when drafting next month's check-in. There is no translation step. Nothing gets re-explained because nothing was ever in a different place.

Three: the practice compounds. Every audit leaves behind a structured note. Every reusable framework gets a file in Resources. Every winery the firm learns something from gets a People note tagged with what was learned. Over time the model can pattern-match across the firm's entire history rather than re-discover the same conclusions in every new engagement.

What's Still Awkward

A few things still break.

Mobile is rough. Obsidian on iPhone works, but writing Claude prompts against a vault from a phone is unpleasant. Voice memos transcribed via Whisper into /4_Inbox/ for later sorting are the only mobile pattern that survives day-to-day use.

Embedded media is a friction point. Screenshots, PDFs, and audio files live in the vault but the model's reading of them is uneven. Keeping a separate /assets/ subfolder per project, and being explicit about which files to look at, helps — at the cost of more friction than you would want.

Search-against-everything sometimes hits context limits. Asking Claude to synthesize across the whole vault — every project, every Area, every Resource — does not fit into a single context window for a vault past a few thousand files. The workaround is to maintain lightweight indexes and summaries that Claude reads first, then pulls in detail files as needed. It works. It is more architecture than most users want to be doing.

None of these are dealbreakers. They are the kind of friction you expect from a workflow built on top of a category — local-first AI coworkers — that is itself only a couple of years old.

Why It Matters for the Wineries We Work With

The reason this post lives on the NunnCurtis Labs blog and not on a generic productivity site: this is the same pattern we increasingly recommend to wineries that want to make AI part of their actual operations, not just their marketing copy.

A winery is a knowledge business pretending to be a beverage business. The institutional memory of a 30-year operation — what blocks ripen first in a hot year, which distributor handled the 2018 release best, what the tasting notes were when the assistant winemaker took over the chardonnay program in 2020 — is exactly the kind of structured-but-unstandardized text that lives badly in CRMs and POS systems and lives well in markdown. The wineries that figure out how to make that memory accessible to AI, on their own terms, without handing it over to a vendor, will have a meaningful advantage over the next decade.

Obsidian and Claude are not the only way to set this up. They are the cheapest, most durable, and most AI-native default we have found. The vault is yours. The model can read it. The software runs at consumer prices and the structuring takes a weekend. For most wineries — and for most consulting practices, agencies, and small content shops — that is the cheapest serious AI infrastructure they will ever buy.

If you run a winery and want to talk about what a setup like this would look like inside your operation, that is exactly what we do at NunnCurtis Labs. Bring your questions and a sample of the kind of institutional knowledge you wish you could ask a model about. We will show you a path from where you are to a vault you own.

Resources

← All insights