Every organization I’ve worked in has the same problem. It keeps everything and remembers very little.

A decision gets made in a meeting. A requirement gets settled in chat. A problem gets solved in a ticket. Months later all of those artifacts still exist, and nobody can tell you why the decision went the way it did, what alternatives were ruled out, or which risks were knowingly accepted. The information survived. The understanding didn’t.

I see this most clearly in my own work. I onboard acquired companies: migrating their infrastructure, transitioning their systems, handing operations over to the teams who will run them. Each one is a months-long project with dozens of decisions, hundreds of conversations, and people rotating in and out. By the end, the team has become historians of its own work, piecing together a story from tickets, emails and meeting notes.

That’s the problem worth solving. What follows is what I’ve learned trying to solve it, including the part that didn’t work.

We have tried this before

Organizational memory isn’t a new idea. Knowledge management was a major enterprise push in the 1990s, and most of it failed for one simple reason: keeping the record current was a second job. People did the work, and then they were supposed to write it up. They didn’t, or they did it once and stopped. Wikis rotted. Lessons-learned documents were written at the end of a project and never opened again. The few practices that survived, like architecture decision records, survived only where a team had unusual discipline.

So when someone says “the next enterprise platform is organizational memory,” the fair response is: we built that, and nobody maintained it.

What is different now

The first wave of enterprise AI was search: connect the data, index it, answer questions. The second was reasoning: summarize the meeting, draft the report. Both are useful, and both only read the record. They make it easier to find and use what someone else took the trouble to write down. Neither does anything about the fact that nobody writes it down.

What’s changed is that an AI can now do the upkeep. It can take a meeting transcript, a ticket update or a chat thread and write the entry back into the record while the work is happening, as a byproduct instead of an extra chore. That is the step knowledge management never had. An assistant answers when asked. A system that writes back keeps the record without being asked.

I know this works, because I’ve been running a version of it for myself.

What I built, and what it taught me

For most of this year I’ve kept every acquisition project in a personal knowledge base, maintained with an AI assistant. It logs work, keeps the ticket list, drafts handover documents, and holds the facts: hostnames, addresses, network segments, service accounts.

Some of it paid off immediately. On one project, I found the server’s current address written out ten times across a single project note, alongside nine copies of the address it had before the migration: the exact value most likely to be pasted into a firewall request by mistake. Scattered copies can’t be audited. We moved every canonical value into a single facts note that everything else references, and the next time I filed a server build request, the values I needed were in one place instead of hunted down across hundreds of lines.

Then it failed, in a way that I think matters more than the success.

Over less than two weeks, I made sixteen corrections to notes the assistant had written, and nearly all of them were the same error in different clothes: thin evidence published as a confident conclusion.

  • It counted four ticket close dates, saw a shape, and wrote it up as a trend. The shape was noise. That summary was rewritten three times, and each rewrite made the same mistake.
  • A user’s remote session kept timing out. The assistant produced a diagnosis, the diagnosis produced an escalation to a network engineer, and the note went through five corrections. The actual cause was a typo in the address the user had typed.
  • A search for “No” in a column labeled “stored in the vault?” turned into a report of exposed credentials. The file was an empty template that had never held a credential.

None of these were caught by the system. I caught them because I read what it wrote.

This is the risk the optimistic version of organizational memory leaves out. A system that writes the story can write the wrong story, and the wrong story reads exactly as authoritatively as the right one. Once it’s in the record it becomes the official version, and the next person has no way to tell it apart from a fact. An organization that forgets is inefficient. An organization that confidently remembers things that aren’t true is worse.

Designing memory you can trust

The fix isn’t to stop the system from writing. Write-back is the whole point. The fix is to be precise about what it writes and what has to happen before a claim counts as true. Here are the rules I’ve arrived at, each written after something went wrong:

Keep evidence and story separate. The evidence layer is ticket text, log entries, transcripts, what someone actually said. It is dated, it quotes its source, and it’s only ever added to. The story, meaning the summary of where things stand and why, is built from the evidence and can always be rebuilt from it. When they disagree, the evidence wins.

Let the system write evidence freely, and propose everything else. A log entry that says “ticket moved to Work in Progress on 09/12” is low risk to automate. A statement that “we decided to keep the storage account” is a conclusion. The system proposes it, with its source attached, and it becomes a fact only when the person who owns that area confirms it. The system is accountable for capturing and flagging. A named human is accountable for what’s true.

Label how certain every claim is. Observed, stated by a person, inferred, hypothesis. An inference should never be phrased like a fact. A pattern match is a question, not a finding.

Record where every claim came from. Who said it, when, from what. A claim with no source gets flagged, not trusted.

Never overwrite. A new value marks the old one as former. A correction states what was wrong and leaves the original readable. The correction log is itself part of the memory, and often the most useful part.

Let facts expire. A value confirmed once is not a validated pattern. Date it, and check it again.

Show contradictions instead of settling them. When two sources disagree, show both. Quietly picking one is how a confident wrong story gets started.

The honest trade

None of this removes the human. It moves the work from writing the record to checking it. That’s the real reason this can succeed where knowledge management failed: reviewing a proposed entry takes a fraction of the effort of writing one from scratch.

It also introduces a new way to fail. A team that approves proposals without reading them ends up with confident fiction carrying a sign-off, which is worse than no memory at all because it looks official. The number I’d watch is the correction rate: how often proposed changes are rejected or edited. If it trends toward zero, either the system has become very good or nobody is reading anymore, and you need to know which.

Why it can’t depend on one person

My own system has an obvious flaw: it depends on me. The conventions live in my notes and my habits, the data lives in my account, and I’m the one reviewing. If I leave, it goes with me, which is exactly the institutional amnesia it was meant to prevent.

The part worth keeping isn’t my tooling. It’s the method: evidence and story kept apart, facts recorded once, sources on every claim, a person confirming before a guess becomes a fact, and corrections left visible. None of that is specific to acquisitions. Facilities teams, software teams and operations teams all generate context continuously and lose it continuously. The method can be written as a template that each team runs on its own, with its own owners and its own data, so that no single person or team becomes the new point of failure.

The pieces to build it already sit in the software most enterprises license: agents that can act rather than just answer, workflow tools with approval steps, and lists and documents with version history. I’m starting with a pilot on one acquisition with a couple of teammates, because one person’s success is an observation, not a rule. If the method holds up for a team, expanding it is an easy case to make.

Memory you can audit

It’s tempting to describe the future of enterprise AI in three generations: search, then reasoning, then memory. I’d add a qualifier. Memory alone isn’t the goal. Plenty of organizations already have more stored information than they can use. The goal is memory that can show where each claim came from, how certain it is, and who confirmed it.

AI can finally keep the record without making people do a second job. Whether that record is worth anything depends entirely on whether we can trust it, and trust has to be designed in from the start.