Obsidian and AI: Architect vs. Gardener Notes

Capturing notes has never been easier. A browser extension clips an article into your second brain in one click. A voice memo gets transcribed automatically. An LLM can summarize a meeting, a book, a codebase, and hand you back three paragraphs you didn’t have to write. The bottleneck used to be getting the note down. It isn’t anymore.

Which makes the question that’s left standing more important, not less: once the note exists, where does it go, and how do you find it again? That question predates AI by decades — but AI changes the answer in a way most people haven’t noticed yet, because your notes aren’t just for you to search anymore. They might be for an LLM to search on your behalf.

This post covers the two classic answers to “where does it go” — Architect and Gardener — what they actually mean mechanically (not just as a personality quiz), when each wins, and then the part that’s new: what changes once an LLM, not just you, is the one doing the retrieval. I rebuilt my own Obsidian vault around these ideas this week, so the examples in the second half are real, not hypothetical.

Two Ways to Organize a Second Brain

Both styles answer the same question — “how do I find this note again in six months?” — with a different source of truth.

Architect: folders are the source of truth. You decide the category in advance, file the note into it, and find it later by browsing down a tree you designed. A note lives in exactly one place.

Gardener: links are the source of truth. Folders become shallow, loose buckets — what stage a note is at, not what deep category it belongs to. You find things by following backlinks and by curated hub notes (MOCs — Maps of Content) rather than by remembering a path. A note can be relevant to five different contexts at once, because nothing forces it into one folder.

Neither is “correct.” They’re optimized for different failure modes:

Architect, in Practice: PARA

The most common Architect implementation for a personal knowledge base is PARA (Projects / Areas / Resources / Archive), from Tiago Forte’s Building a Second Brain. The sorting rule is a single question: is this actionable?

• Projects — has a deadline and a defined “done.” Time-bound.
• Areas — a standard you maintain indefinitely. No end date (health, a role, a discipline).
• Resources — reference material, useful for future projects, not tied to one right now.
• Archive — anything from the above three that’s no longer active.

A worked example, for someone doing engineering management work:

Projects/
  Q3 Hiring Push/
  Migrate CI to Buildkite/
Areas/
  Engineering Management/
    Agile/
    Skills/
  AI/
Resources/
  Book Notes/
  Clippings/
Archive/

Pros: zero ambiguity about where anything is. Works immediately, with no linking discipline required. Anyone can browse it cold, which matters if a teammate needs to find something without asking you first. Predictable, stable paths are easy for scripts and automations to target.

Cons: a note can only live in one place. A book about the Theory of Constraints is simultaneously “Resources” (reference) and arguably “Areas/Engineering Management” (a standard you apply) — PARA forces a single home, so cross-cutting ideas get artificially bucketed or duplicated. Reorganizing later means physically moving files, not just retagging. And it reveals only the connections you already planned for, not the ones you’d discover by accident.

Gardener, in Practice: Growth Stages and MOCs

Gardener style borrows its vocabulary from actual gardening. The core idea — a note that’s atomic, densely linked, and written to stand on its own — comes from Andy Matuschak’s “evergreen notes.” The specific seedling → budding → evergreen growth-stage tagging convention isn’t Matuschak’s own taxonomy; it’s a broader digital-garden community practice that extends his “evergreen” quality criteria into a staged progression you tag directly on each note:

• 🌱 seedling — raw capture, unprocessed, maybe one sentence and a link
• 🌿 budding — reworked in your own words, linked to one or two other notes
• 🌲 evergreen — stable, densely linked, could stand alone if someone else read it

A note’s folder barely changes over its life. Its tag does, as you rework it. This is the actual mechanism — not a vibe, a real frontmatter field:

---
title: "Cardinality explosion"
tags:
  - "🪴budding"
  - "observability"
created: 2026-08-10
---

Instead of deep folders, a Gardener vault leans on two other structures:

MOCs (Maps of Content) replace category folders. Instead of Areas/Engineering Management/Agile/Kanban/, you’d have one flat notes folder and an Agile MOC.md that just links out to whatever’s relevant — [[Kanban Overview]], [[Scrum Notes]], [[Agile Manifesto]] — and also anything else that touches Agile, wherever it physically sits. The MOC is the real category; the folder is just storage.

Backlinks do the rest. Open any note and see every other note that links to it, discovered automatically, not maintained by hand. This is where unplanned connections actually surface — the thing Architect-style folders structurally can’t do, because a folder only shows you what you already decided belonged together.

Pros: a note can be relevant to multiple topics without duplication. Backlinks surface connections you didn’t plan for. Cheap to restructure — retag, don’t re-file. Scales well as a vault grows past a few hundred notes, where a folder tree usually calcifies.

Cons: falls apart without discipline. An unlinked note is functionally lost — there’s no folder fallback to stumble onto it. Harder to see structure “at a glance” since it’s not spatial. MOCs need upkeep or they go stale. Onboarding someone who expects folders takes longer.

Best Practices That Apply to Either Style

A few things are worth doing regardless of which model you pick:

• Atomic notes. One idea per file, not one topic per file. A note titled “Agile” that tries to hold the manifesto, Kanban, Scrum, and your own opinions in one file is neither browsable nor linkable at the granularity that matters.
• Consistent frontmatter. Even a minimal, repeated schema (title, created, tags) beats an inconsistent rich one. Consistency is what makes any later automation — a script, a Dataview query, an LLM — able to rely on the shape of your notes rather than parsing prose to guess at it.
• Daily notes are an inbox, not a destination. Capture into a daily note with zero friction, then within a day or two, pull anything worth keeping out into its own atomic note, linked back to the day it came from. The daily note itself should be disposable scaffolding, not where knowledge actually lives.
• Review and promote, don’t let capture rot. A 🌱 seedling that’s never revisited is just clutter with extra steps. The promotion step — rereading, linking, retagging — is where you actually learn the thing, not the capture step.

Does AI Change Any of This?

Yes — and the reasoning is less about theory and more about how retrieval actually works once the reader isn’t only you.

Folder depth is weak signal for a search tool; frontmatter is strong signal. An LLM, a grep-based agent, or an embedding index doesn’t browse the way a human does — it searches, in roughly the same way an agent managing its own context window has to decide what’s worth keeping in view. Areas/AI/Agents/Orchestration/Toolings.md tells a search tool almost nothing that tags: [ai, agents, orchestration] in frontmatter doesn’t tell it better and more flexibly. Structured, parseable frontmatter is the single highest-leverage thing you can do for future tooling — more leverage than the folder decision itself.

[[wikilinks]] are a retrieval graph, for free. When a tool pulls up one note, its backlinks and outgoing links tell it exactly what else to pull in for context — no embedding model, no folder-guessing required. It’s the same problem a multi-session agent’s memory system solves for itself: what’s worth carrying forward isn’t a folder path, it’s a link. A deep Architect tree can’t offer this: a note either “is” in Areas/Engineering Management/ or it isn’t, full stop. A linked note surfaces from five different angles.

One-folder-per-idea is a constraint that actively hurts here. Real content is cross-cutting more often than not — a post about observability cost economics is simultaneously “writing,” “AI,” and “engineering management” reference material. Architect-style forces a single home for that. An LLM asked “what do I know about telemetry cost economics” would miss it entirely if it only searched one folder. A Gardener setup just tags and links it into all three, and it’s findable from any of them.

MOCs double as ready-made orientation documents. A well-kept MOC — a curated link list on one topic, written by a human who understood the domain — is exactly the shape of document that’s cheap for an LLM to read first, before deciding what to pull in next. That’s cheaper and more reliable than inferring scope from folder names.

None of this means folders become useless. They’re still a good coarse filter — “only search Writing/” is a real, cheap scoping mechanism that needs no graph traversal at all. The shift is that folders stop being the primary organizing principle and become a filter on top of the graph, not the other way around.

A Real Example: Rebuilding My Own Obsidian Vault

Theory is easy to nod along to. Here’s what it looked like to actually do this, this week, on a real vault.

I found four separate Obsidian vaults nested inside one iCloud folder: a typo’d Mangement vault (the real, actively used one — 29 files, the only one with plugins installed), a standalone AI vault, a Reading notes vault, and the root folder itself, which was also its own vault. Because Obsidian’s search and graph don’t cross vault boundaries, AI-related notes were split across two of these and could never link to each other. Some Book Notes had zero frontmatter; Clippings had rich frontmatter from a browser extension; a Fleeting inbox had a template with a growth-stage tag sitting on exactly one note. Familiar, if you’ve ever let a note vault run for a year without a second pass.

The rebuild consolidated everything into one vault, structured Gardener-first:

📥 Inbox/          — daily captures, unprocessed 🌱 notes
🌱 Notes/          — the garden itself: flat, tagged by growth stage
🧭 MOCs/           — topic hubs: Agile, AI, Book Notes, plus one per writing series
✍️ Writing/        — this blog's own posts, one folder per series
🗞️ Clippings/      — saved articles, merged from two separate folders
📎 Assets/         — images, flattened out of nested subfolders

The part worth quoting real numbers on: this blog’s own posts got pulled into the vault as a worked example of making writing “LLM-wiki friendly,” not just filed away as flat text. Every post’s Jekyll frontmatter converted into clean Obsidian frontmatter (title, date, tags, source back to the live URL); every internal cross-reference between posts — the “Part 3 → Part 4” links, the inline “as Part 7 covered” mentions — got rewritten from a relative URL into a real [[wikilink]]. 487 links, across 62 posts, with zero broken after verification. That’s 487 edges in a graph that used to be 62 disconnected files.

Two real bugs came out of doing this mechanically instead of by hand, worth knowing if you ever script something similar: a title containing a colon (Part 8: Logging) needs its wikilink target to match the actual filename exactly — sanitize the filename and forget to sanitize the link text identically, and you get a link that looks right but resolves to nothing. And a title containing a forward slash (SDK/ACP) will silently become two path segments if you don’t catch it before it hits the filesystem. Both are boring bugs, and both are exactly the kind that don’t show up until you check — which is the whole argument for verifying link resolution programmatically rather than trusting that a batch rewrite worked.

Managing a Vault With Claude Code and OpenCode

None of the migration above happened inside Obsidian. It happened in a terminal, with Claude Code reading and writing plain files. That’s worth pausing on, because it’s the actual reason a Gardener vault built on Markdown and YAML is a better long-term bet than any note app with a proprietary format: there’s no API wall. An Obsidian vault is just a folder of .md files with frontmatter. Any coding agent that can read and write files — Claude Code, OpenCode, Cursor, whatever comes next — can operate on it directly, with the same tools it would use on a codebase.

The actual recipe, generalized past this one migration:

1. Back up before anything touches the vault. A plain recursive copy to a timestamped folder, before the first write. This isn’t optional caution — it’s what makes an aggressive rewrite low-risk instead of a leap of faith.
2. Script the mechanical transform, don’t hand-edit. Parsing 62 files’ frontmatter by hand invites exactly the kind of small, silent inconsistency that a script applies uniformly instead.
3. Verify programmatically, not by eyeballing. The check that mattered here was three lines of logic: collect every real filename in the vault, walk every [[wikilink]], flag any target that isn’t in that set. That’s what caught both bugs above — not a read-through.
4. Rebuild the derived files (the MOCs, the home note) from the same data, so they can’t drift out of sync with what actually got migrated.

Turning the Recipe Into a Skill

A one-off script is fine for a one-time migration. For anything you’d want to repeat — auditing link health monthly, promoting stale seedlings, rebuilding a MOC after adding ten new notes — the better unit is a skill: a packaged, reusable instruction set the agent loads on request instead of you re-explaining the task from scratch every time.

Both Claude Code and OpenCode support the same underlying idea, just with slightly different plumbing. A skill is a folder with a SKILL.md file: a short frontmatter header (a name and a description the agent uses to decide when this skill is relevant) followed by plain-markdown instructions for what steps to follow. Drop a real script alongside it — Python, a shell script, whatever the deterministic part of the task actually needs — and the SKILL.md becomes the glue that tells the agent when to reach for that script and how to interpret what it returns. You invoke it by name (a slash command) or let the agent pick it up automatically when your request matches the skill’s description — you’re not re-explaining the task from scratch each time, you’re pointing at the skill.

A vault-maintenance skill would follow that same shape — frontmatter that says when to reach for it, instructions for what to actually check:

---
name: vault-gardener
description: Use when the user asks to audit, clean up, or maintain their Obsidian
  vault — checking for broken links, orphaned notes, stale seedlings that need
  promoting, or MOCs that have drifted out of sync with the notes they list.
---

# Vault Gardener

## Link health
Walk every `[[wikilink]]` in the vault. Collect every real filename.
Flag any link whose target isn't in that set — report file + broken target,
don't silently fix (a human should decide whether the target moved or the
link is just wrong).

## Stale seedlings
Find every note tagged 🪴seedling with no edits in 30+ days. These are
either worth promoting to 🪴budding (link it to something, rewrite it in
your own words) or worth deleting — flag them, don't decide for the user.

## Orphan notes
Find every note with zero incoming and zero outgoing links. In a Gardener
vault this is the equivalent of a note nobody can find — surface it.

## MOC drift
For each MOC, compare its linked notes against notes actually tagged with
that MOC's topic. Report notes that should probably be added, and links
that point at notes that no longer exist.

That’s the whole trick: the same discipline that made the blog-post migration safe — back up, script it, verify, don’t trust by eye — packaged so it’s one request (“clean up my vault”) instead of a fresh conversation explaining the task each time. The skill doesn’t do anything a script couldn’t; it just means you stop re-writing the script.

Where to Start

If you’re starting from nothing: don’t design the perfect taxonomy first. Start with a flat notes folder, a Fleeting/inbox capture habit, and the discipline to link a new note to at least one existing note before you consider it “done.” The MOCs and growth tags can come once you have forty or fifty notes and can feel where the actual clusters are — a taxonomy designed before you have content to organize is usually wrong, and Gardener-style makes being wrong cheap to fix, since fixing it means retagging, not re-filing.

And if part of the goal is a personal wiki you’ll eventually point an LLM at — a coding agent, a research assistant, anything that reads your notes to help you — bias early toward consistent frontmatter and real [[links]] over folder depth. That’s the part that’s expensive to retrofit later and nearly free to do from the start.

References

• Tiago Forte, Building a Second Brain — the PARA method
• Andy Matuschak, “Evergreen notes” — the growth-stage vocabulary
• Obsidian — the tool used for every example above