PKM Wiki

Vault-as-Platform

5 min read

Vault-as-Platform is the emergent understanding, converging across the 2025-2026 PKM practitioner community, that a mature Obsidian-style vault has quietly become a complete personal application platform — interface, storage, sync, distribution, agent substrate — rather than just a note-taking tool. The shift is architectural, not cosmetic: the same vault that stores notes also runs plugins (interface), holds structured data (storage), syncs across devices (sync), ships plugins to others (distribution), and serves as context for AI agents (agent substrate).

The framing synthesizes four independent practitioner arguments, each approaching the same observation from a different angle.

The Four Convergent Arguments

1. Matuschak (2026): Composable architectures escape app tyranny

The composability thesis says that systems built from plugins (not with plugins bolted on) give users the same primitives the developers used. Obsidian is cited as the PKM-space positive example: "plugins use exactly the same primitives that the Obsidian developers used to create their product." This is what makes the vault more than an app — it is a substrate on which arbitrary user-built capabilities can run.

2. TfTHacker (2026): Obsidian is secretly an app platform

The operational proof: any personal application needs interface + storage + sync + distribution. Obsidian provides all four: Electron gives HTML/CSS/JS; vault gives files-as-database; Sync/iCloud carry data across devices; BRAT and the Community Plugin directory are distribution channels. A working plugin (Spanish-number flashcards with cram mode and audio recognition) built in 1.5 days via vibe-coding demonstrates the claim.

3. Koylan (2026): The file system is the new database

The Personal OS thesis: an ~80-file Git repository of markdown/YAML/JSONL is a sufficient agent substrate for personal context. No vector store, no database, no API. LLMs read the filesystem natively. The vault becomes an operating-system-level context substrate rather than just a content store.

4. YB (2026): Vault + agents as partner

The agentic constitution + Knowledge Work PRs + subroutines pattern. Vault holds the standing context (who you are, how you work); agents run against it to propose changes (skills, drafts, synthesis); human reviews and merges. The vault is simultaneously the workplace and the workbench.

What These Arguments Share

All four practitioner positions converge on five properties:

  1. User-owned substrate. Files on disk, under the user's control, not rented from a vendor
  2. Plain-text primitives. Markdown + YAML + JSONL — human- and machine-readable, future-proof
  3. Composable extension. Plugins/skills/subroutines build on the same primitives as the core
  4. Agent-readable by default. LLMs can read the substrate without special tooling
  5. Multi-function. Same artifact serves as notes, context, workflow, app, distribution target

What Becomes Possible

When all five properties hold, several capabilities become possible that are not possible with any single alternative:

  • Personal app prototyping (TfTHacker) — build custom tools via vibe-coding without servers or deployment
  • Agent-as-partner operation (YB) — agents read vault, propose changes, user reviews and merges
  • Context compounding for AI (Koylan) — accumulated personal context that any LLM can use
  • Escape from research purgatory (Matuschak) — novel interface ideas can land as plugins rather than as entire competing tools
  • Cross-tool portability — the substrate travels between cores (Obsidian, Logseq, Foam) because the primitives are standardized

What It Requires

For vault-as-platform to work, several things have to be in place — some are solved, some are not:

Requirement Status
Composable extension API Solved (Obsidian)
Plain-text primitives Solved (markdown, YAML, JSONL)
Local-first sync Solved (Obsidian Sync, Syncthing, iCloud)
Plugin distribution Partially solved (Community Plugins, BRAT)
Agent-readable structure Emerging (Personal OS patterns)
Episodic memory / judgment capture Emerging (Koylan's model)
Knowledge transfer pipeline Unsolved (Koylan's open problem)
Standardized cross-tool plugin shape Unsolved
Agent-reliable progressive disclosure Partial (Vercel's 56% skill-invocation failure)

Implications for PKM Tool Choice

Vault-as-platform reframes the tool-selection question. Instead of "which tool has the best features," ask:

  • Is the substrate composable? Can plugins use the same primitives the core uses? (Obsidian yes; Notion no)
  • Is the substrate plain-text? Can you read it without the vendor's app? (Obsidian yes; Evernote partial; Notion no)
  • Is the distribution open? Can users install community plugins? (Obsidian yes; most SaaS no)
  • Is the substrate agent-readable? Can an LLM ingest it without special APIs? (markdown yes; proprietary formats no)

Tools failing multiple of these criteria cannot become platforms regardless of feature quality. Tools passing all can become platforms regardless of feature gaps — the community fills them.

Risks and Caveats

  • Platform lock-in shifts, doesn't disappear. A composable substrate still has a core (Obsidian). If that core degrades, the platform degrades with it, though less severely than rented SaaS because data stays portable.
  • Quality variance. Community plugins have highly variable quality; a vault-as-platform is only as good as its curation.
  • Cognitive load. Running a Personal OS demands structure-awareness most users don't want. Vault-as-platform is power-user territory by default.
  • Security surface. Open plugin APIs are attack surfaces. Plugin security is under-theorized in most PKM ecosystems.
  • Not for all use cases. Teams, regulated industries, and non-technical users may be better served by simpler tools without the platform surface.

Key Points

  • Vault-as-Platform = mature Obsidian-style vault as a complete personal application platform
  • Synthesis of four convergent practitioner arguments (Matuschak, TfTHacker, Koylan, YB)
  • Five shared properties: user-owned, plain-text, composable, agent-readable, multi-function
  • Enables: personal app prototyping, agent-as-partner, context compounding, research-purgatory escape
  • Requires: composable API, plain-text, local-first sync, plugin distribution, agent readability
  • Reframes tool selection around platform properties, not features
  • Not universal: power-user territory, quality variance, security surface

Open Questions

  • Will the vault-as-platform framing remain Obsidian-centric, or will cross-tool standards emerge (markdown + facet API + standardized plugin shape)?
  • What does vault-as-platform look like for teams or families, vs. individuals?
  • Is there a point at which a single vendor's vault-as-platform becomes a monopoly risk and the community should fork?

References

  • Andy Matuschak, "Apps and Programming: Two Accidental Tyrannies" (2026)
  • TfTHacker, "Obsidian Is Secretly an App Platform" (2026)
  • Muratcan Koylan, "The File System Is the New Database" (2026)
  • YB, Engineering Agency corpus (2026)