Institutional Memory & AI
In 1086, William the Conqueror sent his commissioners across England to record every acre of land, every head of livestock, every mill and fishpond in the kingdom. The result ā the Domesday Book ā was not an act of curiosity. It was an act of power. William needed to know what he owned, what he could tax, and who might resist him. The parchment they wrote on has survived 940 years. You can still read it. Nine centuries of institutional memory, legible on animal skin, sitting in the National Archives in Kew.
In 1986, the BBC attempted a digital update. The BBC Domesday Project recorded the voices, photographs, and local knowledge of a million contributors onto interactive LaserDiscs. It was a technological marvel. Within fifteen years, the discs were unreadable. The hardware was obsolete. The software was incompatible. A million voices, silenced not by conquest or fire but by a format change. The original parchment, meanwhile, endured.
That is the story of institutional memory in a single parallel. The thing we wrote on dead animal skin outlasted the thing we encoded in light. And if you think that is merely a parable about storage media, you are not paying attention. It is a parable about what organisations choose to remember ā and what they allow themselves to forget.
What Institutional Memory Is and Why It Is Dying
Institutional memory is the sum total of what an organisation knows about itself: how it got here, why certain decisions were made, which experiments failed and why, whose name is on the contract, what the system actually does versus what the documentation says it does. It lives in people's heads. It lives in the stories told over coffee. It lives in the engineer who has been there twenty years and knows that the batch job on server four must not be restarted before midnight because of something that happened in 2003 that nobody wrote down.
When that engineer retires, the memory retires with them. When that team is restructured, the context evaporates. When the civil servant moves to another department ā and in the UK civil service, 12.7% moved or left in 2023/24, with the Department of Health running at 24% ā the knowledge walks out the door and does not come back.
This is not a new problem. But it is an accelerating one.
Consider COBOL. There are 220 billion lines of COBOL still running in production systems worldwide. Those lines process $3 trillion in daily commerce. They handle 95% of ATM transactions. The average COBOL developer is fifty-five years old. Ten per cent are retiring every year. And 85% of universities have dropped COBOL from their curricula entirely. The people who understand these systems are literally dying, and nobody is replacing them. When COVID-19 hit in 2020 and US state unemployment systems buckled under the load, governors were begging retired COBOL programmers to come back and fix systems they had built decades earlier. They called them the "COBOL Cowboys." It would be funny if it were not terrifying.
In the UK public sector, the picture is worse. 28% of central government systems are classified as legacy, rising to 70% in some areas. Nearly a quarter are rated "red" ā the highest risk category. And the government spends 30% less on IT than its peers. The institutional memory required to maintain, let alone modernise, these systems is vanishing with every retirement, every restructure, every round of austerity.
The Submarine That Forgot How to Build Itself
I keep returning to one example because it haunts me. In the 1990s, the United Kingdom decided to build a new class of nuclear submarine ā the Astute class. There was a problem. Between the end of the previous Vanguard programme and the start of Astute, there had been a gap of roughly ten years. A decade in which Britain built no submarines. And in that decade, the tacit knowledge ā the things that experienced engineers knew in their hands and their bones, the adjustments that were never written in any manual ā disappeared. The people retired. The people left the industry. The people died.
The Ministry of Defence had to bring in over a hundred American designers from General Dynamics Electric Boat at a cost of $145 million. The programme ran 57 months late and came in 53% over budget ā Ā£1.35 billion more than planned. The Astute programme had other problems ā scope changes, procurement delays, industrial capacity gaps. But those were the problems the Ministry of Defence could see. The knowledge loss was the one they could not, because nobody knew what they had forgotten until they tried to build the thing.
NASA learnt the same lesson with the Saturn V rocket's F-1 engines. The blueprints survived. The tacit knowledge did not. And when the Columbia Accident Investigation Board declared in 2003 that "NASA is not functioning as a learning organisation" ā seventeen years after Challenger, the same institutional failures had returned ā they coined a phrase that should keep every CTO and permanent secretary awake at night: budget cuts had left critical areas "one-man-deep."
One-man-deep. Think about that.
Brent, the Most Dangerous Man in IT
If you have read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, you will recognise this pattern instantly. The character of Brent is the engineer who knows everything. Every critical system, every workaround, every undocumented dependency. Brent is indispensable. Brent is the hero. Brent is also the single point of failure that will destroy the organisation when he gets hit by a bus, burns out, or simply takes a holiday.
Brent is the human embodiment of institutional memory concentrated in one skull. And the lesson of The Phoenix Project is not that Brent is bad at his job. He is brilliant at his job. The lesson is that the organisation has failed to invest in distributing what Brent knows. The bus factor ā a term coined in the Python community in 1994 ā is one. And a bus factor of one is an organisational death sentence.
The Brent problem is not, at root, a risk management failure. It is an investment failure. Organisations consumed the knowledge their people accumulated over decades and never invested in its capture ā because the knowledge appeared free, a byproduct of having the person on the payroll. The bill arrives when the person leaves.
Every enterprise has a Brent. Every government department has a Brent. The question is whether you know who yours is (if you don't, is it you?), and what happens when they leave.
The Historian's Solution
Some organisations have understood this problem deeply enough to create a dedicated role. GCHQ ā Britain's signals intelligence agency ā has maintained a departmental historian since the institution's earliest days. The current holder, Dr David Abrutat, is the ninth. His predecessor, Tony Comer, served for 37 years and was the first publicly avowed GCHQ historian. Abrutat's mission, as he described it to Computer Weekly, is to preserve the "folk memory" of the organisation before it disappears ā to capture the stories, the decisions, the failures, the context that no filing system retains.
I admire this enormously. The fact that a signals intelligence agency ā an organisation built on secrecy ā has concluded that it needs a historian to preserve its own memory tells you something profound about how hard institutional memory is to maintain. If GCHQ cannot rely on its own filing systems and databases, what chance does your organisation have?
The West African griot tradition proves that dedicated memory-keepers can sustain institutional knowledge across centuries. The Kouyate line has maintained unbroken historical memory for the Mali Empire for over seven hundred years. GCHQ's historian is, in some sense, a griot for the intelligence community. But the griot tradition also teaches a harder lesson: the knowledge survives only as long as the succession is unbroken, the keeper is trusted, and the political conditions allow honest remembering. When any of those conditions fail, the memory warps or dies.
Here is the problem: GCHQ is one organisation. The UK has 400-plus local councils, thousands of NHS trusts, hundreds of government agencies. The model of the dedicated organisational historian is magnificent. It may also be fundamentally unscalable.
Brent as a Service
This is where the AI vendors arrive, breathless with excitement. The pitch goes like this: what if you could digitise Brent? What if you could capture every piece of institutional knowledge ā every email, every Slack message, every incident report, every design decision ā and feed it into a retrieval-augmented generation system that could answer any question anyone in the organisation ever had? Brent as a Service. The colleague who never forgets, never sleeps, never retires, never gets hit by a bus.
The pitch is seductive. And parts of it are real. Knowledge workers currently waste 8.2 hours per week finding, recreating, or duplicating information that already exists somewhere in the organisation. RAG-based systems can, in principle, solve the "nobody updates the wiki" problem that killed the first wave of knowledge management in the 1990s. Tom Davenport diagnosed the failure bluntly: "Everything devolved to technology. KM is a complex idea, but most organisations just wanted to put in a system." The wikis went unupdated. Google killed internal KM by making external search so good that nobody bothered curating internal knowledge.
AI-powered institutional memory promises to solve this through passive capture. You do not ask people to write things down. The system listens, indexes, synthesises. It surfaces patterns that humans miss. It scales beyond what any single historian could achieve.
I want to believe this. I genuinely do.
And I should be honest: for certain categories of institutional knowledge, AI memory systems already work. Technical documentation retrieval across large codebases, code archaeology through decades of commits, onboarding acceleration for standard operational procedures, system dependency mapping ā these are real, bounded, valuable applications. Enterprise search is a commodity. Document-based RAG is becoming a reliable product. If all you need is an answer to "where is the configuration for the batch job on server four," a well-built RAG system will give you one.
But institutional memory is not documentation retrieval. The knowledge that matters most ā why a decision was made, which experiments failed, who objected and why, what the political context was, what the thing actually does versus what it was supposed to do ā lives in a different category entirely. That knowledge is tacit, politically sensitive, and often embarrassing. And that category is where the problems begin.
The Poisoned Well
Here is what the vendors leave out.
The risks of AI institutional memory are not one thing. They are three distinct things, and conflating them ā as the industry habitually does ā makes all of them harder to address.
The first is a data integrity problem. An AI that remembers everything can be made to remember things that never happened. Researchers at USENIX Security demonstrated with PoisonedRAG that injecting just five malicious texts per question into a knowledge database of millions achieves a 90% attack success rate under laboratory conditions. Real-world deployments with access controls and retrieval filtering would reduce that figure, though by how much remains an open research question. Five documents. In a corpus of millions. A competitor, a disgruntled employee, a state actor ā any of them could inject a handful of carefully crafted documents into your knowledge base and corrupt the answers your organisation gets back. Your AI "remembers" things that never happened. Your AI recommends approaches that were designed to fail. NIST has developed formal taxonomies for this class of attack, and Anthropic's own researchers demonstrated with their Sleeper Agents paper that backdoor behaviours can persist through standard safety training ā with larger models proving better at hiding deception. Subsequent research on detecting sleeper agents through probes is promising, but early. The knowledge base itself cannot be trusted to be honest.
The second is a behavioural problem. An AI that remembers everything is also a surveillance system. And the moment people know they are being watched ā that every Slack message, every candid post-mortem, every "I think we got this wrong" is being captured and indexed ā they stop being honest. This is not speculation. This is Amy Edmondson's research, dating back to 1999, replicated hundreds of times since. Only 1-4% of failures in organisations are truly blameworthy. Yet 70-90% are treated as such. People learn to hide mistakes. They learn not to report near-misses. They learn to cover their tracks. A 2024 study from Cornell's ILR School found that AI-monitored employees generate fewer ideas, though it is worth noting that study measured productivity monitoring rather than knowledge capture specifically ā the chilling effect on institutional memory systems is an extrapolation, not a proven equivalence. But the direction of the evidence is clear, and if anything, a system that captures the content of what you say is more intimate than one that merely monitors how fast you type.
I will name the paradox plainly: the more comprehensive your memory system, the greater the risk that honesty is suppressed. But the chilling effect is not uniform. People will speak honestly about system configurations into a machine that records everything. They will not speak honestly about political decisions, leadership failures, or their own mistakes. The sensitivity of the knowledge determines whether the memory system captures truth or performance. And most organisations do not have the psychological safety culture to withstand that risk. You build the perfect institutional memory and fill it with sanitised half-truths because nobody dares speak candidly into a system that remembers everything. Astro Teller at Google X understood the inverse of this when he created a culture that gave bonuses and promotions for killing projects ā for proving that an idea would not work. The psychological safety required to report failure honestly is the precondition for institutional memory worth preserving. A system that undermines that precondition undermines itself.
The third is a lock-in and opportunity risk problem. The more institutional knowledge you pour into a single provider's AI memory system, the heavier the gravity around that incumbent becomes. Every document indexed, every integration built, every workflow that depends on the system's answers ā each one raises the cost of switching. And the cost of switching is the cost of being stuck when something better arrives. The AI landscape is moving fast. A provider that is best-in-class today may be a legacy choice in eighteen months. An alternative may emerge that is faster, cheaper, more transparent about its model provenance, or better suited to your regulatory environment. But if your entire institutional memory is embedded in one vendor's platform, the switching cost may be so high that you stay ā not because the incumbent is still the best option, but because the gravity is too strong to escape. That gravity can be genuine (the sheer volume of indexed knowledge, the retraining cost, the integration surface area) or artificial (proprietary formats, contractual lock-in, opaque export mechanisms). Either way, the organisation that was trying to solve a knowledge dependency on one person has created a knowledge dependency on one provider. The NCSC has published guidelines for secure AI system development and the UK government's AI Playbook both acknowledge the complexity. But acknowledging complexity and solving it are different things. Model provenance ā knowing where your model came from, what it was trained on, who had access to its weights ā is not a nice-to-have. It is a minimum requirement. Anthropic's own disclosure about disrupting the first AI-orchestrated espionage campaign tells you that this is not paranoia. It is operational reality.
These three risks ā corrupted data, suppressed honesty, vendor gravity ā are independent of one another. You could solve one completely and still face the other two. That is what makes AI institutional memory a genuinely hard problem rather than a configuration exercise.
The Forgetting That Is Not Accidental
There is something else the piece needs to say, and I have been putting it off.
Not all institutional amnesia is accidental. A new leader who wants to change direction benefits from the previous administration's memory being lost. A new CTO who wants to replace a legacy platform benefits from nobody remembering why the last migration failed. Institutional forgetting is sometimes a feature, not a bug ā a political choice dressed up as organisational entropy. The Cambridge Centre for Science and Policy has documented the structural factors driving institutional memory decline in UK government ā civil service churn, machinery-of-government changes, the loss of specialist roles ā but some of those factors are not accidental. They are the consequence of a system that treats institutional knowledge as overhead rather than infrastructure, and sometimes as an inconvenience to be shed. And if you map the incentives, nearly every player in the system ā the incoming leader who wants a clean slate, the consultancy that profits from rediscovery, the vendor who wants to sell you a replacement ā benefits from the forgetting. The people who lose are the ones who have to build the submarine.
And there is a further irony: the consultancies called in to diagnose institutional memory loss are often the same firms whose restructuring advice caused the loss in the first place. The cycle is not accidental. It is a business model.
AI will not fix a culture that treats institutional knowledge as disposable. And it certainly will not fix a culture that sometimes wants to forget.
What This Means for You
I had a conversation last year with a retiring principal engineer at a government department I cannot name. Twenty-six years in. Knew every integration point, every workaround, every reason why the Thursday batch run had a forty-minute delay that nobody had ever fixed. I asked him what would happen when he left. He laughed. "They'll find out," he said. "Probably on a Thursday."
That man was a Brent.
If you have read this far, you are probably someone who has felt this problem ā who has watched knowledge leave and wondered what could have been done. What you do about it depends on where you sit and how much time you have. But before the advice, a distinction the piece has been building towards without naming.
Not all institutional knowledge is the same, and the strategy for preserving each type is completely different. Operational knowledge ā procedures, configurations, system dependencies ā is commodity. AI handles it now. Deploy it. Craft knowledge ā the tacit expertise of the twenty-six-year engineer, the Thursday batch job, the adjustments never written in any manual ā is custom-built. It must be captured through structured interviewing, pair working, and deliberate succession before the people leave. No AI system captures it passively. Political knowledge ā why a decision was made, who blocked it, what the real objections were ā is the most fragile and the most valuable. It requires psychological safety to speak and human trust to preserve. Automate its capture and you guarantee its corruption.
If you are bleeding knowledge now ā if your Brents are retiring this quarter, if the COBOL developers are leaving, if the institutional memory is walking out the door ā you do not have the luxury of building psychological safety first and deploying AI memory second. You need to do both in parallel, imperfectly, knowing that the AI system you deploy today will capture operational knowledge well, craft knowledge partially, and political knowledge barely at all ā and that is a trade-off you are making with your eyes open. Start with the bounded cases. Keep the sensitive knowledge where it belongs: in conversations between humans who trust each other. That is not a counsel of perfection. It is a triage decision for organisations that are bleeding knowledge now.
If you have more time ā if your teams are stable, if your Brents are not yet leaving, if you have the organisational patience to do this properly ā then the sequence matters. Build psychological safety first. Create the conditions in which people speak honestly about failure before you turn on the machine that listens. Here is a simple test: if your post-mortems are blame-free and your teams report near-misses voluntarily, you have the safety culture to deploy AI memory broadly. If your post-mortems are forensic exercises in fault-finding, start with operational knowledge and keep everything else in human conversations. Edmondson's work is clear. Google X's results are clear. The ICO's guidance on workplace monitoring is clear. Then and only then, deploy AI memory systems ā and start with the knowledge categories where the chilling effect matters least before you touch the categories where it matters most.
And regardless of where you sit: demand model provenance. This is not an argument for or against open weights, open training data, or any particular licensing model ā that is a different debate with its own complexities. But whether the model is open or closed, you have an obligation to understand where your AI systems come from, what they were trained on, and who controls them. The NCSC guidelines are a starting point. Treat them as a floor, not a ceiling. This is not optional.
There is a final thing, and it is the one nobody wants to hear. Some institutional memory cannot and should not be digitised. The griot tradition survived seven hundred years not because the Kouyate family had superior technology but because they had superior commitment. GCHQ's historian works not because the role is efficient but because it is valued. Some knowledge requires a human being who cares about it. If your organisation will not invest in people who carry its memory ā and I mean invest, with budget and status and a career path that does not dead-end ā then no AI system will compensate for that failure. And some of these problems are beyond what any single CTO or permanent secretary can deliver alone. The National Archives already serves as cross-departmental memory infrastructure for records. The question is what the equivalent looks like for living institutional knowledge ā the kind that does not sit in filing cabinets but in people's heads. That requires shared investment across departments, collective approaches to knowledge preservation, and institutional capacity that survives the next spending review. Individual action is necessary. It is not sufficient.
Technologies change. Human nature does not. The desire to remember, the fear of forgetting, the temptation to let a machine do the remembering for us ā these are as old as William's commissioners riding out across England with their quills and parchment. The question is not whether AI can serve as institutional memory. The question is whether we are wise enough to build it without corrupting the knowledge, suppressing the honesty, and locking the memory of how decisions were made into a system we cannot leave when something better arrives.
I suspect we will find out. Probably on a Thursday.
(Views in this article are my own.)