Not in a system. Not in the manual. In their heads — and it leaves the building every evening. You already know this. What you may not know is why every attempt you've made to write it down has died within a quarter, and what has to change structurally for the next one to survive.
The usual diagnosis is that people are busy or careless, so the usual fixes are a mandate, a template, and a recurring reminder. All three fail, in that order, at every company that tries them.
They fail because the incentive runs backwards. The person who has the knowledge pays the entire cost of writing it down, and the benefit goes to someone else — often someone who hasn't been hired yet. That's not laziness. That's a rational response to a tax with no rebate.
Any system that requires people to do a second, separate job in order to capture what they learned during the first job will decay to the rate at which people voluntarily do unpaid work. That rate isn't zero — but it's close enough that you should plan as if it were.
So the question isn't how to get people to document more. It's whether the writing-down can stop being a separate act at all.
Most companies adopting AI hand people a chat window. Someone copies something out of a system, pastes it in, gets an answer, pastes it back. The assistant never touches the business — it's an articulate stranger you consult on your lunch break. Nothing it learns is kept, because there's nothing connecting it to anything.
Connected, the work happens through the assistant instead of beside it. Not "ask the AI about the proposal" — draft the proposal in the place where the client history, the pricing rules, and the last four proposals already are.
Everyone designs the pull. Ask a question, get an answer grounded in how the company works. That's the demo, that's what gets bought, and on its own it goes stale exactly the way your wiki did.
Nobody designs the push. But when an experienced person does real work through the assistant, they leave evidence — the exception they made, the threshold they applied, the vendor who let them down, the phrasing that landed. That material is produced whether or not anyone intends to produce it. It costs nothing extra, which means there's nothing to skip.
The second column is what pays for the whole thing, and it's invisible on day one. That's the hard part — and the reason most implementations stop at the first column and quietly decay. How the deposit physically travels is further down; it's simpler than it sounds.
Two assumptions come up immediately, and both are wrong in ways worth being direct about.
It isn't one place everyone works out of. Ask sixty semi-autonomous people to change where they work and adoption is over before it starts. The assistant attaches to the tools they already use — their inbox, their CRM, their files. You meet them where they are.
And it isn't knowledge-transfer assignments. That's the chore, and the chore is the thing that already died. If the plan involves anyone being asked to write up what they know, you've rebuilt the wiki that failed.
Four mechanisms actually move knowledge out of heads. They run at different times and they're worth telling apart.
Front-loaded. Where most of the first version comes from.
There's a technique to this and it's the difference between weeks of work and nothing. Experts genuinely cannot tell you what they know — the rule became automatic years ago, so they no longer experience it as a rule. Ask "what are our pricing rules" and you get platitudes everyone already agrees with.
Ask instead: "walk me through the last four quotes you sent." The rules fall out of the cases, including the ones they'd have sworn they didn't have. Cases, never abstractions. That's the whole trick, and it's why this is real labor rather than a form.
Front-loaded. A shortcut, not a source.
The last fifty proposals. Two hundred client emails on one topic. The patterns are already in there, and reading them produces a draft of the rules in a fraction of the time it takes to ask.
The critical qualifier: this generates candidates. Old files contain the current policy and the one from 2019 that nobody deleted, and nothing in the folder says which is which. Every mined rule goes back to a human for confirmation. Skip that step and you've automated the propagation of stale truth.
Ongoing. This is the one that makes it compound.
Someone asks for a draft, gets something ninety percent right, and fixes the last ten. That correction is the deposit — precise, attached to a real case, and free, because they were fixing it anyway.
The agent asks one question about the change, in the same conversation, and a sentence answers it. No document, no form, no Friday roundup. This is the answer to "what keeps it alive after you leave."
Ongoing. Targeted at the highest-value moments.
When somebody escalates, approves a deviation, waives something, or overrides the default — that is an undocumented rule surfacing in real time. It's the densest knowledge your company produces and it's almost never captured, because by the time anyone thinks to ask, the reasoning has evaporated.
You ask in the moment, while the reasoning is still loaded, or you don't get it at all.
Capture is automatic; acceptance never is. Every one of the four routes above ends in the same queue, and a named reviewer decides what becomes true. That distinction is what separates a layer that gets better from one that fills up with sixty contradictory opinions — which is a different failure than going stale, and not a better one.
People find this one least intuitive, so here's a single instance end to end. Two things worth knowing before you read it.
It's a conversation, not an interface. There's no special screen watching someone edit and popping up a prompt. The agent asks, in the same chat where the work is already happening, because its standing instructions tell it to.
Which means it captures what people tell it, not what they do elsewhere. A correction made half an hour later in Word or Outlook is invisible to it. The deposit comes out of the back-and-forth of getting the work right — which is also, conveniently, where the reasoning actually lives.
The ask is an instruction, not a mechanism — the agent will usually remember, not always. That's acceptable here and unacceptable elsewhere, and the difference is worth being precise about, because it's the line most AI pitches blur.
Not everything a system does carries the same duty. Sorting the work into these three categories before anything gets built is what decides where an instruction is sufficient and where you need a mechanism.
Probabilistic capture is fine.
Noticing a rule, catching an exception, learning which vendor is unreliable. Missing one costs you nothing permanent because rules recur — the same correction surfaces again next week. This is where the deposit loop lives.
Grounded generation, then a human reads it.
Drafts, summaries, comparisons, client correspondence. The layer makes these accurate far more often, and a person still signs off. Most of the day-to-day value sits here, and so does most of the time saved.
Deterministic check plus required approval.
Regulatory disclosures, prohibited language, mandatory approvals, records retention. A single miss is the whole problem, so these cannot rest on the model choosing to comply. They need software that runs regardless, and a named person who signs.
The deposit loop is squarely in the first column. Nothing in the third column should ever be described in the same language — and if anyone tells you their assistant "checks for" a compliance requirement, the question worth asking is whether that check is a mechanism or a request.
A manual written once is at its most accurate the day it's finished. That's the trap, and it's why the objection is usually delivered as proof that this doesn't work.
Below is the same two years under three arrangements: no written layer at all, a layer written once and maintained by hand, and a layer fed by the work as it happens. What's being measured is the share of real questions it answers well enough that somebody can act without checking first.
Plenty of companies this size don't run on employees at all. Licensed agents, producers, advisors, contractors — people with their own books of business who can't simply be told what tools to use. It changes the design in a way that's easy to get wrong and expensive to get wrong.
You cannot quietly absorb someone's client relationships into a company asset. Beyond whatever their agreement says, the moment people suspect it's happening they stop being candid — and candor is the only input the deposit loop has.
Shared and governed. How the firm works, what the rules are, the standards, the vendors, the procedures everyone follows. People read from it; changes route through a named reviewer.
Theirs. Their clients, their territory, their voice, their live work. Private by default, and deliberately thin — every minute someone spends maintaining it is a minute they resent.
Things move upward only on purpose and with the person's knowledge. This is the rule that makes the whole arrangement survivable, and it's worth writing down before anything gets built.
Two constraints shape the whole build. Nobody producing work should ever see a repository or learn a developer tool. And nobody producing work should ever be able to edit shared truth directly, because sixty people with write access to the same files produces sixty versions of the truth inside a quarter.
Worth being precise here, because it's the difference between a policy and a fact: the second constraint isn't something we promise to be careful about — the shared library simply cannot be edited by the people it's delivered to. And where something genuinely must be present on every machine, it can be made impossible to remove. Those are properties of how the tooling is distributed, not house rules somebody has to enforce.
Both are satisfied by a single rule: producers only ever create new files. They never edit existing ones. Everything else follows from that.
New files never collide with each other, which quietly removes every problem you'd otherwise have with sixty people writing at once. No locking, no conflicts, no last-write-wins data loss. The append-only inbox is the entire trick.
Append-only applies to the inbox, not to the knowledge itself. Worth stating plainly, because it's an easy thing to over-apply. The wiki has to be fully editable by the reviewer — rules get corrected, superseded, and sometimes deleted outright, and a body of knowledge that can only ever be added to stops being an operating manual and becomes an archive. Version control gives you the history; the current page still has to say what's true today and nothing else.
Mid-task, in the tools they already use. Their agent writes a small proposal file into the inbox — what the rule seems to be, the case it came from, which page it would change, who and when. The producer clicked once.
Not by hand-editing files. They read the proposals and make decisions — accept, revise, reject. Their agent does the mechanics: applying accepted rules to the right pages, updating cross-references, writing one clean, attributed commit per proposal.
Because each accepted proposal became its own coherent commit, there's a real diff to look at — what changed, why, sourced to a specific case. That's a review anyone can do. A pile of loose edits in a shared folder is not.
Accepting the change is the release — there is no separate step where somebody remembers to distribute it. Every producer has the new version by their next task. A rule that lived in one person's head is now applied by sixty people, and nobody attended a meeting about it.
Because the inbox sits outside the repository, only reviewed and accepted material is ever committed. A proposal that contained a client's details, or was simply wrong, is deleted rather than preserved — it never enters the permanent knowledge record. Version history is excellent at remembering and very bad at forgetting, so keeping the gate in front of it rather than behind it is the whole point.
To be precise, since this is a privacy claim: that means no permanent trace in the knowledge repository. Ordinary application and security logs are a separate matter, governed by your existing retention policy, and are part of the data-flow document rather than something this design changes.
Producers get a desktop agent with the firm's library already installed — no repository, no accounts, nothing to set up, and nothing they could break. The reviewers get a developer-grade agent that can read history, write commits and manage the repository. Same knowledge, two entirely different surfaces, matched to who's actually sitting there.
Two people hold that second role, not one. A primary who works the queue and a backup who can cover a holiday, an illness, or a resignation. One reviewer is a single point of failure sitting directly on top of the thing you paid to build.
The first version of the inbox is a person noticing something and writing it down, the way your operations lead already handles everything else. Automating it is worth doing once the volume proves it's worth doing — which is a number you get from running a small pilot, not from guessing in advance. Building the machinery first is how implementations end up with excellent plumbing and nothing flowing through it.
Take a firm of sixty licensed agents in a single city — a brokerage, though the shape is identical at an insurance agency, a small law firm, an accounting practice, or an agency of any kind. Semi-autonomous producers, regulated written output, and a handful of people who know everything.
In a firm like this the productivity gain mostly belongs to the producers, not the company — they're independent, and they keep what they earn. So the reason the firm pays isn't speed. It's that the knowledge stops walking out the door, quality stops varying by whoever picked up the phone, and there's a defensible answer when someone asks why a document said what it said. Those are owner problems, and no amount of individual productivity fixes them.
Every one of these should be settled in writing before a single system is connected — whoever you end up doing this with. The answers below are the ones I'd argue for; the point is less that you agree with them than that somebody has committed to an answer before the work starts.
This is the right first question, particularly if you're in a regulated field where client information carries obligations beyond your own preferences.
The principle: your operating knowledge is plain readable text, in a repository your company owns, that stays legible if every tool involved disappears tomorrow. What gets connected, what's excluded, retention, and whether anything can be used to train anything are settled explicitly in the agreement before connection — not assumed, and not left to a default setting somebody didn't read.
Being exact about one thing a technical reader will ask: the knowledge is yours and sits in your repository, but delivering it to sixty people and connecting to your other systems does route through the vendor's infrastructure rather than your local network. That's a normal arrangement and it is not the same as "nothing leaves the building" — so it belongs in the data-flow document, in writing, rather than in a reassuring sentence.
If you have an existing security review or a compliance officer, they belong in that conversation from the start rather than at the end.
All of it, unconditionally. The extracted knowledge is the company's own knowledge — nobody helping you build it has a defensible claim to it, and anyone who wants one is telling you something.
There's a practical reason beyond the ethical one. The entire input to this process is people being candid about how they actually work. Any ambiguity about who ends up owning that shuts the candor down, and the candor is the whole product.
Plain text, your repository, readable without anyone's tooling. If it stops, you keep a documented company.
It will be. The relevant question isn't whether an AI system makes mistakes — it's whether yours are visible and fixable, or invisible and repeated.
A grounded layer changes the failure mode. When an answer is wrong you can see which written rule produced it, correct that rule once, and it's right for everyone from then on. Compare that to a chat window, where the same mistake is regenerated fresh every time and there's nothing to fix.
Constraints on prohibited language and required disclosures reduce risk substantially. They do not eliminate it, and they don't replace your review. Anyone telling you otherwise is selling you something.
If you have to, it isn't working — and with independent producers you couldn't anyway.
Adoption is the honest measure of whether this is worth continuing, which is why it's tracked from the first week rather than reported at the end. Every design decision that adds friction for the person doing the work is a tax paid against it.
The pattern that works: start with a small mixed group including at least one person everyone else watches. If they use it visibly, the rest follow. If they don't, that's the finding, and it's cheaper to learn it in week three than in month nine.
Worth saying plainly, because the version of this argument that skips it is a sales pitch rather than a description.
Recording what happened is mechanical. Deciding which of two contradictory things is now true is judgment, and no amount of automatic capture makes it. Somebody at the company has to own that — three to five hours a week, usually the person everyone already asks when they don't know the rule. Skip it and the layer fills with contradictions instead of going stale. Different failure, not a better one.
Getting what's in your people's heads into usable form is interview work — sitting with the experienced ones and asking the questions that surface rules they don't know they're following. Weeks, not days. Anyone describing this as a software install is selling you the demo.
Your core systems can't be connected to — everything downstream degrades back to a chat window. Or nobody can be freed for a few hours a week to own what's true. Or the goal is to reduce headcount, in which case the people whose knowledge you need will read the room correctly and tell you nothing useful.
The conclusion I keep arriving at is that nobody should begin with a rollout. The first thing worth knowing is whether there's anything in your people's heads worth extracting — and the only way to find out is to extract some of it. A handful of people across experience levels, three workflows they do every week, a few weeks of work.
That's also the honest test, and it's why I'd argue for it even though it makes the idea look smaller. If a real sample doesn't produce something the team recognises as valuable, the full version won't either — and you've spent a month finding that out instead of a year.
Most of this comes from doing the same work at much larger scale, where the failure modes are identical and only the budgets differ. I write these up mainly to think them through properly. If you're wrestling with the same problem I'd like to hear how it's going — including the parts where you think I've got it wrong.
Senior Lead Application Developer, working on enterprise AI assistants at Fortune 500 scale. Ten years in conversational AI, six of them at enterprise scale. This piece is that same method thought through for companies where one person still knows everything — a problem I find more interesting than the size of the company suggests.
These notes are how I work things out. Comments and disagreement welcome.
Email · Notes · Back to the site · LinkedIn