The Incentive Vacuum

I have spent twenty years watching organizations fund knowledge management initiatives with real budget and real intent, and watching most of them go unevenly maintained within a year or two. Not because the technology failed on launch day. Because the maintenance was never evenly distributed to begin with.

This isn't a story about bad tools. Every KM platform I have implemented, migrated, or inherited was technically capable of doing what it was bought to do. What I actually watched was asymmetry: a handful of KM champions on a handful of teams carrying the discipline for everyone else, while most teams quietly opted out. And the more technical the team, the more begrudging the participation. Engineers will document a function for themselves in a comment nobody else reads. Ask them to translate that logic into a business rule someone in operations can act on, or an SOP that updates when the logic changes, and the willingness drops off fast. Not because they can't. Because writing for someone else's understanding is a different, unrewarded skill, and there was never enough time in the sprint for it.

That asymmetry is the real failure mode, and it's older than AI. It's also the reason RAG, bolted onto the same platforms, was never going to be the fix everyone hoped for. RAG doesn't create champions. It just searches faster over whatever the champions who existed happened to leave behind.


The maintenance nobody budgets for

Knowledge management has a consistent failure pattern, and it has almost nothing to do with which platform gets selected. Someone builds the taxonomy. Someone tags the first thousand documents. Someone writes the wiki pages that make the system genuinely useful for the first six months. Then that person gets reassigned, or leaves, or simply runs out of time as their actual job absorbs the hours the KM system was borrowing.

The system doesn't collapse. It just stops being current. Six months later it's a search index over stale information, which is arguably worse than no system at all, because it now actively misleads the people who trust it.

This is the maintenance burden I referenced when I called SharePoint and Confluence governance failures rather than tool failures. The tools didn't create the burden. They just never solved it, because solving it was never their job. It was an organizational discipline question, and organizations consistently underfund discipline in favor of tooling.


The 10x threshold

Enterprise systems don't get replaced because they're bad. They get replaced when something clears a threshold, roughly ten times better, not twenty percent better, because the cost of switching is never just the cost of the new tool. It's retraining, data migration, workflow disruption, and the political capital of admitting the old system was a mistake. Anything short of an order-of-magnitude gain gets absorbed as a minor upgrade or ignored entirely.

RAG never came close to that threshold, and I don't think it was ever going to.

Retrieval-augmented generation makes search faster and occasionally more conversational. That's real value. But it introduces new costs that eat most of the gain: hallucination risk that has to be governed, prompt behavior that has to be maintained, and a retrieval layer that still depends entirely on the quality of what it's retrieving from. If the underlying corpus is the fragmented, unmaintained mess I described above, RAG doesn't fix the corpus. It just answers questions from it faster and with more confidence than the corpus deserves.

That's not a 10x gain. That's a better front door on the same building.


"That's not a 10x gain. That's a better front door on the same building."


The incentive vacuum

Here's the part that took me longer to name clearly: the reason no open standard for knowledge ever emerged isn't an oversight. It's structural.

SharePoint and Confluence are extensible platforms owned by companies that make money from you staying inside them. An open standard for knowledge, one that let your organizational knowledge move as freely as your personal notes do, would commoditize the very lock-in that makes those platforms valuable to their vendors. Nobody who controlled the substrate was incentivized to make it portable. Quite the opposite.

Compare that to what happened in personal knowledge management. Individual practitioners chose markdown precisely because no single vendor controlled it. Portability was the point. But no enterprise vendor was ever going to build the equivalent for organizational knowledge, because the business model runs the other direction.


"Nobody who controlled the substrate was incentivized to make it portable."


RAG and MCP are patterns that emerged inside that vacuum, not solutions to it. They're clever ways of extracting value from knowledge that was never structured to be extracted from. Useful. Necessary, even, as a bridge. But they operate on top of the mess instead of resolving it. Wrong altitude for the actual problem.

The reversal

For years, the friction of switching exceeded the friction of staying. That's the whole 10x argument: nothing beat the status quo by enough to justify the pain of change. But something is inverting right now, and it's worth naming precisely. There are two drivers, and the first one gets less attention than it deserves.

The KM champion asymmetry I described earlier was never really a discipline problem. It was a labor problem. Writing for someone else's understanding takes time nobody budgeted for, and the most technical teams, the ones producing the densest, most consequential knowledge, had the least incentive to spend it. LLMs remove that labor cost. An agent can maintain the code comment, translate it into the business rule that depends on it, and keep the downstream SOP current when the logic changes, continuously, without waiting for a champion to have a free afternoon. The human's role shifts from author to reviewer. Someone still approves what gets written and traces it back to its source. They're no longer the reason it doesn't get written at all.

The second driver is the one everyone's talking about: prompt engineering has a ceiling. You can get an agent to behave well on a single task with a well-crafted prompt, but that behavior doesn't accumulate. It doesn't remember what the organization learned last quarter. It doesn't know which policy version is current or which project decision superseded an earlier one. An agent without organizational memory is doing the same thing on every single query, starting from zero, the same failure mode RAG was supposed to fix and mostly didn't.

Organizations are discovering that the ceiling on agentic AI isn't model capability. It's the absence of a substrate the agent can actually build memory on top of. That absence used to be a passive inconvenience: annoying, survivable, someone else's problem. It is becoming an active liability, because every AI initiative that depends on organizational context now runs headfirst into the same wall.


"The absence used to be a passive inconvenience. It is becoming an active liability."


The cost of staying the same is no longer close to zero. That's the reversal. And it's the first real crack in the 10x wall that knowledge management has been failing to clear for two decades.

Five weeks, two companies

I don't think this reversal is theoretical. I think it's already visible in how fast the tooling is moving.

Google Cloud published the Open Knowledge Format specification on June 12, a vendor-neutral standard for representing knowledge as plain markdown with YAML frontmatter, explicitly designed to be readable by both humans and AI agents. Five weeks later, LangChain shipped version 0.2 of OpenWiki, their open-source tool for generating and maintaining codebase documentation, with native OKF support built in. Wikis generated by OpenWiki now carry structured frontmatter, an index.md that summarizes each directory, and a running changelog of what changed and when, so an agent can filter by category or tag instead of searching the entire wiki on every query.

Two companies. Five weeks. Neither one waiting for the other to move first, both building toward the same open format because the format solves a problem both of them have.

That is what an emerging standard looks like in its first months. Not a committee. Two teams independently deciding the same open contract is worth building on.

Codebases, not digital paper

The detail that matters most about what OKF and OpenWiki are doing is the shape of it. An index. A changelog. Structured metadata that makes retrieval deterministic instead of a fresh search every time. Version history that shows exactly what changed and why.

That's not a document management pattern. That's a codebase.

I think this is the correction the entire discipline needs. Enterprise knowledge management has spent thirty years treating knowledge like digital paper: store it, tag it, search it, hope someone maintains it. Software engineering solved the maintenance problem for code decades ago with version control, changelogs, and structured review, because code that nobody could trust was code nobody could ship. Knowledge deserves the same discipline, and now it has a format that can carry it.

None of this replaces SharePoint or Confluence. It doesn't have to. It doesn't need to clear a 10x threshold against systems that are already deeply embedded in how organizations work today. It needs to sit alongside them, compiling what they already contain into something an agent can actually build memory from: governed, versioned, and current, the way a codebase is current.

That's not a replacement strategy. It's a different kind of architecture entirely.


By Jason Miller

Linked Pages

Tags

#knowledge_management #enterprise_architecture #rag #mcp #okf #sharepoint #confluence #artificial_intelligence