How to build a second brain for your company's AI

Everyone who uses AI seriously for commercial work arrives at the same conclusion within about a month. The model knows almost everything except the four things that actually matter: your product, your buyer, your process, and what happened in the two thousand meetings you have sat in. So you start writing it down.

That instinct is right. Over the past year I worked with AI to document how my companies operate. Ideal customer profiles, pricing rules, how we keep the CRM, how we run a workshop, how I write an email. It came to a hundred and six documents. I do not regret any of it, because you cannot organise knowledge you have never put into words, and most companies have never put theirs into words at all. That work has to happen.

But it is the first half of the job, and I spent a long time believing it was the whole thing. I still correct or rewrite roughly three quarters of what AI hands back to me, and for months I assumed that number was a limit of the technology.

It was a filing problem.

The problem was named in 1945

In July 1945, Vannevar Bush published an essay in The Atlantic called "As We May Think". He had just spent the war coordinating American scientific research, and he was worried about a specific failure: the record of human knowledge was growing faster than anyone's ability to find anything in it. Specialists, he wrote, were drowning in findings they could not consult.

His proposal was a desk-sized machine he called the memex, which would store a person's books, records and correspondence and let them build associative trails between them. The important part is why he designed it that way. Bush argued that indexes and categories were the wrong model because the human mind works by association, jumping from one thing to the next along links. The machine should copy that while adding what human memory lacks, which is permanence. He even imagined a user photographing a whole trail and passing it to a friend to insert into their own memex.

Storage stopped being the hard part decades ago. Finding the right piece at the right moment still is.

The same idea shows up in Niklas Luhmann's card index, and later in the term most people know it by. Tiago Forte popularised "building a second brain" in his course and then his 2022 book of the same name. The phrase has since been flattened into "somewhere to keep your notes", which is a shame, because the original point was finding things again.

Why more knowledge makes the output worse

When you give AI a large document of instructions, it reads all of it, and everything in that document competes for the model's attention at the same time. If you have written a thorough twenty-thousand-word guide to selling into manufacturing, and you ask for a follow-up email to one manufacturing prospect, the model averages across every buyer you have ever described.

That average is what people mean when they call AI output generic.

You cannot fix that by writing less. B2B selling is complicated, and compressing it onto a page throws away the part that made it worth having. What has to change is what loads, and when.

Separate the front door from the house

In an earlier piece on AI in sales I argued for keeping a skill, the instruction file AI loads before it starts a task, tight. That holds for the part that loads every time. It took me a year to see the rest of it: there are two different kinds of thing in your documentation, and they want opposite treatment.

The first is instruction: how to approach a task, what good looks like, what never to do, where to go for the detail. This is short, it is stable, it changes rarely, and it should load every single time.

The second is knowledge: the substance itself. Every objection you have handled and what worked, every call transcript, your real pricing, the emails that sound like you. This is enormous, it is specific, and it should load almost never, in slivers, only when a task calls for it.

The mistake almost everyone makes, and the one I made at scale, is writing the second kind into the first kind. You end up with an instruction file that is really an encyclopedia, and it opens itself in full every time anyone mentions the topic.

The best thing in my own setup is the skill that teaches AI to write in my voice. An earlier version described my voice in detail across thousands of words and produced writing that read as machine-written, for the obvious reason that a description of a voice cannot produce a voice. The current version is a short front door that says which situation this is, and behind it sits a file of forty-five of my actual sent emails, sorted by situation. It reads the handful that match and writes. It is the only thing I almost never correct.

What the second brain is actually for

A second brain, in this sense, is a store of what you and your company know, structured so AI retrieves the specific part a task needs. Luhmann is the proof that this works, and the numbers are worth knowing. Between the early 1950s and 1997 he built a card index of roughly ninety thousand slips. He published dozens of books and hundreds of articles from it.

The cards mattered less than the links between them. Each card carried a fixed number and pointed at others, so that pulling one card pulled a trail of related thinking he had often forgotten he had. He described the box as a conversation partner. What made it useful was that he never had to read the whole thing.

That is what you are building. A store with enough structure that a question about a compliance buyer in manufacturing returns the three calls and two objections that bear on it, instead of the whole category.

A company needs two brains

Two decisions come first, because they are easy to get wrong and expensive to reverse.

Build two. I run a personal brain on my own machine, and we run a company brain for Up Strategy Lab. They are separate on purpose. The personal one holds half-formed thinking, notes from books, things I am still working out, and it can be messy because only I read it. The company one has to be trusted by other people, which means it is stricter about sources and maintenance. Mixing them produces a store that is too scruffy to rely on and too formal to think in. What connects them is a deliberate step, not a sync: once a week, at most five items from my week's work are proposed for the company brain, and nothing moves until I have approved it.

Decide what the model is allowed to do. This is the rule that makes the whole thing hold together, and it is worth writing on the wall:

Raw inputs are immutable. The compiled wiki is the source of truth. The model is a compiler, not an author.

Three things follow. Every compiled page carries a reference back to the raw file it came from, so if a page says something surprising you can walk back to the source in one step. The model is forbidden from adding general knowledge it happens to know, so the wiki represents only what you have actually read. And because raw files are never edited, the wiki is a derived artefact you can rebuild from scratch when you improve your prompts or change your format.

Most people break that third one by editing raw files in place, and then a change of format means starting again.

Where to build it, and how to start

Whatever you build it in, the principle is the same: the AI pulls only the few entries a task needs.

Starting today: a single folder of markdown files, one topic per file, each with a short summary at the top and links to related files. Point your AI tool at the folder. It is free, and it works.

Structure without engineering: Obsidian. Its graph view is the closest cheap thing to what Bush described, it stores plain files you can move later, and Claude Code, pointed at the folder, does the compiling on a daily schedule.

Available to every session and every colleague: a database with a small server in front of it that AI tools query directly. This is what the company brain runs on. It is more work and you should not start here.

The material to feed the store is already sitting in your business. Start with transcribed sales calls and won and lost deals, because they hold the real objections and the language customers use. Then CRM notes, support conversations, and the documents you have already written.

A prompt that works

You are helping me build a knowledge store my AI tools will query later. Read the attached material. Produce a set of separate knowledge items rather than one summary. For each item: a title of two to four words, a one-sentence summary of what it covers and when it would be useful, the substance itself with the specifics kept in, and links to any other items it relates to using double brackets. Split anything that covers two subjects into two items. Keep real numbers, names and quotes exactly as they appear. Reference the source file each claim came from. Do not add anything that is not in the source, and do not generalise. Add the date of the source to each item.

Run it over one quarter of call transcripts before you attempt the whole company. You will learn more from the first twenty items than from any amount of planning.

One practical note on cost. Compiling is volume work, so run it on a cheaper model and keep your best model for asking questions of the finished store. The judgement calls that matter most stay with a person: checking that a reference page is still true, and deciding what moves into the company brain. Getting that split right is the difference between a system you run every day and one you run once.

How mine runs

Nothing about it depends on me remembering. Every conversation I have with Claude Code is captured as it happens. At 09:15 each morning, a compile turns the previous day's conversations, and anything I saved, into pages: one for each account, person, competitor and idea, with every claim linked to the file it came from. Every version is kept, so a bad compile can be undone.

Before a call, one command prints what we know about the company, and it leads with what nobody has asked yet. An account page never leaves a field blank. Anything we do not know says "UNKNOWN: ask", because a blank reads as nothing to say, while "UNKNOWN: ask" reads as a question nobody asked. Those fields become the agenda for the call.

I started mine on 23 August. Six weeks later it holds 691 pages, 79 of them accounts, compiled from 124 conversations and 249 other sources.

We have packaged this setup as a free kit, so you can run the same thing: an installer, the compiler instructions, the page templates, the health checks and the daily compile, with step-by-step instructions written for people who have never used Claude Code. It takes about fifteen minutes on a Mac. Get the Second Brain kit.

What this does not fix

A knowledge store nobody maintains becomes a confident liar. Old facts do not announce themselves as old, and an AI quoting a price you retired last year is a specific and expensive way to lose credibility in front of a customer.

Discipline fails at this, reliably, so the fix has to be structural. Decide where a fact lives according to how fast it changes.

Anything that moves weekly never goes in the brain at all. Deal stages, invoice status, who owns an account, what a customer is currently paying. That data belongs in the CRM and the billing system, which are already the source of truth for it, and the AI should query them live at the moment it needs an answer. The brain holds the pointer, and the CRM holds the value. A copied number is out of date the moment you copy it.

Anything that moves slowly does belong in the brain, and gets maintained deliberately: product truth including current limitations, positioning, the objections that were answered well, how you run a discovery call, what your competitors actually do. This material is worth curating because it changes over quarters rather than days.

A third kind needs no maintenance at all, and it is the most valuable: dated evidence. What a buyer said on a call, why a deal died, which objection came up and what answer was tried. A record of what happened on a date stays true about that date, so it can be stored freely, and it is usually the only copy anywhere.

Everything carries a date, without exception, so that anything can be aged out later. And the traceability rule earns its keep here too. When a page looks wrong, you want to find the source behind it in one step rather than arguing with a paragraph nobody can account for. If nobody can check where a claim came from, people stop trusting the store, and then they stop using it.

And none of this gives you judgement. I can tell when a draft is wrong because someone spent years telling me when mine were. That is why I still catch the three quarters. A second brain lowers the correction rate. It does not replace the person doing the correcting, and if the people coming up behind you never get corrected by a human, retrieval will not teach them judgement.

Most of the visibility problems I see in B2B companies come down to something like this: knowledge the company already has and cannot find. I have twenty years of positioning work behind me, a Red Dot for MuchSkills, and 500,000 readers on the guides on this site. None of that stopped me building a library with no way to search it. Write everything down. Then build the thing that finds it.