The knowledge that matters has never been computerised. Until now.

Computing has always been fundamentally conservative. It excels at structure, at routine, at work that can be reduced to predictable patterns. For fifty years, enterprises have poured billions into systems that do exactly this. Relational databases, ERPs, CRMs. They captured the transactional layer of business, the operational heartbeat. Revenue by quarter. Stock levels by SKU. Customer interactions logged and queryable. If your business problem fit into rows and columns, computing solved it brilliantly.

But that was always just twenty percent of what an organisation actually knows.

The other eighty percent has never been computerised. It lives in the expertise of people who have solved the same problem a hundred times and learned what actually works. It lives in institutional memory, in the reasoning behind decisions, in the accumulated judgment that separates a mediocre operation from an exceptional one. It is the knowledge that drives competitive advantage, but it is almost entirely inaccessible to the systems that run the business. When an expert leaves, that knowledge walks out the door. When a decision needs to be made, someone has to find the person who knows, interrupt their work, and extract what they need. It is inefficient. It is fragile. It is how we have always done it.

Until recently, there was a good reason for this. You cannot reduce expertise to a schema. You cannot normalise judgment. Unstructured knowledge does not fit into databases because databases require predictability. They require structure. And for decades, that was the hard constraint.

LLMs change that constraint. For the first time, we have tools that can work with unstructured knowledge, that can reason across ambiguous, messy, real-world information the way human experts do. And that opens a question we have never had to answer before. How do you actually build systems that capture, maintain, and serve expertise at scale?

The answer is not what most people think it is.

The static knowledge problem

The industry’s first answer to this question was retrieval-augmented generation. RAG. The idea is straightforward. Take your documents, break them into chunks, convert those chunks into mathematical representations, and store them in a vector database. When someone asks a question, search for the most relevant chunks, feed them to a language model, and generate an answer.

It works. For demos, for proofs of concept, for getting started. But it has a fundamental limitation that becomes obvious in production. The knowledge base is static. Documents go in, get processed, and freeze. Nothing updates those chunks based on how they perform. Nothing flags when content goes stale or contradicts newer information. Nothing improves the knowledge base based on what users actually ask or what experts actually correct. The moment you finish ingesting, the knowledge starts degrading.

This is the gap that matters. RAG gives you a system that answers questions. It does not give you a system that learns. The knowledge base never improves from use. It never incorporates corrections. It never fills its own gaps. When the underlying knowledge becomes stale or outdated, nothing flags it. Nothing retires it. It sits in the retrieval pool indefinitely, surfacing confidently in response to queries long after it stopped being accurate. The knowledge base is a snapshot of what you knew at ingestion time, and it stays that way until someone manually re-ingests.

Closing the loop

The difference between a static knowledge base and a living one is a single architectural decision. Do you measure what happens after retrieval, and do you feed that measurement back into the knowledge itself?

In a static system, retrieval is the end of the story. A chunk gets surfaced, the model uses it, the user gets an answer. Nobody tracks whether that chunk actually contributed to a good response. Nobody records when an expert says “that’s wrong.” Nobody notices when the same gap in the knowledge base causes the same failure for the fifth time. The system has no memory of its own performance.

In a living system, every interaction is a signal. When a chunk is retrieved but never contributes to a well-grounded response, that is a signal. When an expert corrects an answer, that is a signal. When the agent cannot find relevant knowledge for a question that should be answerable, that is a signal. The question is whether you capture those signals and act on them. If you do, the knowledge base improves through use. If you do not, it decays.

This pattern, closing feedback loops, is not specific to knowledge management. It shows up everywhere in the work we do with agentic AI. It is the principle behind self-healing systems, behind trust escalation, behind every architecture that improves rather than degrades over time. Measure performance. Feed the measurement back. Let the system learn. The specifics vary. The pattern is universal.

What this looks like in practice

We are building expert systems at inmydata that capture decades of specialist knowledge and serve it to agents through retrieval pipelines. The knowledge base is not a static archive. It is designed to improve through use, and the feedback loops are what make that possible.

The most striking example is gap detection. When a user asks the agent a question and the retrieval pipeline finds nothing relevant in the knowledge base, the agent does not simply say “I don’t know” and move on. It recognises the gap and creates an interview request. Our interview platform then schedules a conversation with the relevant domain expert. That expert’s knowledge is captured, processed, and fed back into the knowledge base. The gap is closed. The next person who asks the same question gets a grounded, well-sourced answer.

That is not a knowledge base retrieving what it already knows. That is a knowledge base actively discovering what it does not know and reaching out to fill the gap. The system identifies its own blind spots and fixes them.

Other feedback mechanisms work at different scales. Expert corrections captured during use feed back into the content itself, updating chunks with full provenance so you can trace every change back to who made it and why. Performance monitoring tracks which chunks are frequently retrieved but rarely contribute to good answers, flagging content that may be stale, misleading, or poorly structured. Each of these loops operates independently, but together they turn a static repository into a system that compounds in value over time.

The pattern is emerging everywhere

Andrej Karpathy published a gist on GitHub in early April describing what he calls the LLM Wiki. The core idea is that instead of retrieving from raw documents on every query, an LLM should incrementally build and maintain a persistent, interlinked knowledge layer that compounds over time. Knowledge should be compiled once and kept current, not re-derived on every question.

His system is personal-scale. Markdown files in an Obsidian vault rather than vectors in a database. An LLM that reads new sources, extracts key information, updates existing pages, flags contradictions, and maintains cross-references. The LLM handles the ongoing maintenance, the updating, the cross-referencing, the contradiction-flagging, that makes a knowledge base useful over time but that humans consistently fail to do manually. Within nine days the gist had over five thousand stars and spawned dozens of implementations.

The tools are completely different from what we build at inmydata. The principle is identical. Knowledge that improves through use. Systems that compile and maintain rather than just retrieve. Feedback loops that keep the knowledge current rather than letting it freeze at ingestion time. Karpathy frames it as a personal productivity pattern. We are building it as enterprise infrastructure. But the underlying insight is the same, and the fact that it is surfacing independently across different scales and contexts tells you something about where this field is heading.

A new computing discipline

We have spent fifty years building the infrastructure for structured data. Relational databases, query languages, indexing strategies, replication, backup, recovery. An entire discipline of engineering exists around storing, serving, and maintaining data that fits into rows and columns. That discipline is mature. The patterns are well understood. The tooling is robust.

Nothing equivalent exists yet for unstructured knowledge.

We are at the very beginning of discovering what that discipline looks like. How do you measure the quality of a knowledge base that contains expert judgment rather than transaction records? How do you detect when knowledge has gone stale when there is no schema to validate against? How do you maintain provenance when content is corrected, enriched, and synthesised over time? How do you build retrieval systems that know the difference between a chunk that is topically adjacent and one that is genuinely relevant?

These are not AI questions. They are infrastructure questions. They are the same category of questions that the database community spent decades answering for structured data. The answers will be different, because unstructured knowledge behaves differently from transactional data. But the work is the same kind of work. Designing systems, building feedback loops, establishing quality standards, creating tooling that makes the discipline repeatable.

The organisations doing this work now are not just building better AI products. They are building institutional knowledge about how to manage knowledge itself. That compounds in exactly the way a living knowledge base compounds. Every problem you solve, every pattern you identify, every feedback loop you close makes the next system you build faster and more reliable.

Build the loops

The model interprets. The knowledge is the magic. I wrote that in a post about context engineering a few weeks ago, and it is more true now than when I wrote it.

The models will keep getting better. Context windows will keep growing. Retrieval techniques will keep improving. None of that changes the fundamental problem. If your knowledge base does not learn from use, it degrades from the moment you build it. If it does learn from use, it compounds.

The difference is feedback loops. Measure what happens after retrieval. Capture expert corrections. Detect gaps and fill them. Track what works and retire what does not. These are not sophisticated AI concepts. They are the same engineering principles you have applied to every production system you have ever built. The domain is new. The discipline is not.

The knowledge that matters, the expertise, the judgment, the institutional memory that actually drives decisions, has been outside computing for fifty years. It does not have to stay there. But getting it inside requires more than a vector database and a retrieval pipeline. It requires systems that treat knowledge as living, improving, and worth maintaining.

We are building those systems. The field is wide open.