Where we're going, we don't need wikis

Lots of talk about knowledge bases, LLM wikis, and company memory lately. Good, it’s important. But the current debate over how many markdown files is too many overlooks a much deeper truth: the company wiki is an outdated solution that we have a generational opportunity to overcome.

We’re not above this. The first versions of Knowhow were essentially a better wiki. Cursor for knowledge bases, with some nifty personal attribution built in. We got customers and immediately got our asses kicked. Adoption fell off a cliff the moment management stopped encouraging usage, despite users telling us how much they liked it. We needed to find out why.

The answer, it turns out, was chat. Despite an abundance of lovingly maintained documents, the people on the ground were in group chats, hammering the small handful of experienced people for confirmation dozens of times a day. The truth of the organization was there.

We started looking for that signal in every customer interview and demo call. We found it every single time. We found it in our own experiences. I use Slack every day, so much so that I feel like I work for it. I’ve been one of those super-users at a large org and it felt like I was in some kind of behavior experiment, my eyes pried open Clockwork Orange-style so I couldn’t resist the barrage. It soon became clear that this was about much more than noisy Slack channels.

Wikis have been successful because they were the default option. An electronic form of record keeping that humans have been doing for six thousand years. Writing things down and keeping them in a safe place has had a great run. For 99.9667% of that time, centralized record keeping was the best way to describe reality. Solving this became our obsession.

“Company wiki” is shorthand here for any type of approach to managing a company’s expertise with a centralized, document-driven system. Writing things down and keeping them in a safe place. An ancient system, but by no means an inevitable one.

The core issue with wikis is that they force a company to maintain a simplified, artificial copy of itself made out of documents, labels, and imaginatively defined workflows. We accepted these compromises because we had no better way of representing the constantly evolving expertise of the people who make up a company and take action on its behalf. It was the least worst solution. Documentation may resemble reality to varying degrees, but by definition it’s always stale upon arrival because the real world moves faster than any kind of top-down speculative writing process can represent.

In short: the wiki was never a company’s true knowledge. It was simply the shape that knowledge had to take before systems and software could understand people.

The inherent limitations of a wiki demand an enormous maintenance and comprehension burden. It requires people to stop doing the work that matters for their customers, predict what their colleagues might need, invent a structure for it, write it down, then maintain it forever. We accepted this bargain on the hope that if we did some extra work for the system now, that system would help someone later. Too often, the bargain didn’t deliver. That feeling of “Notion is too confusing” or “I spend more time writing in Confluence than committing code” is a symptom of this.

Generative AI’s innate capacity for automation seems to present a solution: have a machine take over the toil of updating and reading documents. It makes for a punchy argument: wikis go stale because people fail to maintain them, AI will solve that with {insert jargon here, ideally using the word layer a lot}.

This is bad. The companies that do this will lose. Why? Because automating the wiki is not escaping its limitations, it’s hypercharging them with AI slop derived from general purpose training data that everyone has the same access to. Your company and its people are out in the real world, serving customers and generating unique expertise every day, but what you are feeding into your documents is stochastically assembled content loosely derived from that experience.

Using AI to generate and maintain artifacts that never needed to exist is actively harmful to your alpha.

Generative AI has given us something truly new under the sun:

Computers we can talk to, that can understand us.

The translation layer that documentation demands, where a person has to go through the effort of trying to force their messy (but extraordinarily valuable) real-world experience into neatly typed fields and artifacts, is no longer necessary.

I think the full implications of this still get overlooked. We now have technology that doesn’t just automate bureaucratic toil but completely eliminates the need for it at the root. In the simplest form, it’s a time-saver. Beyond that is something much more dramatic: the promise that a company’s digital twin can now actually resemble how it really works.

This will not look like “ask the bot for a deck in Slack” or “infer how my company works by reading our CRM and ERP.” It’s going to look more like “ask how we do it here, now” and the system answers. When it doesn’t, it goes out and finds the answer from someone who does. In the background there’s a constant ambient hum of knowledge growing in every conversation, where AI stores feedback from each interaction in a constantly evolving knowledge graph.

To build this, we are focusing on five capabilities:

1. Search and retrieval. Company memory is useless if it cannot bring back the right evidence at the moment someone needs it, quickly and efficiently.
2. Lean, useful knowledge graphs. The most cavemen-dumb-but-effective set of typed edges that improve the relevance of search, discovery, and help to show the true shape of a company’s expertise. Strictly avoid massively complex ontologies that require constant care.
3. Fast, token-efficient agent harnesses. Task-suited tools that produce results quickly and with sustainable token consumption on reasonably sized models. A multi-trillion-parameter model grepping documents at subsidized token prices hides a lot of bad design. We can’t afford that complacency. Notice how this is enabled by 1 and 2.
4. Multiplayer native. In hindsight, it was obvious. The idea that AI apps can be built from the ground up to support multiple people collaborating in realtime with an agent and each other. This is an emerging product discipline that has real engineering implications for how you construct messages and manage context.
5. Building something people choose. This matters most. We are confronting how people actually behave with the same humility and curiosity as someone building a consumer app or a social media network. Business software too often assumes the user is wrong and needs to be trained or mandated into compliance. This cannot work that way. It has to be delightful to use, and genuinely feel like people and conversation are the beating heart of the system. People have to want to use it; not only because it is useful, but because the thing itself feels good and makes them feel closer to their colleagues and their team. We can never put systems before people.

This isn’t science fiction and it’s not unattainable. It’s a clever arrangement of existing LLM capabilities married to search and knowledge graph best practices, shaped with a strict discipline to remain radically simple and devoted to human activity as the site of knowledge creation.

The businesses of the future will run on language.

They will have company memory that reflects reality, as it truly is.

That memory will be maintained on demand, automatically, in conversations between people, right where their work is happening.

It will be powered by AI that listens, learns, and helps. AI that doesn’t fill out forms and maintain documents, but that makes those things unnecessary.

What was ancient will be new again.