How I Turned Obsidian into an AI-Powered Knowledge System

Part 2: The Architecture That Fixed It

This is Part 2 of a 6-part series on building an AI-powered knowledge system with Obsidian and Claude Code.

1. How I Got Here
2. The Architecture That Fixed It – you are here
3. Teaching an AI Agent Your Note-Taking Rules
4. Building Workflows That Run Themselves
5. Searching 5,500+ Notes in Seconds
6. Connecting the Vault to the Outside World

In Part 1, I talked about the mess that got me here – scattered notes across apps, a career change that forced me to rethink everything, and the books that pointed me toward Obsidian. Now let’s build the thing.

This post covers the structural foundation: the PARA folder system, folder-note dashboards that update in real time, and YAML frontmatter schemas that turn plain markdown files into queryable records. By the end, you’ll have a working vault skeleton you can start using today.

The PARA Method: A Routing System for Notes

Every note-taking system fails the same way: you create notes but never organize them, so finding anything becomes a treasure hunt. PARA – created by Tiago Forte – solves this with a simple rule: every note has a destination, and that destination tells you what the note means.

PARA stands for Projects, Areas, Resources, Archives. I use a numbered-prefix variation that keeps folders sorted in a logical order:

The numbered prefixes aren’t decorative – they enforce sort order in the file explorer. 00 Inbox is always at the top (where new stuff arrives), 40 Archives is in the middle (where old stuff goes), and 90 Templates is at the bottom (configuration you rarely touch).

The key insight: PARA is a routing system

When a new note arrives in 00 Inbox, the first question isn’t “what folder does this go in?” – it’s “what kind of thing is this?” That answer determines the destination:

• Has a defined outcome and deadline? → 10 Projects
• Ongoing responsibility with no end date? → 20 Areas
• Reference material you’ll consult later? → 30 Resources
• Not useful? → 40 Archives (or delete)

This routing decision is the entire workflow. Once a note is in the right folder, the folder’s conventions take over – project notes get status tracking, meeting notes get linked to projects, resource notes get tagged for retrieval.

Folder-Note Dashboards: Every Folder Is a Live Surface

Here’s where it gets interesting. Each major folder has a folder note – a special markdown file with the same name as its folder – that acts as a live dashboard. When you click the folder in Obsidian’s sidebar, you see the dashboard instead of a file list.

This uses the Folder Notes plugin by LostPaul: a file at 00 Inbox/00 Inbox.md becomes the landing page for the 00 Inbox folder.

Example: The Inbox Dashboard

My Inbox folder note has three live views powered by Bases – Obsidian’s built-in query engine for note properties:

Obsidian syntax note: The query blocks below go inside fenced code blocks with base as the language identifier (triple backticks followed by base). That’s what tells Obsidian to render them as live Bases views instead of plain code.

Active Queue – shows every inbox capture that hasn’t been routed yet:

filters:
  and:
    - file.inFolder("00 Inbox")
    - tags.contains("capture")
    - or:
        - status == "triage"
        - status == "clarify"
        - status == "ready"
views:
  - type: table
    name: Active Inbox
    order:
      - status
      - modified
      - file.name

Ready to Route – captures that have a clear destination, ready for batch processing:

filters:
  and:
    - file.inFolder("00 Inbox")
    - status == "ready"

Stale Triage – captures I haven’t looked at yet, sorted oldest first (a “neglect detector”):

filters:
  and:
    - file.inFolder("00 Inbox")
    - status == "triage"

These aren’t static lists – they update in real time as I change note properties. When I set a capture’s status from triage to ready, it moves from the Stale Triage view to the Ready to Route view automatically. The dashboard is the workflow.

The Journal Dashboard

The Journal folder note works the same way – live views for recent daily notes, weekly reviews, and meetings. Here’s the Meetings view:

filters:
  and:
    - file.inFolder("50 Journal/Meetings")
    - tags.contains("meeting")
views:
  - type: table
    name: Meetings
    order:
      - date
      - file.name
      - summary
      - account
      - project
    sort:
      - property: date
        direction: DESC
    limit: 15

This gives me a rolling view of my last 15 meetings with their date, summary, linked account, and linked project – all pulled from frontmatter. The Journal dashboard also includes views for recent daily notes (last 14 days), weekly reviews (last 6 weeks), and one more:

Unlinked Meetings – a vault health indicator that shows meetings not yet connected to a project or account:

filters:
  and:
    - file.inFolder("50 Journal/Meetings")
    - tags.contains("meeting")
    - project == null
    - account == null

If a meeting shows up here, it usually means I took the note but didn’t finish processing it. It’s a gentle nudge to close the loop.

YAML Frontmatter: Turning Notes into Queryable Records

Every note in the vault starts with a YAML frontmatter block – structured metadata between --- fences at the top of the file. This is what makes notes queryable. Without it, a note is just text. With it, a note is a record in a database that happens to also contain prose.

Universal fields (every note gets these)

---
created: "2026-03-31T10:00"
modified: "2026-03-31T10:00"
tags:
  - project
summary: "SD-WAN migration for Gondor Networks - Phase 2 site deployments"
---

• created and modified are timestamps. created is set once when the note is made. modified is auto-updated by the Linter plugin every time you save.
• tags is an array that identifies the note type: project, meeting, person, resource, area, account, etc.
• summary is a ~150-character retrieval filter. Not an abstract – a line that lets you decide “do I need to open this?” without opening it. Think of it as the note’s search result snippet.

Note-type schemas

Each note type has additional fields that enable relationship queries:

Project Note:

tags: [project]
status: active        # active | planned | blocked | done
priority: p2          # p1 | p2 | p3 | p4
account: "[[Gondor Networks]]"
people:
  - "[[Aragorn Elessar]]"
  - "[[Samwise Gamgee]]"
areas:
  - "[[Network Security]]"

Meeting Note:

tags: [meeting]
date: "2026-03-28"
project: "[[SD-WAN Migration - Gondor]]"
account: "[[Gondor Networks]]"
people:
  - "[[Aragorn Elessar]]"
  - "[[Eowyn Rohirrim]]"
  - "[[Samwise Gamgee]]"

Person Note:

tags: [person]
org_type: external    # internal | external
role: "Network Architect"
account: "[[Gondor Networks]]"
email: "a.elessar@gondor-networks.example.com"
ext:
did:
cell:

Notice the wikilinks in the YAML fields. These aren’t just strings – Obsidian resolves them as links, which means you can query relationships: “show me all meetings where Aragorn was present” or “show me all projects linked to Gondor Networks.”

Why this matters

With structured frontmatter on every note, I can embed queries like this in a project note:

Show me all meetings linked to this project
  → filters: project == this

Show me all areas that include this project
  → filters: projects.contains(link(this.file.name))

Show me all people involved in this project
  → read from the `people` field

The this keyword is critical – it refers to the current note, so queries don’t break when you rename a note. This is one of those details you learn the hard way after renaming a project and watching all your dashboards go blank.

What Comes Next

So far we’ve built the storage layer: PARA folders for routing, folder-note dashboards for visibility, and YAML frontmatter for queryability. That’s a functional vault you can use today with nothing but Obsidian and a few plugins.

The rest of the series adds two more layers on top of this foundation:

1. The AI agent layer (Parts 3-4) – a CLAUDE.md file that teaches an AI agent your vault’s conventions, plus custom workflows for inbox processing, meeting transcripts, and daily reviews.
2. The search and integration layer (Parts 5-6) – semantic search across 5,500+ notes, the Obsidian CLI for programmatic access, and MCP connections to Slack, email, and project boards.

None of that requires training a model or building a custom app. It’s markdown files, a well-written instruction document, and an AI agent that can read and write files. We’ll build the full architecture diagram in Part 6 once you’ve seen each piece in context.

Getting Started: Your First 30 Minutes

If you want to follow along, here’s what to do right now:

1. Install Obsidian

Download from obsidian.md or brew install --cask obsidian. Create a new vault.

2. Create the PARA folders

Tip: Or have an AI agent do it for you.

00 Inbox/
10 Projects/
20 Areas/
30 Resources/
40 Archives/
50 Journal/
50 Journal/Meetings/
60 Accounts/
90 Templates/

3. Install the Folder Notes plugin

Go to Settings → Community Plugins → Browse → search “Folder Notes” → Install → Enable. Configure it to use {{folder_name}} as the note name and store notes inside the folder.

4. Create your first folder note

Create 00 Inbox/00 Inbox.md and paste this minimal dashboard:

---
tags:
  - inbox
---

# Inbox

## Status Flow
- `triage` -> `clarify` -> `ready` -> `routed`
- `dropped` is terminal.

5. Create your first inbox capture

Create any note in 00 Inbox/ with this frontmatter:

---
tags:
  - inbox
  - capture
status: triage
---

Write a quick thought in the body. You’ve just started the inbox workflow. In Part 4, we’ll build the full state machine with Bases views and an AI skill that processes captures automatically.

Next up: Part 3 - Teaching an AI Agent Your Note-Taking Rules – where we write the most important file in the entire system: CLAUDE.md.