Company brains live or die on adoption, not architecture

Adoption beats architecture

The piece opens by refusing the obvious framing. Setting up a company brain — a shared, AI-readable memory of how an organisation actually works — is usually treated as a data problem: connect the folders, load the docs, wait for magic. The headline finding from 200 deployments is that this is the losing move.

'If you treat the company brain like a wiki migration, it dies.' The three things that actually predict success are all human: who owns it, who uses it first, and whether context comes from real work or a side project someone maintains by hand.

None of that is architecture. It is a useful counterweight to most writing on the topic, which is mechanics-heavy: layer models, retrieval, permissions.

Lesson 1 — the empowered champion

The single biggest predictor is one internal champion: a person, ideally senior, with good instincts for what AI can and can't do, trusted to act without sign-off. Connect a folder, grant access, add a team, 'make a reversible mistake', all without a meeting.

The reason is mechanical rather than motivational. If every small change needs approval, 'the system never gets enough signal to become useful.' A brain improves by absorbing corrections, and corrections only flow if someone can feed them in freely.

The licence has a hard edge, though. 'Act freely, mistakes are reversible' holds until the data is client or employer data — there, some mistakes are not reversible, and the champion's speed has to coexist with the boundary.

Lesson 2 — the technical-user paradox

Engineers ask the right questions — where does the context go, what if two files conflict, how are permissions enforced — and then 'question themselves into paralysis.' They want deterministic guarantees before joining a non-deterministic system: software whose output isn't fixed for a given input, so you can't pre-prove it will behave.

Less-technical users often do better because they start from the work. Draft the email, fix the tone, upload the missing thread, judge whether it helped, repeat. 'A company brain is closer to onboarding a new employee than configuring a database.'

The tension is real but it resolves by layer. 'Keep moving, correct later' is the right rule for using the brain. 'Prove the scope first' is still the right rule for structural changes to it.

Lesson 3 — the brain builds itself

The load-bearing context is not in static documents. It lives in how people actually work: the thread explaining why a client is sensitive, the message rejecting a positioning, the 'we don't do it that way here' aside that never reaches the wiki.

Nobody maintains all that by hand, so a separate Notion or Drive layer 'goes stale in days.' The fix is to embed the upkeep in the work itself, so context moves upward as a by-product rather than as a chore.

This is the compounding claim: the brain starts imperfect and every interaction sharpens it, the way interest builds on interest. The warning inside it is blunt — any corner you update manually is the corner that will rot.

Where it thins out

Strong as it is, this is a field report, not a study. 200 deployments, self-reported, no numbers, and the author sells the service, so survivorship is baked in.

It is also written for teams, and the solo translation is lossy. Lessons 1 and 2 largely evaporate when the champion, the first user and the whole 'company' are one person: there is no approval chain to unblock and no colleague to un-paralyse. What genuinely transfers is lesson 3.

The strongest case against the whole piece: it may just be describing clients who were already going to succeed, dressed up as causal lessons.

Vocabulary

• company brain — a shared, AI-readable memory of how an organisation actually works
• internal champion — the one empowered person who drives and feeds an internal system
• non-deterministic system — software whose output isn't fixed for a given input, so it can't be pre-proven
• compounding — small gains build on each other, so value grows faster over time

If you're building — what to watch for

• If your knowledge layer needs someone to file things by hand, assume it is already going stale — make context flow up from the work as a by-product, or don't build it.
• Split your rules by layer: tolerate ambiguity and correct as you go when USING an AI system, but still prove the scope before making structural changes to it.
• The 'move fast, mistakes are reversible' licence stops dead at client or employer data. Keep a hard wall there and accept that it slows you down on that side.
• A system that can't absorb corrections freely never gets enough signal to become useful — check whether your setup actually lets you feed a correction back in, cheaply, today.
• Beware validation-shaped reading: a field report that tells you your instincts are right is the easiest thing in the world to over-weight.

Reading it critically

• Self-reported field notes from someone selling the service — no numbers, no benchmarks, survivorship baked in.
• Lessons 1 (champion) and 2 (technical-user paradox) mostly dissolve for a solo builder who is champion, first user and whole 'company' at once — only lesson 3 fully transfers.
• 'Make reversible mistakes' is exactly wrong where the data is sensitive — a leak of client or employer data isn't reversible, so the free-access advice has a hard edge.
• The causal claim is weak: it may be describing clients already set up to win, not lessons that caused the win.