Cheap to Write, Expensive to Keep

Somebody on your team spent months teaching an AI assistant how the work actually gets done here. Which client wants the summary before the deck. What gets checked before anything goes out. The two things that went wrong last year and must never go wrong again.

Then the laptop got replaced. Or the project moved to someone else. Or they left.

And what survived the move was almost none of it.

Nobody deleted anything. Nothing broke, right up until the moment it mattered. The knowledge was real, it was written down, and it was written down in the layer that doesn’t travel.

Call them the belt and the pants. Memory is the belt, the skill is the pants, and the test for which is which is what you’d lose if it vanished tomorrow. In an AI setup the belt is what your assistant remembers about you. The pants are the document, the runbook, the checklist somebody else could open without asking you first.

Which of the two a piece of knowledge lands in is almost never decided. It gets decided by which one is easier to write into, and that is the part worth proving rather than asserting.

The important knowledge drifts into the cheap layer because the cheap layer is cheaper. That’s the whole engine. If it isn’t true, none of the rest follows.

And it’s worth taking that objection seriously, because a reader with good tooling can answer it in one line. My assistant writes the document for me now. Both layers are cheap. Where’s the asymmetry?

The expensive half was never the writing

There’s a body of research on this that nobody thinks to look at, because it’s filed under software engineering rather than under AI.

Emad Aghajani and colleagues mined 878 documentation-related artifacts from mailing lists, Stack Overflow discussions, issue repositories and pull requests, and built a taxonomy of what actually goes wrong with documentation. They then took that taxonomy back to practitioners and asked which of the problems matter. That second study, published at the International Conference on Software Engineering in 2020, drew 146 responses across two surveys, and every figure below comes from the first of them, which drew 78.

Start with what practitioners called worst. At 69%, the single most widely reported problem was the lack of documentation for a new feature or component, which the authors note was “not only the one considered important by most participants” but “the most recurring issue in this subcategory.” Inconsistency between code and documentation followed at 59%, described as “one of the top recurring issues they face.”

So far this reads like a case for exactly the tool you were about to buy. The durable record is missing and out of date, and generation fixes missing.

Then the same survey asks what makes documentation hard to maintain, and the answers run the other way. The two dominant concerns were superfluous content, at 55%, and duplicate content, at 46%.

Read the two halves together, because the pairing is the finding. The durable layer is missing what people need and stuffed with what they don’t, at the same time. It isn’t empty and it isn’t full. It’s unsorted.

Nothing about writing explains that. A record fails in both directions at once when nobody is deciding what goes into it, and the survey has practitioners saying so in their own words. Asked what would fix documentation, they kept proposing budget, which the authors read the obvious way: this “suggests that software documentation does not receive the attention it deserves when planning and allocating software resources.” Missing comments, elsewhere, were attributed to understaffed projects, “where the team tends to focus more on coding rather than on documenting.”

The authors end up pointing at the same thing, and it’s a striking conclusion to find in a software engineering paper. “The research community has focused on the generation of code comments,” they write, “while our survey points to the need for approaches that identify redundant and/or unnecessary code comments that increase the comment maintenance cost.” One practitioner’s proposed fix goes further in the same direction: keep the durable record to the minimum needed, because a smaller record is simpler to keep true as things change.

Two limits, now that you’ve seen the numbers, and both bind. This is software documentation rather than AI memory, used here as the best-measured instance of a durable knowledge artifact we have. And the sample leans heavily on one company: 125 of the 146 participants worked at ABB. The paper reports that for the combined pool rather than per survey, so I can’t tell you precisely how single-company the 78 are. These are also perception figures, which is not the same as measured outcomes, and the paper is careful about that.

Where the asymmetry actually sits

Now the question the article opened with, and the survey answers half of it. Start with the half it can’t.

Nobody has measured a cheap layer and a durable layer side by side, in software or anywhere else. And what makes the cheap layer cheap isn’t a finding, it’s the definition. It’s the layer you could lose without consequence, so nobody sorts what goes into it and nobody comes back to check it later. That much is true by construction, and true by construction is not evidence.

Which would settle nothing, except that it’s also where the story at the top of this article went wrong. Losing that memory layer cost plenty. What was in it wasn’t redundant at all.

So the cost driving the migration was never the cost of losing the cheap layer. It’s the cost of writing to it, and that cost gets paid at a moment when the other one is invisible. Thirty seconds and a line, against a document, a structure, and a decision about who reads this in six months. Both prices are compared at the point of writing, and only one of them is on display there.

That’s where the survey earns its place, because it puts a number on the half nobody sees. The durable layer costs the writing, plus the deciding, plus the keeping-true, and every problem practitioners named above is one of those second two rather than a failure of composition.

So the asymmetry was never about typing speed, which is the version your tooling can fix. Better generation made writing cheap on both sides of the split at once, and left the deciding and the keeping-true untouched.

That reaches you by transfer rather than by direct measurement, and it’s worth saying plainly. Nobody has run this study on an AI memory layer. What the software case supplies is the mechanism, and the mechanism is what travels.

One more thing it doesn’t touch. Cheaper generation raises the volume of what lands in the durable layer, and volume is what practitioners named as the maintenance cost. That a generator generates more is my inference rather than their finding.

The objection I can’t close

Here’s where I stop having evidence, and it’s worth marking the join rather than writing past it.

The strongest challenge to all of this is that it’s already obsolete. Vector databases, organisational retrieval systems and shared agent state are turning memory into durable institutional infrastructure. The cheap layer is becoming a shared, backed-up, searchable asset. So memory becomes the durable stratum, and the distinction dissolves.

My reading is that this confuses two different things. One is whether the substrate survives, and a shared index obviously does. The other is whether what’s in it is worth anything when you need it. A vector store full of facts you could have derived in ten seconds is still the cheap layer, backed up. Durability of the container tells you nothing about criticality of the contents.

And the trajectory may run the other way from what the objection assumes. Dumping a line into a shared index is cheaper than writing a document, and it feels institutional while you do it. If the engine here is cost asymmetry, a cheaper channel that feels more official is the engine running faster.

That’s my position, and I went looking for evidence on both sides of it. On whether knowledge stores fill with derivable noise rather than canon, the evidence exists and it points this way. That’s the 55% and 46% above, and it’s about human-maintained documentation rather than vector stores. On organisational retrieval systems specifically, I found nothing. No study measuring what accumulates in a production shared memory store, in either direction.

The nearest adjacent finding is worth one line, because it describes the failure this would produce. Florin Cuconasu and colleagues, at SIGIR in 2024, found that documents scoring high on relevance but not containing the answer “negatively impact the effectiveness of the LLM”, which is consistent with what an index full of near-duplicate derivable facts would look like from the inside.

So treat the position above as ours rather than as a finding. What we know is that the durable layer people already maintain fills with material nobody needed. What nobody has measured is whether the shared index does the same thing faster.

What to do about it

The sorting test does the classifying, and it turns on what the knowledge is about rather than how important it feels. Knowledge about the work, meaning how it gets done and what gets checked before it goes out, is durable. Knowledge about a person, meaning how they prefer to work, is cheap, and it’s only true of them anyway. The common failure isn’t confusing the two. It’s writing work knowledge into the person place, because that’s the easier place to write. That’s the belt taking the weight the pants were meant to carry, and it holds right up until the moment you move.

What follows assumes the sorting, and changes what you do about it.

Ask one thing what it would cost you to lose

Not your memory layer in general, which is too big to think about. Pick the single most useful thing your AI setup currently knows about how your team works, and ask what you’d lose if it vanished tonight.

If the answer is “nothing, it’s written down properly somewhere else”, you’re fine and you’ve learned your setup is in better shape than you thought. If the answer is “quite a lot”, you’ve just found work knowledge living in the cheap layer, and you found it in about a minute.

Budget the deciding, not the writing

This is the move that follows straight from the research, and the one that survives better tooling.

If your answer to a thin knowledge layer is a tool that writes more of it, you’ve funded the half that was already cheap. What needs a budget line is the sorting and the upkeep: an hour of a senior person’s attention on a recurring basis. It’s unglamorous enough that it never wins against anything urgent, which is precisely why it has to be scheduled rather than intended.

This is the same argument the harness compounds, not the model makes about budget allocation, arriving one level down. That piece asks whether the memory layer is your bottleneck at all. This one assumes you’ve decided it is, and asks what inside it is worth paying for.

Prune on a schedule, because volume is the cost

The 55% and 46% are the operational finding in this whole article. A durable knowledge layer degrades by accumulation, not only by neglect. That the degradation runs faster when writing to it is easy is the same inference I flagged earlier, not a finding of theirs.

So the review has to include deleting. If nothing came out of your durable layer last quarter, it isn’t being maintained, it’s being appended to. A retention policy for AI meeting agents works the same problem from the exposure side, sorting by artifact type and half-life. Sorting by what the knowledge is about is the other axis on the same shelf, and you want both.

Know when you’re in the temporary state, and say so out loud

Sometimes there’s no durable layer yet because the knowledge is genuinely new and hasn’t settled. A line in memory really is all you’ve got, and that’s fine.

What isn’t fine is not knowing you’re in it. The cheap version of this move costs nothing: when somebody writes something into the fast layer that’s about the work rather than about a person, they say so at the time. Not a process, just a habit of naming it. The knowledge stays where it is, and it stops being invisible.

Run the handover before you need it

The first move tests one item. This one tests the organisation, and it’s the test nobody runs until a resignation forces it.

Pick someone, and ask them to write down what they’d need to hand over if they changed projects on Monday. Then check how much of it already exists somewhere the next person could open without asking them. The gap is your answer, and it costs an afternoon instead of a departure.

The part that doesn’t get easier

Every tool in this space is getting better at the writing. None of them is getting better at knowing what mattered, because that’s a judgment about your business rather than a text-generation problem.

Which means the asymmetry isn’t closing. It’s moving, out of the writing and into the judgment. That’s a smaller job than producing documentation, and a much harder one to hand to anybody else, and it’s the one nobody has a tool for.