TL;DR (aka future GT, read this first next time): Months ago I built a second brain out of markdown files and told an AI agent to maintain it. People asked why not Notion, why not a vector database, why not something that isn't just a folder of text files. This week, Karpathy published LLM Wiki (linked markdown files an agent reads and rewrites), Google released OKF (enterprise knowledge as plain markdown), and Garry Tan open-sourced gstack (23 markdown roles that summon 10 coding agents). Three independent bets, same quarter, same answer. The moat is shifting from the model to the markdown your team accumulates. I didn't predict this. I stumbled into it by being too lazy to learn a new tool. Here's what I was building, why it matters, and what the industry just validated.
The setup: I was lazy, not prescient
Six months ago I had a problem that every knowledge worker eventually hits: my notes were scattered across Notion, Google Docs, Slack DMs, and my own head. I couldn't find anything I'd learned. Every project restart meant rediscovering decisions I'd already made.
The obvious solutions: Notion (too slow), Obsidian (too manual), a vector database (I am not building infrastructure for a personal knowledge base at 11 PM).
So I did the laziest thing possible. I made a folder with markdown files.
01-sources/— articles, repos, raw material02-concepts/— extracted reusable ideas03-learnings/— what I actually learned from building04-writing-angles/— content hooks derived from the above05-outputs/— drafts, posts, presentations06-style/— my voice, what performs
Then I told an AI agent to maintain it. The agent reads my Claude Code sessions, extracts learnings, generates writing angles, and cross-references everything with related: fields in yaml frontmatter. I don't organize the brain. The agent does.
It has 14 source files, 12 concepts, 20+ writing angles, and growing. Every file is plain markdown in a git repo. No database. No API. No proprietary format.
I assumed this was a hack. A stopgap until I got around to building something "proper."
Turns out it was the architecture.
The convergence: three bets, same quarter, same answer
In the past few months, three of the smartest people in AI shipped things that look suspiciously like my lazy folder of markdown files.
Andrej Karpathy — LLM Wiki (April 2026)
A GitHub gist describing an idea, not a product: an AI agent keeps what it knows as linked markdown files it can read and rewrite. A language model doesn't get bored maintaining cross-references. It can touch 15 files in a single pass and never complains about documentation drift.
Google — Open Knowledge Format (May 2026)
A published standard, labeled v0.1. OKF packages organizational knowledge — metrics, tables, runbooks — as plain markdown. Any agent can read it without a proprietary account. The target use is enterprise context for BigQuery agents, but the implications are broader: when Google's AI division ships a spec that says "your organizational knowledge should live in .md files," the format war is over.
Garry Tan (YC President) — gstack (June 2026)
MIT-licensed Claude Code setup. 66,000+ GitHub stars within weeks. Twenty-three specialist roles, each one a markdown file. No runtime. No code. Just prose that runs across 10 different coding agents. The goal: summon an engineering team from a terminal. The substrate: markdown.
Three independent bets. Three different problems (agent memory, enterprise context, agent behavior). One answer: markdown files in git.
Why markdown won (it isn't the features)
Markdown didn't win because it's the best format. It won because it requires zero switching cost.
catthe file.git clonethe repo. Any tool parses it.- Already present in millions of repos as
CLAUDE.mdandAGENTS.md— the initial files every coding agent loads. - LLMs are trained on it natively. No parsing layer, no API, no schema migration.
- Human-readable and machine-writable simultaneously. Your agent edits it. You review the diff.
This is the Git and JSON playbook replaying. Git didn't win version control because it was the best DVCS. JSON didn't win data interchange because the spec was elegant. They won because you could start using them without changing anything else.
Markdown for agent memory is the same pattern. The formats that survive are the ones that don't ask you to switch.
What the GTBrain actually looks like in production
My setup isn't just a folder of notes. It's a pipeline:
- I have a Claude Code session building something (dashboard frontend, scraper pipeline, course outline).
- The agent reads the session transcript and extracts what I learned.
- It writes that into
03-learnings/as a markdown file with yaml frontmatter andrelated:links. - From the learnings, it generates writing angles — specific hooks, audiences, and story beats — into
04-writing-angles/. - A weekly cron job picks an undrafted angle and produces a LinkedIn or Medium draft in my voice.
- When I publish and rewrite the draft, the delta (what I changed vs what the AI wrote) gets fed back into
06-style/to train the next draft.
The agent runs this loop autonomously. I don't write the content. I edit it.
And here's the key architectural detail: every file in this system is markdown. When I switch from Claude to DeepSeek to GPT — and I do, depending on the task — the knowledge base doesn't change. The model reads the same files. The only thing that changes is the intelligence doing the reading.
That's the moat.
The moat shifted. Nobody announced it.
For two years the AI industry believed: own the best model → control the developer. That assumption is breaking.
Switch Claude for Gemini, switch GPT for Codex — gstack still works because the documentation didn't change. The 23 markdown roles don't care which model is interpreting them. The lock-in isn't in the model API. It's in the accumulated context files your team owns.
This flips the competitive landscape. The model vendor's advantage erodes every time a new frontier model launches (and they're launching monthly now). The team that accumulates the richest, most structured context files wins — because those files are portable, and portability is the only defense against platform risk.
I didn't plan this. I just noticed it was working, and then the entire industry started shipping products that validated the architecture.
The risk: durability, not adoption
MSV's article flags the real risk: durability. OKF is a 0.1 draft with a reference implementation, not a full ecosystem. If nobody builds consumers for it, it's just a good idea Google released on a slow Friday. Declaring standards is easy. Making them reliable is hard.
My approach sidesteps this because it doesn't depend on a standard. It depends on a convention: yaml frontmatter, related: fields, a known folder structure, state: tracking. No consortium needed. No spec to ratify. Just git-tracked markdown that any LLM can read, and a few scripts that parse the frontmatter.
The file format isn't the innovation. The accumulated corpus is.
What this means if you're building on LLMs
If you're building anything that uses AI agents — coding tools, content systems, internal workflows — the most valuable asset you're creating isn't your prompt library. It's the markdown files your agents read and write.
Your CLAUDE.md isn't a disposable prompt. It's the entry point into a growing knowledge corpus that compounds with every session.
Your architecture decisions, your debugging war stories, your "never do this again" notes — those are your competitive advantage. Not because they're secret. Because they're structured, searchable, and agent-readable in a format that will outlast your current model provider.
The teams that treat agent context as an accumulating asset will run laps around the teams that treat it as a disposable prompt. The difference compounds daily.
What's the format you're betting your agent memory on — and can you switch models without losing it?