Institutional Memory

The engineer who understood the payments reconciliation job better than anyone else gives two weeks’ notice on a Tuesday. Nobody on the team is alarmed. The code is there, the tests pass, the runbook was updated last quarter. What is missing does not announce itself until an incident three months later: the reasoning. Why the retry logic waits four seconds and not two. Why one currency gets special-cased. Why an earlier, cleaner version of the job was tried and abandoned for the messier one still running in production. None of that was ever written down anywhere a person could search.

A good share of that reasoning, for the last year, lived inside AI coding sessions — worked out loud, decision by decision, in exchanges with an agent that nobody thought to keep, because the code that came out the other end looked, at the time, like the only thing worth keeping. This is a familiar failure with an unfamiliar amount of material behind it. Engineering organizations have known for decades that knowledge concentrated in one person is a risk. What is new is how much knowledge a single person can now generate and discard in an afternoon, at a pace no code review or design doc ever had to keep up with before.

This Library’s previous chapter argued that code depreciates the moment it ships while the understanding behind it keeps paying out for as long as anyone can retrieve it — and that making code cheap to regenerate makes retrieval, not generation, the scarce resource. Institutional memory is that same argument applied to an organization instead of a single codebase: the question is not whether a team’s code still works after someone leaves, but whether the understanding that produced it is still reachable by whoever is left holding it.

A risk with a number attached

Software engineering gave this risk a name well before agentic coding existed: the bus factor, or truck factor — the minimum number of people who would need to become unavailable, colloquially by being hit by a bus, before a project stalls for lack of anyone who understands it. The term circulated informally in the field for years before researchers started measuring it directly. Guilherme Avelino and colleagues built an automated estimator and ran it against 133 popular GitHub projects, then validated the results by surveying the developers themselves. Their finding, published in 2016: 65% of the systems studied had a truck factor of two or fewer. Two departures, in the median well-known open-source project, is enough to stall it.

A separate line of research complicates the picture usefully rather than resolving it. Surveying 269 engineers directly, Elgun Jabrayilzade and colleagues found that developers do treat bus factor as a real, felt concern — but that the knowledge keeping a project alive rarely lives only in commit history. Code review comments and team meetings carry a meaningful share of it too, which matters here for an uncomfortable reason: those are exactly the channels a developer working mostly with an AI agent tends to have least of. There may be no reviewer reading the reasoning at all, and no meeting where it got said out loud to a second person — only a session transcript, and an agent that has no memory of the conversation once it ends.

Both studies measure knowledge the way it has traditionally been stored: in commits, in review threads, in who showed up to which meeting. An automated bus-factor tool built on Git history — Valerio Cosentino and colleagues published one of the first, in 2015, scoring every file, directory, and branch in a repository — is blind to a channel that barely existed when either paper was written: the AI session itself, where an engineer can work through a decision at length with an agent and never write a single line of that reasoning into a commit message, a comment, or a ticket. The concentration risk these tools were built to measure may already be moving somewhere they cannot see it.

The two-sided risk

This is where AI-assisted engineering genuinely changes the calculation, and it changes it in two directions that point at each other. If a session’s reasoning is captured as durable, queryable Decision Memory — this Library’s term, established earlier, for the practice of persisting what an agent decided and why rather than only what it changed — a departure is measurably less catastrophic than the classic case, because the reasoning no longer depends on the person who produced it remaining reachable. The knowledge outlives the employee. That is the optimistic direction, and it is not hypothetical; it is exactly what the mechanism exists to do.

The other direction is less comfortable. A team that runs its work through AI agents without ever building that capture layer is not simply repeating the old bus-factor risk at the old rate. It may be accumulating tacit knowledge faster than any purely human team ever could, because sessions happen faster, more of them run per day, and the overwhelming majority leave no trace beyond a diff once the transcript scrolls out of view. Throughput looks higher on every dashboard that measures output. Institutional memory per unit of work produced is quietly lower, hidden behind a number that only counts what shipped. It is a higher bus-factor risk wearing the appearance of more work getting done — the number of people who could disappear tomorrow and take irreplaceable understanding with them may be rising precisely because the team ships more, not despite it.

The risk is not confined to people who eventually leave, either. Anthropic’s own randomized trial on AI-assisted learning, published in early 2026, found engineers who delegated a coding task to an AI assistant scored substantially lower on a follow-up comprehension quiz than engineers who wrote the equivalent code by hand — 50% versus 67%, roughly two letter grades. The gap narrowed sharply for engineers who used the assistant to ask questions and request explanations rather than simply produce code. Passive delegation does not just fail to write knowledge down anywhere durable. It can leave less of it in the one head that was actually in the room while it happened.

Fifty percent versus sixty-seven percent. The gap wasn’t in the code. It was in what stayed in the room after the code was done.

On Anthropic’s 2026 skill-formation trial

What gets forgotten

Three specific things go missing, over and over, in ways a postmortem can usually point at without ever naming precisely enough to fix.

The first is why, as distinct from what. Version control keeps the what forever; a diff is permanent the moment it merges. The reasoning behind it is not stored anywhere by default — it has to be deliberately captured, or it evaporates the moment the session that produced it ends. This volume’s next chapter, Decision Archives, is about building that capture at organizational scale rather than leaving it to whoever happens to still remember; it is worth naming here only as the shape of the gap, not solving it.

The second is what was tried and rejected. A team that has forgotten a rejected approach does not just lose a fact — it re-spends the exact effort that already ruled the approach out, often with the same result, sometimes months apart, occasionally with the same engineer proposing the idea they themselves abandoned the first time. This Library’s chapter on workflow recovery names the mechanism built for the adjacent problem: continuation, a new session deliberately informed by what a prior, abandoned attempt already learned rather than starting from a blank page. The discipline that makes continuation work for one session is the same discipline institutional memory needs at the scale of a team’s whole history.

The third is domain knowledge that only ever lived in one person’s head — a specific billing rule, a regulatory constraint nobody wrote into a ticket, a hard-won understanding of why the obviously simpler approach does not actually work here. This is the hardest of the three to notice missing, because nothing about the code announces that a constraint used to be enforced by a person’s memory rather than by a rule anyone could check. This Library’s chapter on organizational systems already covers what it takes for an organization to notice a repeating pattern like this before it costs something a second time — the same structural habit of treating memory as infrastructure rather than folklore applies here without needing to be re-derived.

What survives without being asked

A short way to check which of the three a team is actually protected against — not whether the team feels careful, but whether the knowledge would survive being asked for by someone who was never in the room.

What capture would need to show

What this means before anyone leaves

None of this requires abandoning AI-assisted work, or slowing it down to match the pace at which people used to write things down by hand. It requires deciding that the record of why is not an optional artifact of a session, produced only if someone remembers to produce it, but part of what the session actually output — as real as the diff, and considerably harder to regenerate once it is gone. The next chapter in this volume takes that requirement and builds the infrastructure for it at the scale of an organization’s full history, not just one session’s.