โ† Guides
Knowledge Architecture

Three Layers of Personal Knowledge

Google Drive for source documents, Obsidian for extracted knowledge, and a local workspace for operations. What goes where, why they mirror each other, and how AI agents read all three.

March 18, 2026 ยท Drive + Obsidian + macOS

The Problem with One System

Most people start with one tool. Everything goes into Obsidian, or everything goes into Google Drive, or everything lives in a folder on your desktop. It works until it does not.

PDFs, contracts, and tax documents are not the same thing as the knowledge you extract from them. And neither of those are the scripts, configs, and agent workspaces that operate on the knowledge. When they all live together, you end up with a vault full of binary files Obsidian cannot index, a Drive full of markdown nobody reads, and a workspace cluttered with documents that should be somewhere searchable.

The solution is not picking the right tool. It is defining what each tool is for, and then being disciplined about the boundary.

Google Drive
Google Drive
Source Documents
PDFs, contracts, tax forms, screenshots, spreadsheets. The original files you received or downloaded. Accessible from any device.
Obsidian
Obsidian
Extracted Knowledge
Markdown files with the information you extracted, analyzed, and organized. Wikilinks, tags, frontmatter. Searchable and queryable.
Terminal
Workspace
Operational
Scripts, configs, agent files, templates, build outputs. The machinery that operates on the knowledge. Lives on your local filesystem.

What Goes Where

The way I think about it: if I received it or downloaded it, it goes in Drive. If I wrote it or extracted it from something, it goes in Obsidian. If it runs or builds something, it goes in the workspace.

File TypeLayerWhy
Tax return PDFDriveSource document; Obsidian cannot render PDFs usefully
Employment contractDriveLegal original; needs to be accessible from any device
Property appraisalDriveThird-party document with images and formatting
Spreadsheet (financial model)DriveNeeds Google Sheets or Excel; markdown cannot replace it
Tax analysis (your notes)ObsidianKnowledge you extracted; needs links, tags, frontmatter
Immigration timelineObsidianYour synthesis; references source docs in Drive
Research on a topicObsidianAI-generated or manual; needs freshness metadata
Daily journal entryObsidianPersonal notes; benefits from Calendar plugin and Dataview
Deploy scriptWorkspaceExecutable; does not belong in a knowledge base
Agent configWorkspaceOperational; changes frequently, versioned differently
API keys / secretsWorkspaceSecurity-sensitive; never in Drive or a synced vault
Contacts databaseBothSource in workspace; knowledge summary in Obsidian

The "both" cases are rare but real. A contacts database might live as a JSON or CSV in the workspace (for scripts to read), with a human-readable summary in Obsidian (for you to browse). The workspace version is the source of truth; the Obsidian version is a view into it.

Mirror the Folder Structure

If your Drive has a folder called 00_Spain and your vault has a folder called 00_Spain, you never have to think about where something is. The numbering system keeps both sorted identically. When you are looking at a tax analysis in Obsidian and need the source PDF, you know it is in the same-numbered folder in Drive.

Google Drive
๐Ÿ“ 00_Spain/
  contracts/
  tax-forms/
  property/
๐Ÿ“ 00_USA/
  tax-returns/
  immigration/
๐Ÿ“ 01_Projects/
๐Ÿ“ 02_Career/
๐Ÿ“ 03_Personal/
โ†” โ†” โ†”
Obsidian Vault
๐Ÿ“ 00_Spain/
  Beckham Law/
  Property/
  Relocation/
๐Ÿ“ 00_USA/
  Taxes/
  Immigration/
๐Ÿ“ 01_Projects/
๐Ÿ“ 02_Career/
๐Ÿ“ 03_Personal/

The subfolders differ because they serve different purposes. Drive subfolders organize by file type (contracts, tax-forms, PDFs). Obsidian subfolders organize by topic (Beckham Law, Relocation, Immigration). But the top-level numbers match, so context-switching between tools is instant.

The Flow Between Layers

Information moves in one direction: from source to knowledge to operations. A tax document arrives as a PDF in Drive. You (or your AI) read it and extract the relevant facts into an Obsidian note. A script in your workspace might then read that Obsidian note to generate a report or update a dashboard.

Drive
PDF lands in Drive
Tax return, contract, appraisal
โ†’
Obsidian
Knowledge extracted
Markdown with tags, links, metadata
โ†’
Terminal
Scripts operate on it
Reports, dashboards, automation

In practice, information moves in one direction. I've never had a reason for scripts to write PDFs back to Drive, or for knowledge notes to become operational configs. If you find yourself copying a markdown file from Obsidian into your workspace so a script can read it, the script should probably just read the vault directly.

How AI Agents Read All Three

If you use an AI assistant (Claude, ChatGPT, a local model, anything), the three-layer structure determines how it accesses information.

01
Obsidian is the primary read layer
The vault is plain markdown on disk. Any AI that can read files can read your vault. Tools like qmd index the vault and let agents search it semantically. This is where 90% of agent queries should go.
02
Drive is the reference layer
When the agent needs the actual source document (a PDF, a spreadsheet, an image), it reads from Drive. Google Drive mounts as a local folder on macOS; the agent treats it like any other directory. The key is that agents read Drive for verification, not for everyday knowledge.
03
Workspace is the write layer
Agents write scripts, generate reports, update configs, and manage their own memory in the workspace. This is also where agent-specific files live: AGENTS.md, MEMORY.md, task plans, session logs. The workspace is the agent's home; the vault is the library it visits.
04
Agents write to the vault through a defined process
When an agent produces new knowledge (research results, analysis, extracted facts), it writes directly to the vault with proper frontmatter. The file gets tagged, timestamped, and classified on creation. The agent does not dump raw output; it follows the same metadata schema as every other file in the vault.

The separation has a security benefit too. My AI agent can read the vault and workspace, but it doesn't have access to Drive (which has sensitive legal documents and financial records). That boundary exists because the layers are separate, not because I configured a complex permission system.

Setting This Up

1. Create the Drive structure

Create a shared folder in Google Drive with numbered top-level folders matching your domains. I use a folder called 00_AIProjects as the root, with project-specific subfolders inside it. The numbering does not need to be identical to your vault, but the domain names should match.

2. Create the Obsidian vault

Mirror the top-level folder numbers from Drive. Add the vault-specific folders that Drive does not need: Archive, System, Research, Journal. See the Knowledge Vault guide for the full vault setup including plugins, templates, and freshness metadata.

3. Set up the workspace

Your workspace is wherever your AI assistant or scripts live. Keep it separate from the vault and Drive. It should contain operational files only: scripts, configs, agent memory, build outputs, secrets. Nothing that a human needs to browse or search belongs here; that goes in the vault.

Structure
# Three locations on your machine Google Drive ~/Library/CloudStorage/GoogleDrive-.../My Drive/ PDFs, contracts, spreadsheets, images, source docs Obsidian Vault ~/Documents/Obsidian/My-Vault/ Markdown knowledge, tags, links, frontmatter, journal Workspace ~/.my-workspace/ Scripts, configs, agent files, secrets, build outputs

4. Define the boundaries

Write these rules down somewhere your AI can read them (AGENTS.md, a workspace config, or the vault itself). The boundaries are:

Drive = source documents. Files you received, downloaded, or were given. PDFs, contracts, spreadsheets, photos. Binary files and anything that needs its original formatting. Shared and accessible from any device.

Vault = extracted knowledge. Your notes, analyses, research, journal entries. Always markdown. Always with frontmatter. Always searchable. The vault is the single source of truth for "what do I know about X."

Workspace = operations. Scripts, configs, agent memory, secrets, templates, build artifacts. Things that do work, not things that store knowledge. If you would not want it showing up in an Obsidian search, it belongs here.

Why This Works

Three properties make this system durable. First, each layer uses the tool best suited to its content: Drive handles binary files and sharing, Obsidian handles linked markdown and queries, the filesystem handles executable code. Second, the mirrored numbering means you never lose context when switching tools. Third, the clear boundaries mean new files have an obvious home; you do not have to decide where something goes because the type of file determines the answer.

The system also degrades gracefully. If you stop using Obsidian, the knowledge is still plain markdown on disk. If you stop using Drive, the source documents are still local files. If you stop using AI agents, the folder structure and metadata still work for a human browsing manually. No single tool is a dependency.

For the full Obsidian setup (plugins, templates, freshness metadata, canonical promotion, Dataview dashboard), see the Knowledge Vault guide. For how AI agents maintain session memory across restarts, see How My AI Remembers.

Implementation Guide

Three Layers Setup Guide

The full three-layer architecture in a single markdown file. Folder structure, what-goes-where rules, agent access patterns, and boundary definitions. Hand it to your AI or follow it yourself.

Download .md