The Acceleration Problem
I started using Obsidian in 2022. Before that I had used Evernote, OneNote, and a long list of tools that promised to be the place where I kept everything — bookmarks, notes, todos, the running accumulation of a knowledge worker's life. One by one they got acquired, pivoted, or raised their subscription price past the point where the data felt worth the rent.
I had been through enough of those cycles to recognize what the real cost was. Not the money. The migration.
I have led data engineering and migration teams for over twenty years. I know what it costs to move things. When Obsidian made a single promise — your data stays yours, in plain markdown files, on your own machine — I recognized the architecture before I recognized the product. Portability as a design principle. Not a feature. A commitment.
"Portability as a design principle. Not a feature. A commitment."
The pace changed first
The tools didn't come first. The acceleration did.
The world has been moving faster for a long time, but something shifted in the last decade that is qualitatively different from prior cycles. Ideas spread globally in hours. Disciplines that were once siloed now cross-pollinate faster than any curriculum can track. The technology itself — not just what it does but what it means — is being developed and adopted at a rate that outpaces every organizational learning cycle we have ever built.
For the knowledge worker, this created a specific kind of pressure. Not information overload in the old sense. Something more structural. The rate at which you need to learn, synthesize, and apply has become faster than any enterprise system was designed to support.
I discovered this the way I discover most things: by deciding I needed to learn something serious and then thinking hard about how to operate at scale and speed. I had been taking graduate courses for over a decade, driven by what I can only describe as endless curiosity that kept landing hardest on AI and machine learning. When I finally committed to finishing my master's degree, I knew I couldn't approach it the way I had approached learning in my twenties. The volume was too high. The connections too important. Twenty years inside enterprises had taught me one durable lesson: if you can't operate at scale, you can't sustain.
That's when Obsidian clicked. Dark mode. The knowledge graph — a visual representation of how ideas connect across disciplines, which is exactly how I retain things. A plugin ecosystem that turned a notes application into a platform. I understood immediately this wasn't a better OneNote. It was a different category of thing entirely.
The workaround that became infrastructure
Workers built their own.
Not as rebellion. Not as shadow IT in the classic sense. As a survival response. When the enterprise couldn't give knowledge workers what they needed at the pace they needed it, they found tools that could. Notion. Roam. Logseq. Obsidian. A generation of thinkers built personal knowledge systems that were faster, more connected, and more honest about how cognition actually works than anything IT had ever procured.
The methodologies that emerged alongside — Zettelkasten, PARA, Getting Things Done reinterpreted for networked thought — weren't productivity hacks. They were cognitive load management under acceleration. Ways of operating at scale and speed inside a single human mind, when the enterprise offered no equivalent.
The enterprise didn't ignore this. It just didn't see it. The tools were personal. The practice was invisible. The productivity gains showed up in individual output, not in any system the organization could observe or replicate.
The markdown convergence no one planned
Here is the part that still strikes me as quietly prophetic.
Personal knowledge workers chose markdown for portability. Plain text. No proprietary format. No vendor lock-in. Files that would open in any editor, survive any migration, outlast any acquisition. It was a bet on longevity made by people who had been burned before.
Large language models adopted markdown for entirely different reasons. Computational efficiency. The balance between structure and readability that makes markdown easier to parse than rich text without losing the semantic signals that help a model understand hierarchy and emphasis. LLMs didn't choose markdown because they cared about portability. They chose it because it was the right substrate for machine reasoning.
Two paths. Different motivations. The same destination.
"The portability bet turned out to be the AI-readiness bet. Nobody planned it. It was structural."
The knowledge workers who built personal systems in markdown — without knowing anything about how language models worked — accidentally built their vaults in the format that AI would eventually read most fluently. The portability bet turned out to be the AI-readiness bet. Nobody planned it. It was structural.
Three vaults
I manage three Obsidian vaults today. The separation is deliberate, and living inside it has taught me things about the relationship between human cognition and AI assistance that I haven't seen named clearly anywhere.
The first I call Jaysoul. It is a journal — prompted reflections, private synthesis, the layer where I am working something out and not ready to share it with any system. AI never touches it. It is mine alone.
The second is my organizer — life management outside the platforms. Proton. Google. The logistics of existing. What makes this vault different from a calendar or a task list is that the plugin ecosystem gives it long-term planning capability that no single platform offers, and the structure is deliberately agent-ready. Plain markdown. Linked concepts. An index an agent could traverse. It is built so that when the right agent harness arrives, the knowledge layer is already there waiting. The infrastructure is ready. The governance is mine.
The third is where I go deep — information theory, AI research, the ideas that eventually become writing like this. AI can touch this vault but cannot change it. Guidance only. No rewrites.
I tried the LLM Wiki pattern — letting an AI agent build and maintain the knowledge base automatically. I was the bottleneck, and I accepted that. I learn better when I build the connections myself. What I need from AI is not a ghostwriter for my knowledge base. I need something that can see what I'm missing and point without touching.
That distinction — between AI as synthesizer and AI as collaborator — is the one most enterprise AI deployments have not yet made.
What the enterprise never built
SharePoint and Confluence are not tool failures.
Both platforms are widely adopted. Both are technically extensible. Both have plugin ecosystems that, in theory, could support the kind of structured, linked, agent-ready knowledge management I am describing.
In practice, almost no organization has built that.
The extensibility sat unused because the precondition was never established. Not the technology — the governance. The knowledge culture. Someone who owned the structure, maintained the links, decided what counted as canonical and what counted as draft. SharePoint gave organizations a platform and assumed the knowledge practice would follow. It didn't. Confluence gave teams a wiki and assumed someone would tend it. Nobody had time.
"The tools got blamed for a problem that lived one layer up."
This is not a tool failure. It is a governance and knowledge organization failure wearing the costume of a tool failure. The tools got blamed for a problem that lived one layer up.
And this is precisely why RAG on top of them doesn't work. You cannot compress what was never organized. You cannot retrieve what was written to be read, not reasoned over. You cannot ask a language model to synthesize a corpus whose contradictions were never reconciled, whose links were never maintained, whose tribal knowledge was never written down.
The substrate was never built. The AI just made the absence legible.
The gap that is now visible
My personal knowledge infrastructure is more capable than anything my enterprise clients can offer their workers. That sentence would have sounded absurd five years ago. Today it is simply true.
The people who feel it most acutely are the ones who have built serious personal systems and then gone back to work inside a SharePoint site. The cognitive whiplash is real. Not because the enterprise tools are bad. Because the gap between what an individual can now build for themselves and what the enterprise has maintained for its workers has grown faster than anyone anticipated.
Generative AI is not causing this gap. It is revealing it — and magnifying it — at a rate organizations are not yet prepared to absorb.
The workers thriving in this environment are not the ones who found the best AI tool. They are the ones who built a substrate worth plugging AI into. Who spent years curating, linking, and maintaining a personal knowledge base that a language model can actually reason over — because the structure was there before the AI arrived.
I spend my working days on both sides of this gap. Living inside the personal system. Advising inside the enterprise. Leaving analytic breadcrumbs — nudging organizations toward a future their current stacks weren't built for, without threatening the systems they depend on today.
The gap is not a technology problem. It never was. It is a sequencing problem. And the sequence has a shape.
By Jason Miller