Moving Knowledge Up the Substrate Stack.

Karri Saarinen called issue tracking dead in March, and six weeks later OpenAI shipped Symphony and Linear became the literal control plane for autonomous coding. Some teams reportedly saw a 500% increase in landed pull requests. The thing that had just been eulogized was now the substrate that made all of it work.

Nate Jones wrote the post-mortem on that inversion in May 2026. His argument is that issue trackers, CRMs, ERPs, and service desks accidentally became the best agent infrastructure on the market. The structural primitives that solve human asynchronous coordination turned out to be exactly what autonomous agents need. The translation step is going away. The state machine, the assignee field, and the audit history are all staying, and they're going to be doing more work going forward, not less.

Jones ran his diagnostic across most of the categories that hold organizational state. Issue trackers, CRMs, service desks, and ERPs came out as the strong candidates, with most of the five properties already in place. Email and chat came out weaker because their verbs are conversational rather than structural. Spreadsheets sit in a middle position, with structure that depends entirely on whether the author designed the sheet well. Documentation landed near the bottom, with version history as the only property the category reliably delivers. That assessment matches the gap the knowledge substrate argument has been pointing at for the last several months. The bottleneck for AI agents in the enterprise has moved from the model to the substrate, and the documentation layer is where the substrate is in the worst shape.

The two analyses meet in the middle. Jones described the operational properties that make any tool agent infrastructure. The knowledge substrate argument describes the data properties that make any knowledge layer worth operating on. Documentation today fails on both lenses simultaneously, and the two failures compound each other. Building VanaMD has been the work of figuring out how to fix both at once: how to move knowledge management up the substrate value stack onto the same tier the coordination tools have already reached.

That's the piece I want to make explicit here.

The Jones diagnostic is five questions. Run them on any tool in your stack:

The VANA frame from the canonical knowledge-substrate argument is four properties at a different altitude:

These are not the same five questions. They look at the substrate from two different angles. Jones is asking how the system behaves when an agent operates through it. The VANA frame is asking how the data is stored underneath. Both lenses have to return clean answers for the substrate to actually work, and both lenses agree on the same diagnosis for the documentation category as it currently exists.

Run Jones's questions against the wikis, document editors, and modern note-taking platforms most organizations rely on as their knowledge layer.

Records? No. A page is a content blob. There's a title, a body, maybe some tags. Nothing about the document tells you what kind of thing it is. A policy reads the same as a runbook reads the same as a brainstorm. The structure of the entity is whatever the human author decided to type that morning.

The state machine is worse. Documents have two states (draft and published) and sometimes archived if you're using a tool that thought about it. There is no lifecycle that captures how a decision becomes active and then gets superseded, or how a piece of analysis ages from confident to contested. The state of a document is whatever the version date says, and the version date is the cheapest signal in knowledge work.

Ownership? Also no. There's a creator field and there's a list of editors. Neither is ownership. A document with seventeen editors over four years has no accountable owner. It has a haunted history. When an agent reads it and acts on it badly, there is nobody to escalate to.

For verbs, the situation is the same as everywhere else in this category: edit, comment, share. Conversational. A wiki page does not get resolved the way a ticket gets resolved. Its semantics are whatever the prose says, which means the agent has to re-derive the semantics every time it touches the document.

Queryable history is the one most documentation tools get partial credit for. Version history exists. Sometimes it's even navigable in the UI. But "I can see it in a sidebar" is not the same thing as "I can ask, what changed in the deployment policy between Q2 and Q3, and what other documents were updated in the same commit." The first is visibility. The second is queryability. They aren't the same property.

So 1 of 5. Jones is right. And against the VANA frame the result is the same: fragmented authority, native formats only by accident, accessibility skewed entirely toward human readers. The diagnostic isn't tool-shopping. It's a description of the category. The tools at the top of the documentation market today are 1-of-5 tools because the category was built to be a 1-of-5 category. There was no reason to build it any other way until agents arrived as a new class of consumer.

The premise of the work I've been doing on VanaMD is straightforward enough to state in a sentence.

That sentence is easier to write than to ship. Here's what each property looks like in practice when the design constraint is hitting both lenses at once.

Records, not content. Every document is a typed entity. It carries a classification (decision, policy, runbook, reference, or brief) and lives inside a zone with a schema that declares which slots the document is supposed to fill. The schema is part of the data model, not a UI convention. That means it travels with the document everywhere it goes: into the API, into Git, into the MCP responses an agent reads. Native format and records end up being the same property at different altitudes. Markdown gives you the format. The schema gives you the structure inside the format.

For the lifecycle layer, documents move through real states. Decisions go PROPOSED, ACTIVE, then SUPERSEDED, with the dependency graph tracking which active decisions a new one is replacing. Verdicts on individual claims have their own state machine: SOLID, AGING, CONTESTED, DRIFT. Those states are continuously re-evaluated as the document and its dependencies change. A document doesn't stay SOLID because nobody touched it. It stays SOLID because the system keeps checking. This is what Authoritative looks like when it's not a sticker. The canonical status of every claim is a queryable property, not a tribal memory.

Ownership as a field. Owner is first-class on every document, surfaced in the editor's profile bar and queryable through the API. Decisions carry decision-makers separately, because the person accountable for a decision today is often not the one who wrote it. The distinction matters for agents the same way it matters for humans. The agent needs to know who to escalate to, not who to credit.

The verb layer is where I'd give the platform partial credit today. The vocabulary covers create, classify, move, publish, supersede, and score. It's stronger than wiki vocabulary but not yet as crisp as the issue-tracker primitives Jones names. Assign, resolve, block. Closing that gap is on the roadmap. I'd put VanaMD at 4 of 5 on Jones's diagnostic right now, with the verb layer being the part that still needs more work.

For history, the storage layer is Git. Every change is a commit. The history is replayable through both the UI and the API. That makes it Versioned in the VANA sense: true version control with branching, blame, and diff, instead of the read-only timeline most documentation tools call version history. The kind of question you can ask against Git history is a different class of question than what a sidebar can answer, and that gap matters when an agent is trying to reconstruct what happened the last time someone shipped a change to the document it's about to touch.

Four of five today, with a clean path to the fifth. The VANA properties and Jones's coordination properties end up reinforcing each other when the design constraint is to deliver both, because they're describing the same substrate from two angles. You can't have Authoritative in any meaningful way without a state machine. You can't have Versioned without queryable history. Native format and Records converge in the schema layer. The two frames aren't competing. They're the inside and outside of the same design problem.

The most thoughtful comment on Jones's piece came from Eric Rhodes. He wrote: "Structure makes agents operational. It doesn't necessarily make them trustworthy. What seems to be emerging is a second layer that sits above these systems and governs what the underlying state is allowed to mean."

That sentence is the one I'd been trying to write. Coordination substrate makes the agent operational. It can read and write to durable state, hand off cleanly, log what it did.

The agent will then act on it with confidence, because the structure was correct. The only thing wrong was the meaning of what the structure contained.

Documentation has to handle this part of the stack differently than coordination tools do, because for documentation the meaning is the artifact. A policy that doesn't specify its scope clearly will be misapplied. A runbook that omits the failure-mode reasoning will be followed into a wall by someone who didn't have the context the original author was carrying when they wrote it down. When humans were the only consumers of those documents, organizations compensated by hiring senior people who could read between the lines. The policy lawyer who could tell you what the regulator actually meant. The architect who carried the decision history in their head from three jobs ago. Tribal knowledge made underspecified documents work, because the tribe filled in the gaps.

Agents don't have tribes. They consume documents literally and act on them at machine speed. An agent operating on a 60% specified document produces 60% correct work that looks 100% correct, because the prose reads with confidence. The errors compound silently and nobody catches them until something downstream breaks. The Klarna pattern from the canonical knowledge-substrate writeup is the same problem under a different name. Their AI agent resolved 2.3 million conversations and projected $40M in savings. Then customer satisfaction cratered, because the agent was optimizing for speed when the organizational intent was relationship quality. The structure was right. The intent that the structure was supposed to encode was missing.

Specification depth is how that gets fixed. Every document carries a measurable score on how well it specifies its own intent. The score gets recalculated when the document or its dependencies change. It's exposed through the API the same way ownership and lifecycle state are. The agent reads the score before it reads the content. The document tells the agent how much to trust it. That isn't a sixth property bolted onto Jones's five. It's what Authoritative actually has to mean when the consumers of the substrate include agents who can't read between the lines.

The Rhodes comment named the layer. The work is making it concrete enough to ship.

The Jones piece, taken seriously, is the news that knowledge management has a deadline. Coordination tools like Linear, Jira, Salesforce, and ServiceNow are already far along the substrate stack. They score 4 or 5 on the operational diagnostic, and they got there because the structural primitives that solve human asynchronous coordination happen to be the ones agents need. The category is well-positioned for the agent era because it was already well-positioned for asynchronous human work.

In documentation, the picture is different. Every tool in the category scores around 1 of 5 on Jones's diagnostic and a similar score on VANA. There is no thirty-year accumulation of agent-readable structure for the documentation layer to build on, because for most of those thirty years the documentation layer didn't have to be agent-readable. The category is at the start of the curve the coordination tools have nearly finished walking.

That's the bet underneath VanaMD. AI isn't going to replace documentation. Documentation can be rebuilt as substrate the way coordination was rebuilt as substrate, and the rebuild produces something category-defining because almost nobody has even started. The VANA framing names the data layer. Jones's diagnostic names the operational layer. Together they describe what a knowledge tool needs to look like to land where coordination tools are now.

The diagnostic is the thing to take away. Run Jones's five questions on whatever your team uses to capture decisions, document policy, write strategy, and record what you've learned. Run the VANA test alongside it. If your knowledge layer scores below 3 on either lens, the documentation you have today isn't going to carry the agents you'll be running on it tomorrow. Writing well-specified knowledge now is cheap. Retrofitting agent-readable structure onto inherited content sprawl is going to cost more than most teams have on the roadmap.

The boring coordination tools won. The boring documentation is the next category up the curve, and the path is to build it as substrate from the data model up.

That's the work.

This is the problem we're building VanaMD to solve. If these ideas resonate, and you've felt the weight of a knowledge base that's more noise than signal, we'd love to hear from you.