Last week we audited the AI knowledge base our company runs on, and found three things quietly broken. Not one of them had thrown an error.
The first was a planning document, the one we treat as our source of truth, still saying a workstream was paused. We had been running that workstream for days. The second was the instruction file that tells our AI how to work: it had grown so large that the model started skipping rules we had written ourselves. We trimmed it, and it started following them again. The third was a scheduled automation that had stopped running weeks earlier, silently, with nothing to flag it.
The one that caught us off guard was context rot. We had assumed that giving the model more to work with made it more capable. The research, and our own system, say the opposite.
This article covers what context rot is, why company AI knowledge bases drift, and the operator practices that keep a knowledge base honest as it grows. We build custom software for manufacturers and operations-led companies at the.good.code;, and we run our own operation on this kind of system, so the failures below are ones we have lived through, not theory.
What is context rot, and why does it hit AI knowledge bases?
Context rot is the measurable drop in a language model's accuracy as the amount of text you feed it grows, and it sets in well before the context window is full. In Chroma's 2025 study across 18 leading models, performance fell by roughly 30 to 50 percent as input length increased, long before any model reached its documented limit [1].
Three mechanisms drive it. The lost-in-the-middle effect means models attend well to the start and end of a long input and poorly to the middle. Attention dilution means each new token competes for a finite budget of attention. Distractor interference means content that is similar but irrelevant actively misleads the model rather than being ignored.
An AI knowledge base sits right in the path of all three. It works by pulling stored material into the model's context on demand, often alongside a large standing set of instructions. The more you load in for safety, the worse the answers get, and the degradation is quiet. The model does not refuse. It answers confidently from a diluted view of the truth.
Why do company AI knowledge bases drift?
Company AI knowledge bases drift because they keep looking finished while the reality they describe moves on. The system stays neat. The facts inside it age.
We saw three distinct failure modes, and they generalise well beyond our setup:
- The source of truth stops matching reality. A document that decisions depend on keeps its confident tone after the situation it describes has changed. People act on it precisely because they trust it.
- The instruction layer bloats until the model ignores its own rules. Every new instruction feels cheap to add. Past a certain size, the constraints you care about most are competing with everything else you have ever written down, and the model starts dropping them.
- Automation fails silently. A scheduled job stops firing, and because it produced no error and no alert, nobody notices until they go looking.
The common thread is the dangerous part. None of these broke loudly. Each one looked current while being wrong. A knowledge base that drifts from reality is more dangerous than having none, because people stop checking the source they have learned to trust.
What is context engineering, and why does it beat feeding the model more?
Context engineering is the discipline of fitting the right information into a model's limited attention, rather than the most. Anthropic frames it as a shift away from wording prompts and towards a broader question: what configuration of context is most likely to produce the behaviour you want [2].
In practice it comes down to a few habits. Keep an index and fetch the few relevant files for a task instead of loading the whole store. Compile valuable answers into durable notes once, rather than re-deriving them from scratch every time [3]. Keep the always-loaded instruction layer small, and push rarely-needed detail into references the model reads only when a task calls for it.
Adding context has a ceiling. Past it, accuracy falls, which is the opposite of what most teams expect when they paste in more. Engineering context means deciding what the model should not see as carefully as what it should.
How should an operator run a company on an LLM without drift?
Treat the knowledge base like any other operational system: one source of truth, explicit versioning, a lean instruction layer, and a scheduled audit. This is process work, and it is the part that actually decides whether the system helps you.
- Keep one source of truth, and make it match reality. Pick the document that decisions run on and reconcile it against what actually happened, on a cadence. If it disagrees with the world, the world wins.
- Mark outdated information as outdated, rather than overwriting it silently. When something changes, leave a visible note that it changed and why. Both the team and the model should see the correction, not just the new state.
- Keep the instruction layer lean. When a model starts ignoring its own rules, the instruction file is usually too big. Move detail into on-demand references so the rules that matter still land.
- Audit on a schedule, not on failure. We now review the system the way we would check a number before it goes in front of a client. A fixed cadence catches quiet drift that a break-fix habit never will.
- Treat knowledge as delivery infrastructure. For any company moving to AI-native delivery, the context layer is part of the product. It deserves the same versioning, review, and ownership as the code.
None of this needs a new tool. It needs an owner and a schedule.
Second brain versus company knowledge base: what changes at scale?
A personal second brain fails quietly and only costs you. A company knowledge base fails the same way, but the cost lands on a team, and the AI amplifies whatever is stale. That is why the discipline has to be heavier at company scale.
The personal version has a well-documented trap called the collector's fallacy: saving information feels like progress, so the archive grows and grows while very little of it is ever read or used again [4]. At company scale that same instinct becomes expensive. Several people act on the same out-of-date source, and an LLM confidently spreads it further.
So the shift that matters is from collecting to maintaining. At company scale, a knowledge base is worth only as much as it reliably matches reality, regardless of how much it holds. Fewer notes, verified and current and written so a machine can read them, beat a large pile every time.
Frequently asked questions
What is context rot?
Context rot is the measurable decline in a language model's accuracy as the input grows longer. It appears well before the context window is full, and it is driven by the lost-in-the-middle effect, attention dilution, and interference from similar but irrelevant content.
Do I need RAG or a knowledge graph to run an AI knowledge base?
Usually not as a first step. If your knowledge is already structured, with clear files, links, and routing, a simple index-and-retrieve approach often outperforms bolting on a vector database or a knowledge graph, both of which add cost and maintenance. Add that layer when plain retrieval genuinely stops scaling, not before.
How large should an AI instruction file be?
Small enough that the rules you care about are never competing with noise. A practical signal: when the model starts ignoring instructions you know you gave it, the file has grown too big. Move the detail into references the model reads on demand.
How often should we audit an AI knowledge base?
On a fixed cadence rather than when something breaks. The right interval depends on how fast the underlying reality changes; the point is that drift is silent, so only a schedule catches it.
What is the difference between a second brain and a company knowledge base?
A second brain is personal working memory. A company knowledge base is shared operational memory that an AI reads from and writes to, which means it needs a single source of truth, visible versioning, and regular review that a personal system can safely skip.
The bottom line
The tools for an AI knowledge base are the easy part. The discipline that keeps it honest is the work: one source of truth, visible versioning, a lean context layer, and a scheduled audit. Get that wrong and the failure is silent. The system keeps looking finished while it drifts, and everyone keeps trusting it. Get it right and the same system becomes something you can actually run a company on.
We run our own company on this kind of system, so if you want a straight read on yours, or on an AI-native delivery model more broadly, book a welcome coffee through our technology strategy advisory. The first question we ask is often whether you need to build anything at all, because a good advisor will sometimes tell you not to build.