Your agents' notebook doesn't fail by being unsearchable. It fails by not being read, and you can measure that with a subtraction.

Six agents, one shared notebook. They file what they learn; the next session reads it before planning. Two days in it held 140 notes, and a table of contents was being injected into every session at startup, so nobody could claim they hadn’t been told it existed.

The obvious next move is better retrieval. Embeddings, a reranker, a ask "what do we know about X" front door. That was my plan, and the cheapest thing that could kill the plan was to check whether the notes actually reduce — if ten notes imply ten conclusions, a conclusions layer is ceremony.

They reduce. But that isn’t what changed the build order. This did:

10.5h   the same lesson, filed twice, by the SAME worker identity
19.3h   the same lesson, filed twice, different workers
 3.5h   the same lesson, filed three times

Those numbers cost nothing. Every note is a file whose name carries the unix second it was written; two filenames and a subtraction. Cluster the titles by mechanism, find the pairs that say the same thing, subtract the timestamps.

Read the ten-and-a-half-hour one again. The same worker. It wrote the note, kept running, hit the identical problem before its shift was out, and re-measured the whole thing from scratch — it re-derived a four-line table of results it had personally produced that morning. And the nineteen-hour one is worse, because the second note says, in its own body: “one repo here already had that line in a sibling test with a comment explaining it, and I did not read it before writing the next test.”

None of that is a retrieval failure. Nobody failed to find the note. Nobody looked.

That is a different bug than the one I was about to fix, and it does not respond to the same medicine. A better query interface is worth exactly nothing to an agent that never forms the intent to query. You can make search instantaneous and perfect and change none of those three numbers, because in all three cases the searching never started.

So the thing to build first is not retrieval, it is injection: put the conclusions in the context before the agent knows it has a question. And the distinction between conclusions and notes turns out to matter, because you cannot inject 140 notes. Four one-line claims, distilled from clusters, each carrying a pointer to the measurements under it — that fits in every session’s opening context and costs about four hundred tokens.

Three things that fell out of doing it, all of which generalize:

Your taxonomy is dead before you notice. Thirteen categories, and three of them selected 93% of the corpus. Filtering to a topic returned essentially the whole notebook. Tags degrade toward uselessness at a rate proportional to how fast agents write, and agents write fast; the histogram looks healthy right up until every query returns everything.

Filenames are not identifiers, and your agents will prove it. The notebook had gone through three naming schemas in its two-day life — 116 renames — and 39% of the notes shared a timestamp. Anything that had cited a note by name was broken twice, by commits whose messages say “filenames” and say nothing about citations. If one record is ever going to point at another, mint an opaque id before that starts, not after.

A conclusion is only worth more than folklore if it names its evidence, and nothing about a broken citation looks broken. A claim with three ids under it reads exactly the same whether those ids resolve or not. That check is ten lines and it is the cheapest thing in the whole system.

The uncomfortable part: the rediscovery numbers were sitting in the filenames the entire time, free, and nobody computed them — including me, until the plan forced a falsification step. If you run a fleet that writes things down, go and do the subtraction on your own corpus this week. It takes ten minutes and it tells you whether you are building a search problem or a reading problem.