November 2026
Four questions that tell you whether what your organisation knows is an asset or a liability.
Every organisation runs on knowledge it cannot fully retrieve.
We all understand the basic assumption of any IT operation: someone always knows why. Someone knows why the billing service retries the way it does. Someone knows why the vendor contract has a clause nobody uses. Someone remembers what happened the last time a team tried the obvious fix, which is why nobody has tried it since. Almost none of it is written down anywhere useful. It lives in people, and it moves between them the way it always has: you ask, and they tell you.
That works until the interfaces shift, and suddenly you need to update a dozen agents with context and institutional knowledge while still meeting the next deadline. At that point the panic button — keep asking until you find the person who knows why — stops working. Part of the knowledge base you build to support agentic-assisted delivery has to capture who knows why, and it has to capture it before the people and process behind that knowledge can be safely retired. If you get that knowledge base wrong, AI does not fail gracefully. It fails at scale. Remove the people and process that hold the institutional knowledge and you will find what many organisations are beginning to discover: AI failures are hitting harder now because the human backstop has already been removed.
Without memory, every decision gets made twice. The first time costs a meeting. The second costs a meeting, plus the drift between the two answers, plus the credibility of whoever has to explain why the rule changed. An organisation that cannot recall why a thing is the way it is will re-litigate it forever, and each re-litigation produces a slightly different answer.
People leave, and the reasoning leaves first. The system keeps running, so nothing looks broken. What's gone is the reason it is shaped that way — so the next person either keeps the shape out of superstition or breaks it by accident. Neither of them knows they are doing it.
You cannot improve what you cannot see. Cost, reliability, onboarding time, risk — every one of those depends on someone being able to answer "how does this actually work today?" If that answer lives in one head, you have a single point of failure with a calendar entry. Time-to-context for a new hire is the human version of the same measurement.
And the fourth is new: AI removed the tolerance that was hiding the other three. An agent answers at machine speed, in the same confident voice, whether it read a policy document or a three-word placeholder. It has no hallway, and no eight years of doing the same run every Monday morning because that is how you start the week. It has what you gave it, and nothing else.
This is why it stopped being a knowledge-management talking point and became an operating problem. The gaps were always there. What changed is that something now surfaces them continuously, at speed, and acts on them without checking. If you are lucky, that is your internal IT team working through early-adopter problems. If not, it is a downsized team struggling to keep the lights on. Either way, the gap between what is in production today and how it needs to operate going forward is one you have to fill — and it is probably costing you OpEx today while leaving you exposed to exploits buried in years of IT debt.
Fortunately, you do not need a maturity model, a platform, or a twelve-month programme to find out whether your memory is any good. Start by asking four questions, in this order.
Not "does it exist." Anything can exist. The question is whether it comes back at the moment a decision is being made, to the person making it.
Most organisations pass the first test and fail the second. The document exists, in a folder, with the right name, and nobody has opened it in two years. That is not memory. That is storage with a naming convention.
Test it: ask a real question a new hire would ask in their second week — "how do we handle a refund after thirty days?" — and see whether the answer comes back without a human. If the honest answer is "ask Sarah," you have found the boundary.
A fact has a shelf life, and most organisations never write the expiry date on anything.
There are only two ways for knowledge to stay true. Either it regenerates from a source that is itself maintained, or it carries a date and someone checks it. Everything else is a snapshot wearing the clothes of a fact: correct when it was taken, quietly wrong by Tuesday.
Test it: pick any number your team quotes — a headcount, a cost, a service level — and ask when it last changed and what would have to change it. If nobody can answer, the number is a rumour with a decimal point.
Trust has two parts: where a claim came from, and whether the version you are looking at is the version that matters.
Most organisations hold more than one copy of important things and no way to tell which is authoritative. Both look plausible. Both are formatted correctly. One is a draft from March. The failure is not that the wrong answer exists — it's that the wrong answer is indistinguishable from the right one, so people stop relying on either.
Test it: take one specific fact and ask three people where it came from. If you get three different answers — or three shrugs — you have text, not memory.
One name, per store. Not a team, not a department, not "everyone."
A store with an owner gets searched, gets updated, gets its provenance checked, and gets retired properly when it is done. A store without one does none of that, and nobody notices, because an unowned store is silent by definition.
Test it: name the owner of your wiki, your shared drive, your data warehouse, and your AI memory. Out loud, one name each. If you hesitate on any of them, that store is probably an orphan — or worse, it has multiple masters, none of which is entirely sure of the facts. You will find ownership problems as you go, but start with simple, verifiable facts and build a solid base from there.
Because they fail differently, and the order matters.
Finding fails loudly. You get nothing back, and you know it. Currentness fails quietly — the answer is there, it is just out of date, and you discover that months later. Trust fails confidently: two sources agree with each other and are both wrong. Ownership fails invisibly: nothing breaks, nothing alerts, the store simply drifts and then quietly leaves the conversation.
Put another way, the four questions run from the failure you will notice to the failure you will not. And ownership sits at the root, because whoever owns the store is the person who keeps the other three answers true. This is the documentation phase of a development project. No one wants to do it, no one wants to own it, but it will matter a lot to everyone if it is left to build itself.
That is also why buying a tool does not fix this. A vector database, a wiki, a data catalogue — all of them are storage. None of them answers "who owns this," and none of them notices when the answer stops being true. And when one of them is wrong, there is no name against it: a tool cannot be accountable, and nobody has agreed to be accountable on its behalf.
When I ran this against my own setup, the results were less dramatic and more useful than I expected.
Nearly half of what the system "knew" was a generated summary of the other half — documents derived from my own repository, rendered automatically, then treated as knowledge in their own right. Both copies were correct. Neither was authoritative. That is not an unusual failure; it is the normal state of a corporate knowledge base.
One surface held 142 entries averaging 79 characters each: about a tenth of the index and half a percent of the content. Pointers to things that had never been written. Not wrong, exactly, but it had been quietly taking a share of every search for months, and it sounded exactly as confident as the real material.
And on a server doing something else entirely, there was a folder of 1,588 résumé embeddings — created for a project that ended, never deleted, never registered anywhere. Seven megabytes. Nothing reads it. Nothing maintains it. From the outside it is indistinguishable from a store someone deliberately retired, because "decommissioned" and "forgotten" look identical unless somebody wrote down which one it was.
The pattern across all of it: the failures were not where I expected them. I assumed I was missing files. I was missing three things — a way to find what I already had, a way to know whether it was still true, and a name against every store. Which is, more or less, the four questions.
You do not need to fix the whole estate. Pick one store this week — the one people ask about most — and ask the four questions in order. You will get a yes, a no, a maybe, and a blank. The blank will tell you more than the other three.
The point is not perfect memory. Perfect memory is a fantasy, and an expensive one. The point is being able to say precisely where yours is thin, and who is responsible for the thin parts.
Every organisation has this problem. Most are still paying for it in hallways, in repeated decisions, and in the slow tax of asking the same person the same question — until one day they move on and you have no idea how to get back what they walked away with. Those departures and gaps are being accelerated by the shifts in the technology stack, and those changes are not slowing down. It is a journey that gets a little easier as you go, but it is one you need to start.
Built on a home lab, powered by local models, and owned by Andrew Katana.