Sanara Consulting

Organisational memory

Everyone is building company brains.
I think the approach is wrong.

Ingest every email, every deal note, every Slack thread. Deck out every room with microphones. Then let AI retrieval sort it out. But a store that accepts everything degrades as noise accumulates, and some early research suggests the same.

Record everything, so it can be legible to the AI.

That is roughly the pitch. Tom Blomfield put it plainly in a recent YC batch talk: capture it on your phone, on a clip, on smart glasses, or deck out every room with microphones, because everything needs to be recorded so that it can be legible to the AI. Hello 1984.

It is a funded category now, and the reasoning behind it is not stupid. Companies, agentic or not, generate data and outcomes at volumes greater than any human can remember them. The tempting answer is to hoover all of it into one searchable store, then say something like: AI will figure it out.

But a store that accepts everything degrades as noise accumulates. And an AI that learns from all of your raw operational chatter does not necessarily fix your inefficiencies. Worst case, it codifies them.

I launched a city in three weeks because someone owned the page.

You do not have to go far from how a company already operates effectively to get to a well designed and orchestrated learning brain.

In the early days at Uber, we had well maintained documentation on Confluence. Each page had an owner who kept it updated. That discipline is the reason I could launch a city within three weeks of starting: the key insights and learnings were current, centralised, and readable in one sitting.

As the company progressed, the discipline was lost, and knowledge dissolved into thousands of Google Docs floating around. Nothing about that failure was technological. The pages did not get worse. The upkeep did.

A noisy store cannot be rescued at read time.

There is some early research on this, a small study by Zahn and Chana. They filled a memory store two ways and asked it the same questions.

13% accuracy for a store that accepted everything, once near misses (they call them distractors) had built up
100% accuracy on the same test, for a store that filtered at the point of writing

The ingest-everything approach holds thousands of items, most of them noise. Just reflect on how much genuinely valuable information comes out of all the meetings you sit in. Ingesting everything means ingesting half-formed observations, one-off anecdotes, and contradictory notes from different weeks.

Then an agent asks a question. A search layer runs over that store, pulls back the handful of entries that look most relevant, and ranks them. Looks most relevant is a similarity judgement, not a truth judgement. Near misses resemble the right answer closely: a stale finding from an A/B experiment can read almost identically to the current one.

Filtering at read time cannot save you from a noisy store, because a search layer can only rerank what is already there.

So control what gets written in.

What gets in, how it is updated, and a dated log of what was rejected and why. If only verified, supported claims are allowed in, then everything the search returns is trustworthy by construction. There is nothing to filter out.

So I built the opposite of ingest-everything: a small, curated, human-gated knowledge base that agents read whole, fed by distillation loops with a statistical bar.

Which is really just those early Uber Confluence pages again. Every page had an owner who kept it current, except now an agent does the tedious part, and the human owner approves, edits, or rejects.

Built small,
on purpose.

We run this loop ourselves: a working company brain that fits in a git repository, five automated checks, one letter of instructions, and a weekly wake. It is the machinery behind two dimensions of our readiness framework, feedback loops and documented knowledge, made mechanical enough that forgetting stops being the default.