Every organization has a secret second brain. It lives in Slack DMs, in hallway conversations that were never minuted, and inside the head of the person who's been there longest. The day that person walks out the door, the brain goes with them. And everyone else spends six months rediscovering things the organization already knew.
That's the thing, isn't it? You don't feel the loss immediately. You feel it three months later when someone asks why a particular vendor was chosen in twenty nineteen and nobody can remember the constraint that made the other options impossible.
Daniel sent us this one. He's been the person tasked with informal knowledge management — the side gig nobody asked for but everyone needs — and he's asking three things. First, what do we actually mean in concrete terms when we talk about institutional memory? Second, if you were the hypothetical knowledge manager charged with extracting what's in people's heads, how much of that is valuable and how would you even go about gathering it? And third, what's the real role of AI now that wikis are integrating it as a core feature — is it curation, is it mining, is it something else?
The timing on this is interesting. The AI tools that can ingest, index, and answer questions from internal knowledge bases have gone from experimental to genuinely production-ready in the last eighteen months. Notion AI, Confluence AI, Guru — they're all shipping retrieval-augmented generation under the hood. But most companies are still treating knowledge management like it's the office recycling program. Someone's got the title, nobody's got the time.
So the tools are suddenly capable of surfacing knowledge in ways that were science fiction five years ago, and the actual knowledge they're supposed to surface is still sitting in people's heads or rotting in a wiki nobody's touched since the Obama administration.
That's the tension. And it's not a small one, because the cost of getting this wrong isn't just inconvenience. It's repeated mistakes, slower onboarding, decisions made without context. Organizations are paying a tax on everything they forgot they knew.
Where do we even start with this? What do we actually mean when we say institutional memory? Let's get concrete.
The Wikipedia definition is actually a good starting point here. Organizational memory is, quote, the accumulated body of data, information, and knowledge created in the course of an organization's existence that can be brought to bear on present decisions. That last phrase is the one that matters — brought to bear on present decisions. It's not an archive, it's a resource you're supposed to use.
It's not the minutes from the 2014 holiday party. It's the stuff that would change what you do today if you knew it.
And here's where the distinction that actually matters comes in. There's explicit knowledge — your documented processes, your SOPs, your onboarding checklists. The stuff someone wrote down. And then there's tacit knowledge. Who to ask when the official process doesn't apply. The Harvard Business Review piece on preserving institutional knowledge from 2013 — and this is still painfully relevant — emphasizes that the most valuable knowledge is almost always the least documented. Unwritten rules, informal networks, the thing everyone knows but nobody wrote down.
The thing everyone knows but nobody wrote down. That's the whole problem in six words.
It's what vanishes when a senior engineer leaves without a proper handoff. You don't lose the documented API specs. Those are in the wiki. You lose the conversation where they explain why they chose that database over the other one, what constraint made the elegant solution impossible, which customer interaction killed a feature that looked great on paper.
I've seen this in practice. Not in software, but in organizations generally. Someone leaves and suddenly nobody knows why a particular supplier relationship exists, or why a process has a weird step that seems unnecessary. And someone new comes in, removes the weird step, and breaks everything.
That's the decision context. Institutional memory, concretely, is the why behind the what. It's not just knowing that vendor A was chosen — it's knowing that vendor B had a security vulnerability in twenty seventeen that made them untouchable, and vendor C's support team was unresponsive during a critical outage, and the person who made that call had those facts in their head for nine years and never wrote them down.
When Daniel asks what we mean in concrete terms, the answer is: institutional memory is the set of things you'd need to tell a smart replacement on their first day for them to not repeat the mistakes you already made.
The HBR article frames this through something they call knowledge audits. The idea is you systematically identify what critical knowledge exists, where it lives, and how at risk it is. But the uncomfortable finding, even back in 2013, was that most organizations only do this after a key departure. It's reactive. The knowledge walks out the door first, and then someone says we should probably have written some of that down.
Which is the organizational equivalent of starting your estate planning at the funeral.
A bit morbid, but yes. And it points to why tacit knowledge is both more valuable and harder to capture. Explicit knowledge you can assign someone to document. Tacit knowledge requires someone to recognize they even have it, which is its own problem. The people who've been somewhere longest often don't realize what they know that isn't obvious. It's just how things work to them.
The water the fish doesn't see.
So you've got this asymmetry. The knowledge that would be most useful to capture is the knowledge least likely to be voluntarily offered, because the people who hold it don't know it's special. And the cost of losing it is measured in decisions made without context — which is the kind of cost that doesn't show up on a balance sheet until much later.
With that distinction in mind — explicit versus tacit, the water the fish doesn't see — let's talk about the actual job. You're the knowledge manager. Someone's handed you this title, probably alongside your real job, and told you to capture what's in people's heads. Where do you even start?
You start by recognizing you've been handed an impossible job with no authority and no time budget. The HBR article is blunt about this. The most knowledgeable people are the least likely to have time to write things down. They're the ones putting out fires, shipping features, closing deals. Documentation is what happens when the fire is out — and the fire is never out.
There's no reward structure for it. Nobody gets promoted because they wrote excellent wiki pages. You get promoted for visible output. Documentation is invisible until it's missing.
That's the knowledge manager's dilemma in a nutshell. You're asking busy people to do unrewarded work that only proves its value after they leave. It's like asking someone to write their own eulogy, except the eulogy is about database schema decisions.
A compelling pitch. Please spend your Friday afternoon documenting things so that your replacement won't suffer.
Yet the HBR piece lays out mechanisms that actually work, and they're not theoretical. Structured exit interviews, after-action reviews within forty-eight hours of a project milestone, and knowledge audits. The problem is almost nobody does them systematically. They're the kind of thing an organization implements for two quarters after a painful departure, then quietly drops.
The forty-eight hour thing is interesting. Why that window?
Because details decay fast. After a project wraps, everyone's still got the context loaded in their head — why a decision went a certain way, what almost went wrong, which assumptions turned out to be wrong. Wait a month and those details have been overwritten by the next project. The HBR recommendation is essentially: debrief while the mental RAM is still allocated.
If I'm the knowledge manager, and I've accepted that I can't get people to write documentation, what do I actually do? What are the practical strategies that don't require people to suddenly become writers?
Three things that I think actually work. First, asynchronous capture with lightweight templates. Don't ask people to write a document. Ask them one question: what would you tell your replacement? Give them a template that's basically a text box and a submit button. Five minutes, not five hours.
That's smart. Lower the barrier to the point where the friction isn't the writing, it's just remembering to do it.
Second, record and transcribe team meetings. Not the whole meeting — but the parts where decisions get made. If you've got a tool that can automatically extract decisions and action items from a transcript, you've just documented institutional memory as a byproduct of work people were already doing.
Which means the knowledge manager's job shifts from creating documentation to harvesting it.
And third, this is my favorite — the wiki garden approach. The idea is anyone can plant a stub. A title and one sentence. That's it. You don't need a complete, polished document to publish something. Other people water it over time. Someone adds a paragraph, someone else adds a caveat, someone links to a related page. The page grows organically.
This is the opposite of how most corporate wikis work. The default is what, the cathedral approach? You need a complete, reviewed, approved document before anything goes live.
That's why most wikis are graveyards. The barrier to contribution is so high that nothing gets written, or things get written once during a big push and never updated. The Wikipedia research on organizational memory is clear about this — memory decays without rehearsal and revision. It's not a storage problem, it's a maintenance problem.
A wiki with ten thousand pages and no curator is less useful than a wiki with two hundred well-maintained pages.
Most organizations have the ten thousand page version. Pages created during someone's onboarding push in twenty eighteen, never touched again, still describing a process that changed three reorgs ago. The person assigned to knowledge management has another full-time job, so curation doesn't happen. The wiki rots.
I want to go back to exit interviews, because I think there's a specific failure mode here that's worth naming. The standard corporate exit interview is HR-processed into blandness. The departing employee has already checked out mentally. They're giving safe answers because they don't want to burn bridges. Nothing useful gets captured.
The alternative that some organizations are trying — and I think this is much better — is having the departing person record a fifteen-minute video in their last week. Not an interview. Just them talking to the camera, answering one prompt: what I wish I'd known when I started. Then you transcribe it, index it, and it lives in the wiki. It's raw, it's personal, and it captures the tacit stuff that never makes it into a handoff document.
The stuff they'd tell a friend over drinks, not the stuff they'd put in a formal memo.
That's the stuff that's actually valuable. The formal memo says the project was completed on schedule. The video says we almost lost two weeks to a licensing issue with a vendor who'd changed their terms without telling anyone, and here's who finally fixed it.
We've got capture strategies that work — lightweight templates, meeting transcripts, wiki gardens, exit videos. But they all require something that most organizations don't have: someone whose actual job includes making sure this happens. Not as a side responsibility. Not as a stretch goal. As the thing they're evaluated on.
That's the real failure pattern. It's not that the strategies are hard. It's that knowledge management is treated as a nice-to-have until the moment it becomes a crisis, and by then the knowledge is already gone.
Capture is hard, and wikis rot. And now we need to talk about AI — but not as the savior you might think.
I was waiting for the AI shoe to drop. Daniel's third question.
Here's what's actually changed. The last eighteen months have seen retrieval-augmented generation — RAG — become the standard architecture under the hood of every major wiki platform. Notion AI, Confluence AI, Guru — they all work the same way. You ask a question in natural language, the system retrieves relevant chunks from your internal corpus, feeds those chunks as context to the LLM, and synthesizes an answer grounded in your actual documents.
Instead of navigating a wiki hierarchy, clicking through pages hoping you land on the right one, you just ask "why did we choose this vendor" and it gives you an answer with citations.
That changes the economics of knowledge management entirely. The old bottleneck was finding knowledge. You knew it was probably in the wiki somewhere, but finding it meant knowing the right search terms, the right page titles, the right category structure. RAG collapses that. The finding becomes trivial.
Which sounds like the problem is solved.
This is where it gets uncomfortable. RAG has a dirty secret. If your wiki is full of outdated process docs, conflicting information, and orphaned pages from three reorgs ago, the AI will confidently pull from that garbage and produce an answer that sounds authoritative and is completely wrong.
Garbage in, garbage out — but amplified.
Amplified and dressed up in the confident tone of an LLM. A broken link on a wiki page is obvious. You click it, nothing loads, you know the information is missing. But a RAG system retrieving from a stale page about your deployment process will synthesize a perfectly fluent, step-by-step answer that's two years out of date, and nothing in the output signals that it's wrong. The curation problem doesn't go away. It becomes more acute, because bad knowledge is now surfaced more efficiently.
That's the nightmare scenario. You finally get everyone using the wiki because the AI makes it easy, and the AI is quietly poisoning them with obsolete procedures.
Detecting this is harder than detecting a broken link. You have to know enough to question the answer. The new hire who's never deployed anything before asks the AI how to deploy, gets a confident answer, follows it, and breaks production. They had no way to know the answer was from a page last updated before the infrastructure migration.
The AI raises the stakes on curation without doing the curation itself.
That's the key move. But here's where it gets interesting — AI can also help with the curation. Not by replacing the knowledge manager, but by changing what their job actually is.
A few specific capabilities that are useful. First, staleness detection. An AI can compare last-updated dates against usage patterns and flag pages that are frequently accessed but haven't been reviewed in eighteen months. That's a signal a human curator would never have time to generate manually across ten thousand pages.
It triages for you. Instead of reviewing everything, you review the high-traffic stale pages.
Second, contradiction detection. Using embedding similarity analysis, an AI can find two pages that describe the same process differently and flag them. The classic wiki problem is that the onboarding page says one thing about expense reports and the finance page says another, and nobody notices until someone submits an expense wrong.
I've lived that exact problem.
Third, it can suggest links between pages that are semantically connected but were never cross-referenced. Someone wrote a page about a customer escalation in twenty twenty-one, and someone else wrote a page about a product change that resulted from it, but neither page links to the other. The AI spots the connection.
The knowledge manager's job shifts from writing everything down to reviewing and approving what the AI surfaces. Higher leverage, requires judgment, not typing speed.
And there's a fourth capability that I think is underrated — generating first-draft documentation from meeting transcripts or Slack threads. The AI listens to the decision being made in real time and produces a draft summary. The knowledge manager reviews it, edits it, publishes it. The capture happens as a byproduct of the meeting, not as a separate task.
Which connects back to what we said about harvesting documentation rather than creating it from scratch.
There's a knock-on effect here that I think is the real transformation. Once you have RAG-enabled search, organizations start discovering what they don't know. Someone asks the AI a question, gets no useful answer, and that gap becomes visible. The question itself is a signal.
It flips from push to pull. Instead of writing documentation because someone decided you should, you write it because someone actually asked the question.
The companies using these tools are seeing exactly this pattern. The most common queries on RAG-enabled wikis are "how do I" procedural questions — things that were technically documented somewhere but buried so deep nobody could find them. The AI surfaces existing knowledge that was already there but unfindable.
Which means the first win isn't new documentation. It's making the existing documentation actually usable.
And the second win is that the gaps become obvious. Teams start asking questions the wiki can't answer, and those questions create a prioritized documentation backlog. You're not guessing what people need to know. You're responding to demonstrated demand.
The pull-based culture solves the incentive problem we were talking about earlier. Documentation stops being unrewarded busywork and starts being the answer to a question someone actually asked.
The knowledge manager's metric shifts accordingly. You stop measuring pages created and start measuring questions answered correctly. Track the percentage of RAG queries that return satisfactory answers, and use the gaps to prioritize what to document next.
That's a much more honest metric. Pages created is vanity. Questions answered is value.
Given all that, what can you actually do starting tomorrow? I think there are three things that are actionable.
Lay them out.
First, before you buy any AI tool, before you even look at a vendor demo, run a knowledge audit on what you already have. And I mean a brutally simple one. Take five common procedural questions your team actually asks — real ones, not hypotheticals — and run them through your existing wiki search. Count how many return a correct, current answer.
I'm guessing most organizations would flunk that test.
Most organizations would be lucky to get two out of five. And that's before the AI enters the picture. If your wiki search can't surface the right answer, RAG won't magically fix it. It'll just surface the wrong answer more persuasively. So the first action is: know the state of your source material. Run the five-question test. The results will tell you exactly where to invest curation effort.
You might discover the wiki is actually fine and the problem was findability. Or you might discover it's a disaster. Either way, you know.
Either way, you're making decisions based on evidence instead of vibes. Second actionable thing — and this one you can implement next week without any budget — start lightweight capture rituals before you need them. Not a massive documentation initiative.
Give me specifics.
A fifteen-minute weekly Slack thread: what did we learn this week? Anyone can drop in a sentence. A decision that surprised them, a workaround they discovered, a customer conversation that changed their thinking. It doesn't need to be polished. It just needs to exist.
You're creating the raw material that an AI can later index.
Only if it exists. That's the catch. The AI can't index a conversation that was never captured. Second ritual: a post-mortem template that asks one question — what would we do differently? — and gets filled out within forty-eight hours of any project milestone. That's straight from the HBR recommendation. The forty-eight hour window is the difference between capturing the real reasoning and capturing a sanitized summary.
The third ritual?
Record and transcribe key meetings where decisions get made. Not every meeting — the ones where someone says "I think we should go with option B" and the room agrees. That moment, captured and transcribed, is institutional memory being created in real time. You don't need someone to write it up afterward. You just need the recording to exist.
The through-line across all three rituals is: stop expecting people to write documentation as a separate activity. Harvest it from the work they're already doing.
The AI tools get more useful every month at extracting structure from those raw captures — transcripts, Slack threads, post-mortem templates. But they can't extract from nothing. The capture has to happen first.
What's the third action?
Shift your metric. If you're the knowledge manager — or if you're the person who got handed knowledge management as a side responsibility — stop measuring pages created. Start measuring questions answered correctly. Track the percentage of queries against your knowledge base that return a satisfactory answer.
This is such a better incentive structure. Pages created rewards volume. Questions answered rewards accuracy.
It gives you a clear signal for what needs attention. If someone asks "how do I provision a new development environment" and the AI returns an answer from a page last updated in twenty twenty-three that references tools you deprecated eighteen months ago, that's not just a bad answer. It's a curation task with a known priority. You know exactly which page needs updating and why.
The gap becomes the to-do list.
It's a to-do list driven by actual demand, not by someone's guess about what might be useful. That's the pull-based culture we were talking about. The metric aligns your incentives with actual value creation. You're not rewarded for writing more pages. You're rewarded for making the existing pages more useful.
To synthesize: test your wiki with real questions before you buy anything, start capturing raw material through lightweight rituals that don't feel like documentation, and measure what actually matters — whether people are getting correct answers, not whether you're producing more pages.
None of these require a massive budget, a new hire, or executive sponsorship. They require a decision to stop treating knowledge management as something you'll get to eventually and start treating it as something you do a little bit of every week.
The sloth approach to knowledge management. Slow, steady, and actually finished someday.
I was going to say the archery approach. Small, consistent practice beats the occasional heroic effort.
Of course you were going to say the archery approach.
The point stands regardless of the metaphor.
Where does this leave us? I want to leave you with a question. As AI gets better at extracting knowledge from unstructured sources — Slack, email, meeting transcripts — does the wiki as a distinct artifact disappear? Or does the need for a curated, canonical source of truth become even more important?
I've been turning this over and I think the answer is the second one. The Wikipedia research is instructive here. Organizational memory requires active maintenance. It decays without rehearsal and revision. AI can help with the rehearsal — surfacing, connecting, flagging — but it can't replace human judgment about what's worth keeping and what's safe to let go.
Because the AI doesn't know which decisions mattered. It can tell you two documents contradict each other, but it can't tell you which one reflects the actual policy. Someone still has to make that call.
That someone needs to understand the organization well enough to make it correctly. Which brings us back to the human in the loop — not as a bottleneck, but as the curator of last resort. The wiki doesn't disappear. It becomes the canonical layer that the AI draws from, and the knowledge manager becomes the person who ensures that layer is trustworthy.
The organizations that will thrive are the ones that treat knowledge management as a first-class discipline. Not a side project for the most organized person on the team. An actual engineering and operations function.
The cost of not doing this is concrete. Decisions made without context. It's a tax you pay every quarter, invisibly, on everything you forgot you knew.
Daniel's prompt got at something I think a lot of people feel but don't articulate. The knowledge is in the room. It's just not anywhere anyone can find it. And the gap between those two things is where organizations leak value constantly.
The good news is the tools are better than they've ever been, and the capture strategies don't require a revolution. They require a decision. Run the five-question test. Start a what-did-we-learn thread. Measure what actually matters.
Now: Hilbert's daily fun fact.
Hilbert: In the early Renaissance, the mathematician Scipione del Ferro discovered a general solution to the depressed cubic equation but never published it. He passed the secret to his student Antonio Fiore on his deathbed, and the formula was lost to the wider world until Niccolò Tartaglia independently rediscovered it in fifteen thirty-five — leading to one of the most dramatic public math duels in history.
A deathbed equation handoff. That's honestly the most on-brand thing Hilbert has ever delivered.
We just did a whole episode about institutional memory and Hilbert accidentally lands on a literal deathbed knowledge transfer. I don't know whether to be impressed or unnerved.
This has been My Weird Prompts. If you enjoyed the episode, rate and review us wherever you listen — it helps more people find the show. And if you've got a weird prompt of your own, email the show at show at my weird prompts dot com. We're always looking for the next one.
I'm Corn.
I'm Herman Poppleberry. We'll catch you next time.
