Why your company
wiki died

Somewhere in your shared drive is a folder that was going to fix this. Someone built it, everyone agreed to keep it current, and it was accurate for about five weeks. That failure is structural, not cultural — and it's the thing standing between a small company and AI that's actually worth having.

The previous note argued that AI in a business is only as good as the written account of how that business works — and it ended on an uncomfortable finding: that account goes stale fast. Eighteen months of ordinary change is enough to make a carefully built context layer actively misleading.

Which raises the obvious objection, and it's the one I get every time I describe this to an owner:

"We've tried this. We built a wiki. Nobody updated it."

That's not an objection I can argue with, because it's true nearly everywhere. So this note is about the only version of the answer I've found that survives contact with a real company.

Documentation loses to the work. Always.

The standard diagnosis is a discipline problem — people are busy, people are lazy, we need to hold the team accountable. Every company that reaches that diagnosis tries the same three fixes: a mandate, a template, and a recurring calendar reminder. All three fail, and they fail in a predictable order.

They fail because the incentive is upside down. The person who has the knowledge pays the cost of writing it down, and someone else — usually someone who hasn't been hired yet — receives the benefit. That's not laziness. That's a rational response to a tax with no rebate.

It gets worse the more valuable the person is. Your best estimator, your most experienced agent, the operations person who knows what to do when the vendor misses a date — these are exactly the people whose time is most expensive and whose knowledge is most worth capturing. The documentation tax falls hardest on precisely the people who can least afford to pay it.

So the question isn't how to make people document more. It's whether the deposit can stop being a separate act at all.

What a harness actually is

The word I use for this is a harness, which is engineering vocabulary, so here it is in plain terms.

Most companies that adopt AI give people a chat window. The employee copies something out of a system, pastes it into the chat, gets an answer, and pastes the answer back. The AI never touches the business. It's a very articulate stranger you consult on your lunch break.

A harness is the opposite arrangement: the assistant is connected to the systems the work actually lives in — email, the file store, the CRM, the calendar, whatever the industry-specific system of record is — and the employee does the work through it rather than 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.

That distinction sounds like a convenience feature. It isn't. It's the thing that makes the deposit possible, and here's why.

The layer has to run in both directions

Almost everyone who thinks about AI and company knowledge thinks about one direction: the employee pulls. They ask a question, the system answers from what the company knows. Extraction. That's the demo, that's what gets bought, and on its own it decays exactly the way your wiki did.

The direction nobody designs for is the other one. When an experienced person does a piece of work through the harness, they leave evidence — a judgment call, an exception, a rule they applied that isn't written anywhere, a vendor who let them down, a phrasing that worked. All of that is deposit material, and it's produced whether or not anyone intends to produce it.

The second column is the one that pays for the whole thing, and it is invisible on day one. That's the hard part of selling it and the reason most implementations stop at column one.

Click through a few ordinary work tasks below and watch what accumulates. Then flip the mode.

So how does it get out of their heads

Two assumptions come up here, and both are wrong. It isn't one place everyone has to work out of — ask semi-autonomous people to change where they work and adoption is finished before it starts. And it isn't knowledge-transfer assignments, which is the chore that already failed. Nobody writes a document at any point in this.

Four mechanisms do the actual work, and they run at different times.

Structured interviews are the front load, and there's a technique that decides whether they're worth anything. Experts can't tell you what they know — the rule became automatic years ago, so they don't experience it as a rule. Ask "what are our pricing rules" and you get platitudes. Ask "walk me through the last four quotes you sent" and the rules fall out of the cases, including ones they'd have denied having. Cases, never abstractions.

Mining existing work — the last fifty proposals, a few hundred client emails — drafts the rules far faster than asking. But old files hold the current policy and the 2019 one nobody deleted, with nothing marking which is which, so everything mined is a candidate that goes back to a human. Skip that and you've automated the spread of stale truth.

The moment of correction is the one that makes it compound. Someone gets a draft that's ninety percent right and fixes the last ten. That correction is the deposit — precise, tied to a real case, and free, because they were fixing it anyway. The system asks one question about the change and it takes one click to answer. This is what keeps it alive after the initial build.

The exception moment is the densest knowledge a company produces and almost nobody captures it. When someone escalates, waives something, or overrides a default, an undocumented rule is surfacing in real time. You ask while the reasoning is still loaded, or you don't get it.

All four end in the same place: a queue, as candidates. One named person decides what becomes true. Capture is automatic; acceptance never is.

Why this only works at company level

I've run this setup on my own work for about two years. On one person it's a productivity tool — useful, but the compounding is bounded by how much one person does.

At company level something different happens, and it's worth being precise about what: the deposits are made by many people and the extractions are made by many people, but they're not the same people. The estimator's judgment call gets deposited on Tuesday and shows up in a new hire's draft on Thursday. That transfer used to require the two of them to be in a room together, and it used to only happen by luck.

That's the actual mechanism behind every claim people make about institutional knowledge. Not "AI makes everyone faster" — although it does. The claim worth paying for is that your good people's judgment becomes available to everyone, continuously, without anyone scheduling a training session.

Here's the same twenty-four months from the previous note, with the deposit loop running.

What this doesn't solve

Worth saying plainly, because the version of this argument that skips it is a sales pitch rather than a description.

Deposit is not curation. Capturing what happened is mechanical. Deciding which of two contradictory things is now true is a judgment call, and no amount of automatic capture makes it. Somebody at the company has to own that — arbitrating what's true when the layer disagrees with itself, retiring things that got superseded, deciding what's firm policy versus one person's habit. It's three to five hours a week and it usually belongs to whoever people already go to when they don't know the rule.

If nobody is given that job, the layer accumulates contradictions instead of decaying into staleness. That's a different failure but it isn't a better one. The honest version of this offer includes naming that person, and I'd rather walk away from an engagement than pretend the software covers it.

And it won't run itself on day one. The first pass of getting what's in people's heads into a usable form is interview work — sitting with the experienced people and asking the questions that surface the rules they don't know they're following. That part is labor, it takes weeks not days, and anyone who tells you it's a software install is selling you the demo.

Contractors, and who owns what

A lot of companies this size don't run on employees. Real estate brokerages, insurance agencies, staffing firms, agencies of most kinds — the producers are independent contractors with their own books of business. It changes the design in a way that's easy to get wrong and expensive to get wrong.

You cannot quietly hoover a contractor's client relationships into a company asset. Beyond whatever their agreement says about it, the moment people suspect that's happening they stop being candid, and candor is the entire input to the deposit loop. One misstep here and you've killed the thing you were building.

So the layer has to be split, deliberately and visibly:

Where I'd start

Not with a rollout. The first thing worth knowing is whether there's anything in your people's heads worth extracting, and you find that out by extracting some of it — picking a handful of people across experience levels, taking three workflows they do every week, and building the first version of the layer around those. Three or four weeks. At the end you know what the full thing costs, because you've done a real sample of it rather than estimated one.

That's also the honest test of whether this is for you. If the sample doesn't produce anything your team recognizes as valuable, the full build won't either, and you've spent a month instead of a year finding that out.