Ask most vendors how to give your AI agent a memory and the answer is the same shape: adopt their memory layer, learn their schema, store your knowledge inside their service, and trust that the abstraction was worth the lock-in. We want to argue the opposite. The correct interface layer between a human and an agent is not a clever memory product. It is plain text. Markdown is boring, and boring wins. Boring means portable. It means diffable. It means yours. That single sentence is the whole thesis, and everything below is the architecture that earns it.
Figure 1 - The Three-Layer Memory Stack: A portable second brain has three replaceable layers. The Obsidian vault holds human-readable markdown. The Obsidian CLI gives an agent a structured query interface over that vault. Graphify adds an optional knowledge-graph layer for graph-aware Q&A. The Pi coding agent reads, writes, and navigates all three, and because every layer is plain text or an open command interface, each one can be swapped without touching the others.
The bet against the memory box
The pattern we keep seeing in agent-memory content is a vendor’s abstraction dressed up as a primitive. Mem0 markets itself as a universal memory layer for AI agents [1]. Letta, formerly MemGPT, ships a stateful-agent runtime with its own memory model [2]. Both are genuinely capable, and we want to be precise about what they are, because the lazy critique gets this wrong. Neither is a closed proprietary black box. Both ship open-source cores under the Apache-2.0 license and can be self-hosted [1][2]. The real tradeoff is not open versus proprietary. It is who owns the schema.
When you adopt one of these tools, you accept an opinionated memory abstraction with its own structure, its own retrieval semantics, and a managed hosted tier that the abstraction gently steers you toward. Your knowledge lives inside a shape someone else designed. That is a reasonable trade for some teams. It is the wrong trade for a personal second brain, because a personal knowledge layer has to outlive the tool that reads it. If the service changes its schema, deprecates a tier, or disappears, a markdown vault does not care. You still have your notes.
KEY INSIGHT: The question to ask any agent-memory tool is not “is it open source?” It is “who owns the schema, and does your knowledge survive the tool?” Plain markdown answers both: you own the schema, and the knowledge outlives any single reader.
Figure 2 - Managed Abstraction Versus Portable Text: On one side, a managed memory layer holds your knowledge inside a schema and a hosted service you do not control. On the other, a folder of markdown files stays diffable, git-committable, and readable by any tool. The managed layer is not evil, and it is not closed. It simply owns the shape of your memory, and a portable vault does not give that ownership away.
Karpathy’s three-layer cake
The architecture is not new. Andrej Karpathy sketched the core idea in a short public gist describing an LLM wiki as a simple layered system: take notes, keep a place to read them, and run question-and-answer over them on an ongoing basis [3]. Three layers, nothing exotic. The value is in refusing to over-engineer it. A knowledge layer is notes you write, a place an agent can read them, and a way to ask questions across the whole set.
The stack we are describing maps onto those three layers exactly. The Obsidian vault is where notes get taken, by a human and by an agent. The Obsidian CLI is the place to read them, giving an agent structured access instead of blind file scanning. Graphify is the ongoing Q&A layer, turning the vault into a graph an agent can traverse. The demo that pulled these three pieces together into a working agent-memory loop was a walkthrough on the DevOps Toolbox channel, and it is the concrete source we lean on for the integration below [4].
Figure 3 - The Abstract Pattern and Its Concrete Parts: Karpathy’s three-layer wiki idea is a mental model, not a product. The left column is the pattern: take notes, have a place to read them, run ongoing Q&A. The right column is one concrete implementation of each layer. Any of the three parts can be replaced as long as the layer it fills stays intact.
Layer one: the vault as memory substrate
The base layer is an ordinary Obsidian vault, which is to say a folder of markdown files. That is the entire technology, and its plainness is the point. Markdown is portable across every editor. It is diffable, so every change an agent makes is a reviewable git diff rather than an opaque write to a datastore. It carries frontmatter for structured metadata and wikilinks for a navigable graph, both of which an agent can traverse. If Obsidian itself vanished tomorrow, the vault would open in any text editor and lose nothing.
This is what makes the vault the right memory substrate for an agent rather than a vector store full of embeddings no human will ever read. When an agent writes a note into the vault, you can open it, read exactly what it recorded, correct it, and commit the correction. The memory is auditable by construction. A JSON blob in a hosted memory service is not.
Figure 4 - The Vault as Auditable Memory: Each note is a plain markdown file with frontmatter metadata and wikilinks to related notes. The links form a graph an agent can walk. The git boundary around the folder means every agent write is a diff a human can review, approve, or revert. Nothing about the memory is hidden inside a service.
Layer two: the CLI as the agent’s query interface
A vault of markdown is only half the story, because an agent still needs a way to query it that is better than raw text search. This is where the second layer earns its place, and it is worth stating plainly: the Obsidian CLI is a genuine first-party feature. It shipped in Obsidian 1.12, which reached general availability on February 27, 2026, and it exposes over 100 commands covering nearly everything you can do inside the app [5][6]. There is an official help page for it [6]. This is not a community hack bolted onto the side.
The reason an agent wants the CLI instead of grep is structure. A plain text search hands the agent raw line matches with no ranking and no awareness of the vault’s shape. The CLI understands note tags, vault path structure, frontmatter fields, bidirectional links, and task status. The demo framed the difference sharply: instead of returning 200 lines that happen to match a term, the CLI returns ranked note titles, so the agent can “pick notes, not lines” [4]. An agent reasoning over whole notes and their link graph is working with far better context than one sifting line fragments.
KEY INSIGHT: Give an agent a structured query interface over its memory and it stops guessing from line fragments and starts reasoning over whole notes and their links. The retrieval interface matters as much as the knowledge it retrieves.
Figure 5 - Notes, Not Lines: Raw text search returns unranked line matches with no structure. The Obsidian CLI returns ranked note titles and understands tags, frontmatter, and links. The agent that queries through the CLI reasons over notes as units, which is a cleaner and smaller context than a wall of matching lines.
Layer three: Graphify for graph-aware Q&A
The third layer is optional, and it is where the vault becomes a graph an agent can traverse for question-answering. That layer is Graphify, an open-source knowledge-graph tool by Safi Shamsi, released under the MIT license and built on tree-sitter and NetworkX [7]. A naming note matters here, because the tool is easy to misspell and the wrong spelling points at a package that does not exist. The project is Graphify. Its PyPI package is graphifyy with a double y, and its command-line tool is graphify. Installing it and wiring it into an agent looks like this:
# Install the Graphify CLI (double-y on the PyPI package name)uv tool install graphifyy
# Generate the agent skill and instructions for the Pi platformgraphify install --platform pi
# Build the knowledge graph from the current vaultgraphify buildGraphify scans the vault, builds a graph of concepts and their connections, and writes its output into a graphify-out/ directory: a browsable graph.html, a GRAPH_REPORT.md summary, and a machine-readable graph.json [7]. An agent can then ask graph-shaped questions, pulling a connected neighborhood of notes around a topic instead of a flat keyword hit list. Graphify originated as a tool for code repositories, and its authors have circulated headline token-reduction figures for that code-repo case. We are deliberately not repeating a specific multiplier here, because no vendor-published measurement exists for a knowledge vault of notes, and the person who demoed it on a vault walked the number back on camera as not representative [4]. The graph is a real improvement for traversal-heavy Q&A. Treat any dramatic token-savings claim as unproven until you benchmark it on your own vault.
Figure 6 - The Optional Graph Layer: Graphify reads the vault and builds a graph of concepts and their edges, emitting a visual graph.html, a GRAPH_REPORT.md summary, and a machine-readable graph.json. An agent queries the graph to pull a connected cluster of notes around a topic. This layer is optional; the vault and CLI stand on their own without it.
Pi as the agent that drives the stack
The agent tying these layers together in the demo is Pi, an open-source, bring-your-own-key command-line coding agent by Mario Zechner, developed under the earendil-works organization [4][9]. Pi is a good fit for this pattern precisely because it is composable rather than opinionated: it reads and writes files, runs commands, and takes on extensions that wrap external tools as typed operations. Pointing it at an Obsidian vault through the CLI turns the vault into the agent’s working memory.
Pi picks up Obsidian support through a community extension. This is a spot where precision matters, because there is no single official package here. The Pi package catalog lists a cluster of community Obsidian extensions under overlapping names, and the one that matches the demo wraps the Obsidian CLI as typed tools, best identified as @capyup/pi-obsidian [8]. It is a community Pi extension, not a first-party Obsidian or Pi product. Describe it that way and you will not send anyone chasing an official package that does not exist.
The most talked-about moment in the demo is worth reporting carefully, because it is a single anecdote rather than a documented product behavior. In that demo, after the extension was installed, Pi was asked to compare the extension’s wrapper against its own direct handling of the Obsidian CLI. It concluded that its own approach was better, kept that, and removed the extension it had just been given [4]. Read as a demo moment, it is a striking illustration of an agent curating its own tools. We are not presenting it as a guaranteed or repeatable Pi feature, because it is not documented as one. It happened once, on camera, and that is exactly how much weight it should carry.
Figure 7 - The Agent in the Loop: Pi reads and writes the vault through the Obsidian CLI, reaching it via a community extension that exposes the CLI as typed tools. The inset shows the demo’s self-curation moment, where the agent judged its own handling of the CLI superior to the extension and removed the extension. Reported as a one-off demo anecdote, not a documented behavior.
The open standard underneath the philosophy
The portable-markdown idea is no longer just a personal preference. There is now a genuine open standard aiming at the same target. Google’s Open Knowledge Format, published in mid-2026, standardizes a knowledge layer as a folder of markdown files with YAML frontmatter [10]. The format defines a small set of fields, including type, title, description, resource, tags, and timestamp, with type as the anchor and the rest optional [10]. The spec itself lives in a public repository for anyone who wants to implement against it [11].
Two things about the format sharpen this article’s argument rather than complicate it. First, the resource field is designed to point a concept file at its live source of truth, a table or an API, rather than copying the data in, which keeps each markdown file thin and current instead of a stale snapshot [10]. That is the same instinct behind a good vault: reference live data, do not hoard copies of it. Second, and this is the honest caveat we will not skip, a format like this standardizes the container, not the knowledge. The type field is free text with no central registry, and cross-concept links are untyped, so two spec-compliant vaults can still fail to merge cleanly when one says “customer” and the other says “client.” A framing we find useful: a skill tells an agent how to do something, while a knowledge format tells an agent what you know. The format gives you a shared box. It does not give you a shared vocabulary.
KEY INSIGHT: An open format standardizes the container, not the knowledge inside it. Two compliant vaults can still disagree on what a “customer” is. Portability gets you the box for free; a consistent schema is the work you still have to do.
Figure 8 - A Standard for the Container: The Open Knowledge Format defines a small frontmatter schema, with type as the required anchor and a resource field that points at a live source of truth instead of copying data in. The inset shows the limit: because type is untyped free text with no registry, two compliant vaults can still fail to merge when their vocabularies disagree.
Two ends of the spectrum
A hand-curated Obsidian vault sits at one end of a spectrum, and it helps to see the other end. LangChain’s OpenWiki is the mirror image: a documentation agent that maintains a codebase’s knowledge automatically, driven by git diffs and filing its updates as reviewed pull requests through a scheduled action [12]. One end is a human-curated second brain that a person and an agent write together. The other is an auto-maintained repository wiki that regenerates itself from code changes. Both are markdown. Both are portable. They differ only in who does the curating. We mention OpenWiki as the contrast rather than the recommendation, and we are describing the pattern from its project rather than quoting exact commands, which belong to its own documentation.
Where markdown-native memory stops working
The strongest version of this argument names its own boundary, and there is a clean one. In a talk on scaling knowledge systems, Cole Medin drew a hard line at the point where a personal agent becomes a product shipped to other people [13]. Personal and second-brain agents should be markdown-driven, single-user, and cheap. Production agents that other people have to trust need to be database-backed, access-controlled, and cost-optimized. That is not a contradiction of everything above. It is the edge of it. Markdown-native memory is the right call when you are the only one who has to trust it, and the wrong call the moment someone else does.
Holding both halves is what keeps the thesis honest. We are not claiming plain text scales to a multi-tenant production system where access control and concurrency matter. We are claiming it is the correct layer for a human and their personal agent, which is a large and underserved space. Knowing where the approach ends is what lets you recommend it confidently inside its range.
Figure 9 - The Threshold You Should Not Cross Blind: On the personal side of the line, markdown-native memory is single-user, cheap, and portable, and it is the right choice. On the production side, where other people must trust the system, memory belongs in a database with access controls and cost optimization. The thesis holds on the left of the line and yields on the right.
The pattern, running in production here
We are not describing this from the outside. The knowledge base that grounds the articles on this site is a hand-rolled implementation of the same philosophy. It lives in a docs/kb/ folder as plain markdown: atomic concepts as individual files, cross-cutting connections threaded through wikilinks, and a navigable index that both Obsidian and our Claude Code agents read directly. Every entry is a diff in version control. When a research agent writes a new concept, the change is reviewable line by line before it lands.
The one place we go beyond a bare format is exactly where the Open Knowledge Format admits its limit. Our knowledge base runs a lint script against a fixed schema, so the merge problem, where one note says “customer” and another says “client,” gets caught mechanically instead of rotting silently. That is the small amount of extra structure a shared standard cannot hand you for free, and it is the difference between a folder of markdown that drifts and a knowledge layer an agent can rely on. The portability is free. The consistency is the engineering we chose to add on top of it.
KEY INSIGHT: Portability is what a plain-markdown knowledge layer gives you out of the box. A consistent, lint-enforced schema is the deliberate work that turns a portable folder into a knowledge layer an agent can trust. Choose the boring format, then invest in the vocabulary.
Figure 10 - A Hand-Rolled Version of the Same Idea: Concepts live as markdown files, connections as wikilinks, and both a human editor and a coding agent read the same folder. A lint gate enforces a fixed schema on every write, catching the vocabulary-drift problem that an open format leaves to the implementer. This is the three-layer philosophy built by hand and running in production.
Conclusion
The temptation with agent memory is to buy the box. A vendor’s memory layer is a real product with real capabilities, and for a multi-user production system it may be the right answer. For the human-and-personal-agent layer, the boring choice is the correct one. A folder of markdown files, queried through a first-party CLI and optionally lifted into a graph, gives an agent a memory that is portable, diffable, auditable, and yours. Pi is one agent that drives that stack today, and the specific tools will change. The philosophy underneath them is the durable part.
The practical takeaway is a sequence, not a purchase. Start with a plain markdown vault. Add a structured query interface so your agent reasons over notes instead of lines. Add a graph layer only when traversal-heavy Q&A earns it. Then, if the vault is going to be knowledge your agents depend on, spend the extra effort a bare standard will not spend for you: pin a schema and enforce it. Portability comes free with the format. Consistency is the work. Do both and you have an agent that never forgets, because you gave it a place to remember that no vendor can take away.
References
[1] Mem0, “mem0ai/mem0: universal memory layer for AI Agents,” GitHub. https://github.com/mem0ai/mem0
[2] Letta, “Letta (formerly MemGPT).” https://www.letta.com
[3] A. Karpathy, “llm-wiki,” GitHub Gist, 2026. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
[4] DevOps Toolbox, “I Gave Pi Access to Obsidian And I’m Not Looking Back,” YouTube, May 8, 2026. https://www.youtube.com/watch?v=JnQcPzjC6Vo
[5] Obsidian, “Obsidian 1.12.4 Desktop changelog,” Obsidian, February 27, 2026. https://obsidian.md/changelog/2026-02-27-desktop-v1.12.4/
[6] Obsidian, “Command line interface,” Obsidian Help. https://obsidian.md/help/cli
[7] S. Shamsi, “safishamsi/graphify: knowledge graph for AI coding assistants,” GitHub. https://github.com/safishamsi/graphify
[8] capyup, “capyup/pi-obsidian: a Pi extension that wraps the Obsidian CLI as typed tools,” GitHub. https://github.com/capyup/pi-obsidian
[9] M. Zechner, “earendil-works/pi,” GitHub. https://github.com/earendil-works/pi
[10] Google Cloud, “How the Open Knowledge Format can improve data sharing,” Google Cloud Blog, June 12, 2026. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
[11] Google Cloud Platform, “knowledge-catalog: Open Knowledge Format spec,” GitHub. https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf
[12] LangChain, “langchain-ai/openwiki: a CLI that writes and maintains agent documentation for your codebase,” GitHub. https://github.com/langchain-ai/openwiki
[13] C. Medin, “I Love the Karpathy LLM Wiki but it Doesn’t Scale. Here’s What Does.,” YouTube, July 2026. https://www.youtube.com/watch?v=R-5_2nsF_ZM
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.