AI and the Collapse of Organisational Memory

Ask almost any technology organisation what it plans to do with AI, and knowledge retrieval will appear near the top of the list.

That makes sense. Most teams already have too much information in too many places. Meeting notes scattered across docs. architecture decisions half remembered. incident write‑ups nobody rereads. CMS quirks trapped in Slack threads. Product reasoning sitting inside somebody's head until they leave. The promise of AI is attractive because it appears to solve the mess in one move: index everything, summarise it quickly, and make it searchable through natural language.

There is real value in that.

There is also a dangerous misunderstanding buried inside it. Searchable knowledge is not the same thing as organisational memory. A summary is not the same thing as understanding. A retrieved note is not the same thing as knowing which parts of that note still matter, which parts were contested, and which quiet caveats lived only in the people who were there when the decision was made.

If organisations confuse documentation with memory, they risk building systems that look smarter whilst becoming easier to mislead. The result is not simply lost information. It is hallucinated continuity: a neat, searchable story about how the organisation works that starts drifting away from the lived reality of why it works that way.

Organisational Memory is Not Just the Wiki

The first thing worth stating plainly is that memory in organisations is distributed.

Some of it lives in documents. Some of it lives in habits. Some of it lives in social knowledge about who understands what. Some of it lives in the accumulated pattern recognition that lets an experienced engineer say "this looks normal but it probably is not".

Research on transactive memory systems is useful here because it treats collective memory not as one shared database, but as a social system in which people know, at least imperfectly, who knows what and how to coordinate around that expertise (see also further transactive memory research).

That is a much better fit for real engineering organisations than the simple "put it in the docs" model. Teams do not only store knowledge. They route through expertise.

AI retrieval systems are usually strongest on the storage side. They are much weaker on the routing side, especially when the relevant expertise is tacit, contested, or shaped by context that never made it into the record cleanly.

Decision Records are Not the Same as Decision Understanding

Architecture decision records, RFCs, postmortems, and planning docs are all useful. Many teams would benefit from having more of them and from keeping them in better order.

But even a strong record is only a frozen representation of a decision moment.

It may tell you that a team chose queue A over queue B, or vendor X over vendor Y, or a monorepo over a multi‑repo split. It often does not fully tell you:

• which rejected alternatives were only weakly rejected
• which constraints were temporary
• what political or staffing reality shaped the choice
• which assumptions were already looking fragile at the time
• whether the team still believes the trade‑off was right

That distinction matters because AI is excellent at retrieving the explicit rationale and much less reliable at reconstructing the tacit parts. A summary can give the impression that the decision is settled and self‑explanatory when in reality it was conditional, contested, or already partially obsolete.

Google's work on design reviews is useful here because it shows how much early design quality depends on structured discussion rather than only the final approved document. The artefact matters. The conversation that shaped it matters too.

Incident History is More than the Incident Report

The same issue appears even more sharply in operations.

Post‑incident documents are valuable because they capture facts, impact, root causes, and actions whilst the event is still fresh. They are one of the best tools a team has for building resilience across time. Google SRE's writing on postmortem culture makes that case clearly (see also Google SRE guidance).

But even a strong postmortem is not a drop‑in replacement for lived operational memory.

Experienced responders remember how the system felt before the failure became visible. They remember which dashboard was misleading, which escalation path worked badly, which "temporary" mitigation quietly became standard practice, and which lesson from an older incident should have changed the design but never fully did.

That kind of memory is partly written and partly embodied.

If a team reduces staffing or turnover breaks continuity, AI may still retrieve the old documents. It cannot guarantee that the next responder will understand what those documents meant to the people who wrote them.

Product History and Market History are Memory as Well

Engineering organisations often talk about memory as if it were mostly architectural or operational. Product and market memory matter just as much.

A team may have a decent record of technical decisions and still lose track of why a feature exists, which customer commitments shaped it, which partner dependency made it awkward, or which market‑specific edge case turned out to be commercially important even if it looked technically eccentric. Those histories are often fragmented across roadmap documents, sales escalations, analytics interpretations, contract constraints, and the recollections of a few long‑serving people.

If AI summarises the artefacts without enough of that surrounding context, it can produce an account of the product that is internally tidy and commercially misleading. A future team then optimises against the simplified story and quietly reintroduces problems that the organisation had already learned, painfully, to avoid.

Summaries Compress Away Dissent, Uncertainty, and Sequence

Summaries are useful precisely because they compress. The problem is that organisational understanding often depends on the parts compression removes.

A good summary usually strips repetition, side discussion, false starts, hedging, and digression. Those are sensible editorial choices. They are also the places where disagreement, uncertainty, and sequence often hide.

In delivery work, sequence matters more than teams admit. Knowing that the billing system, membership model, and analytics layer all changed in the same quarter often matters more than reading a clean summary of each change separately. Knowing that legal only approved a data flow after a particular mitigation was added matters more than seeing the final approved version alone. Knowing that a roadmap shift came after a failed launch or a partner escalation changes how you interpret the resulting decision.

Communication research around transactive memory systems reinforces this point. Teams do not build shared memory only by storing information. They build it through communication patterns that clarify expertise, allocation, and coordination.

An AI summary may preserve the output of that process whilst removing parts of the process that made the output intelligible.

The Risk is Not Only Missing Context. It is Hallucinated Continuity

The more interesting risk is not that retrieval systems fail to answer. It is that they answer too smoothly.

An organisation with patchy records and weak continuity can still get plausible summaries from a capable model. That plausibility is dangerous because it creates a sense of coherence the underlying knowledge base may not deserve.

Acemoglu, Kong, and Ozdaglar's AI, Human Cognition and Knowledge Collapse is relevant here even though it operates at a broader level. Their model highlights a dynamic tension where AI can improve immediate decision quality whilst also eroding the learning incentives that sustain longer‑term collective knowledge.

That is close to the organisational‑memory problem. If teams rely more on AI retrieval and less on human reconstruction, explanation, and debate, then the stock of living knowledge can decay even whilst the surface accessibility of information improves.

The result is a company that becomes better at looking things up and worse at understanding what it knows.

Knowledge Management and Judgement are Not Interchangeable

This is why strong documentation programmes still need strong people systems.

Good knowledge management reduces waste. It makes important decisions visible, reduces repeated explanation, and helps new people orient themselves faster. It is extremely valuable. It does not eliminate the need for judgement or expert interpretation.

The same is true for AI. A retrieval layer can save time finding relevant information. It cannot safely decide, on its own, how much weight an old decision still deserves, whether a postmortem action item was actually completed in spirit, or whether the summary it has assembled hides a contradiction between two historical accounts.

That is also why documentation work should not be treated as a substitute for retention. If the people who understand the architecture, incidents, and product history leave, the organisation loses more than paragraphs. It loses interpretive capability.

That point connects directly with Documentation as a Force Multiplier for Senior Engineers. Documentation is powerful because it helps senior judgement scale. It is not a machine for making judgement unnecessary.

Retention is Part of Knowledge Architecture

This is why organisational memory cannot be handled only through documentation tooling. Staff continuity is part of the memory system.

If people with critical context leave too quickly, the company loses not only facts but also the ability to interpret those facts, to resolve contradictions between sources, and to explain what changed between one decision context and the next. AI can reduce retrieval cost for what remains. It cannot recreate the missing layer of lived interpretation from scratch.

For engineering leaders, that means retention, succession overlap, and deliberate transfer of context in critical domains should be treated as architecture concerns as much as people concerns. A system is easier to change when the organisation still remembers why it looks the way it does.

That is also why succession rehearsal matters. A team only really discovers which context is still tacit when somebody else tries to operate without the usual expert present.

Planned leave, incident rotation, and temporary ownership swaps can all reveal where the memory system is still relying too heavily on one person. That sort of rehearsal is often more informative than another documentation push, because it shows which explanations actually travel and which ones only feel clear to the people who already know the story.

Retrieval Systems Should Expose Uncertainty, Not Hide It

There is also a practical design implication for AI knowledge tools themselves.

If a retrieval layer presents old decisions as clean, authoritative answers without showing source age, conflicting records, named owners, or adjacent discussion, it encourages overconfidence. Better systems should make provenance visible, surface uncertainty, and point users back towards the people or documents most likely to hold the still‑relevant context. In other words, the tool should help the organisation navigate its memory, not pretend to have replaced it.

That design choice sounds small, but it changes behaviour. A system that exposes ambiguity teaches teams to investigate. A system that hides ambiguity teaches teams to trust summaries too quickly.

How Engineering Leaders Should Preserve Memory Properly

If you want AI‑enabled retrieval without organisational amnesia, the answer is not to reject the tools. It is to be much clearer about what the tools are and are not preserving.

A practical approach usually includes:

• Write decision records, but also record the constraints, unresolved doubts, and expiry conditions around them.
• Treat postmortems as shared learning artefacts, not compliance paperwork.
• Keep architecture reviews and incident reviews connected to named owners who can still explain the reasoning later.
• Preserve continuity in critical areas through retention, overlap, shadowing, and intentional succession.
• Use AI summaries as entry points into context, not as final authority.
• Build repositories of knowledge that make sequence visible, not only isolated documents.
• Reward people who improve shared understanding, not only those who keep private expertise in their heads.

This is also where broader architecture and delivery discipline matters. Building for Change: Architecture Lessons from Multi‑Phase Replatforms is ultimately about the same problem in another form. If knowledge about why the system is shaped the way it is becomes too thin, future change becomes slower, riskier, and easier to misjudge.

Conclusion

AI can make knowledge retrieval much better. It can surface old decisions faster, synthesise long documents, and reduce the cost of finding relevant material in a large estate. That is real and useful.

But retrieval is not memory, and memory is not judgement.

Organisational memory lives partly in records and partly in people who know how to interpret those records in context. If a company treats summaries as a replacement for that living context, it may get cleaner answers whilst losing a great deal of understanding.

That is the collapse to watch for. Not whether the wiki became searchable, but whether the organisation still knows enough, in human terms, to understand what the search result actually means.