TL;DR: a company brain is persistent memory of the calls, chats, documents and tasks your company already produces. It answers questions with a source you can open, logs decisions with a date and an owner, checks task follow-ups against what actually happened, and sends the owner one brief a week. It is useful for owners whose decisions happen on calls and whose team is remote. It is a waste for a team of five in one room.
Most of what is written about a company brain is either a vendor page or a prediction. I have run one every day since early October 2026, inside one of the companies we operate, so this is a definition from the operator side: what it is, what it costs to keep alive, and where it does not help.
I will also say what it gets wrong. Answers can be wrong. That is the reason every answer shows its source, and it is the reason I trust the system at all.
What is a company brain?
A company brain is a persistent memory built from what your company already says and writes: call recordings and transcripts, team chats, documents and the task board. On top of that memory sit three jobs. It answers questions and shows where the answer came from. It keeps a record of what was decided. It keeps people on track by comparing what was promised with what happened.
The word persistent matters. A chat with a general AI tool forgets everything when you close the tab. A brain remembers that on a call three weeks ago someone agreed to send a revised quote by Friday, and it can tell you whether that happened.
The word brain is a bit grand. In practice it is a database, a set of connectors, a retrieval layer, an AI model on top, and a set of rules about who can see what. The value comes from the connectors and the rules, not from the model.
What goes into a company brain?
Four kinds of input, all things that exist already. Nobody has to start writing anything new.
- Call recordings and transcripts: this is where most decisions in a remote company are actually made
- Team chats: the running commentary, the small agreements, the questions that never reached a document
- Documents: plans, specs, contracts, notes, whatever the team keeps
- The task board: what is assigned, to whom, and what state it is in
These four are what we connected in the company where we run it. Calls matter most. If you only connect one source and you run a distributed team, connect the calls.
What comes out of it?
Four outputs. Each one replaces a chore that someone currently does badly or not at all.
Answers with sources
You ask what was agreed with a supplier, or why a price changed, and you get an answer with a link to the call, message or document it came from. I treat the source as the real answer and the sentence as a summary of it. When the sentence looks off, I open the source, and sometimes the sentence is the part that is wrong.
A decisions log with a date and an owner
Decisions get pulled out of calls and written down with the date and the person responsible. This sounds minor until the third time someone asks why you chose a vendor and nobody remembers. It also ends the quiet argument about whether something was ever decided.
Task follow-ups checked against facts
A task marked done is a claim. A brain can set that claim next to the calls and chats around it and flag the gap. A person saying the work is done and the transcript showing the client still waiting are two different facts, and the owner usually only hears the first one.
One weekly owner brief
A single summary for the owner: what was decided, what is overdue, what changed. One page, once a week, built from the same sources. It replaces the status round where five people each tell you their version.
How is a company brain different from a wiki?
A wiki depends on people writing into it. A brain reads what the company already produces. That one difference decides which of the two is still accurate six months in.
Every team I know has started a wiki with good intentions. It is current for about a month, then it drifts, because writing documentation is nobody's job and the real decisions keep happening on calls. A wiki records what someone had time to write down. A brain records what was said.
This does not make a wiki worthless. A clean, written policy is better than a transcript for anything that must be exact. The brain can read your wiki too, as one more document source.
How is it different from enterprise search?
Search finds documents. A brain also tracks what was decided and whether it happened. Those are different jobs.
Enterprise search is good at the question: where is the file about this. If you type a topic, you get a list of places to read. You still do the reading, the reconciling and the remembering. A brain is built around the question: what is the current state of this, who owns it, and did it get done. That needs a record of decisions and a link between a decision and a task, which a search index does not keep.
If your only problem is that people cannot find files, you do not need a brain. Fix search first.
How is it different from a personal second brain?
A personal second brain is one person's notes. It has no permissions, because there is only one reader, and no conflicting sources, because the author is the only source. A company has neither luxury.
In a company, two people describe the same decision differently. A call from March says one thing and a chat from May says another. Finance data should be visible to the owner and not to everyone. A company brain has to handle both: it has to show where sources disagree instead of quietly picking one, and it has to know who is allowed to ask what. Those two requirements are most of the engineering.
Who needs a company brain?
Three kinds of owner, in my experience. They share one trait: the decisions happen somewhere the owner cannot easily re-read.
- The owner of a remote or distributed team, where decisions happen on calls and the only record is whatever someone remembered to write
- The investor-owner who is not in the daily work and needs to know what is going on without sitting in every meeting
- The owner running several businesses, who cannot hold the context of each one in their head and keeps asking the same questions in different companies
What these have in common is a gap between what happens and what the owner knows. The brain narrows that gap. It does not remove it, and anyone who promises otherwise is selling you something.
Who should not buy one?
Two clear cases, and I would rather tell you now than after the setup.
- A team of five in one room. You already share the context by being there. A brain would summarise what everyone heard an hour ago.
- A company that does not record calls or keep a task board. The brain reads what exists. If the calls are not recorded and the work is not tracked, there is nothing to read, and the first project is getting those habits in place, not buying software.
There is a third case I would add: an owner who does not want to look at the output. The weekly brief only works if someone reads it and acts on it.
What do you need to start?
Four things. The software is the easy part of the list.
- Access to the sources: calls, chats, documents and the task board, with someone who can grant it
- One person who knows how the company really works, who can say that this channel is noise and this recurring call is where pricing gets decided
- A decision on who sees what, made in advance, with finance kept for the owner
- Consent from the people on recorded calls, asked for plainly and recorded as given
The third item is where setups stall. Permissions are an owner decision, and they are easier to set at the start than to tighten after people have seen things they should not have.
The fourth item is not optional. Putting a person's words into a system that anyone can query is a real change for them. Tell them, and make it a yes they can give freely.
How do people actually use it?
Through the tools they already use, with their own login and access that matches their role. If people have to open a new app to ask a question, they stop asking within a week.
In the company where we run it, people reach it from Telegram, from WhatsApp, from a web chat, and through MCP from their own AI tools. MCP is the standard that lets an AI assistant you already use connect to an outside source, so the brain shows up inside the assistant instead of as a separate destination. Each person sees what their role allows and nothing more.
What does it cost to run, and what goes wrong?
Two things surprised me. One is a cost I measured, the other is a cost I did not expect.
The measured one is model spend. Over 20 days in one company, chat on a top model cost about $0.08 per answer. We then tested a smaller model on 30 real questions from the team. It answered at about $0.006 per answer, against $0.12 on the larger model in the same test. So routine chat moved to the smaller model, and anything that touches decisions stayed on the stronger one. Thirty questions is a small sample, and I would run it again on your questions before trusting my result for your company.
The unexpected one is approval. Decisions extracted from calls go in as proposals, and a human approves them before they count. That is the right design, because a model reading a transcript will sometimes call a hypothetical a decision. But within two weeks the unapproved proposals had piled up into the hundreds. Approval has to be somebody's job, with time set aside for it, or the decisions log becomes a backlog nobody trusts.
Beyond that, the failure I watch for is the confident wrong answer. The defence is the source. If a team stops opening sources, the brain gets less reliable without anyone noticing, so I treat the habit of checking as part of the system.
Should you build it yourself or have it set up?
You can build one. The pieces exist and a capable developer can connect them. The work that takes time is not the first demo, it is the permissions, the approval routine, the model choices and the weeks of correcting what it gets wrong.
We offer it as a service: we set it up with your team, then we run it together with you. We pick the sources with you, set the access rules, train the approval routine, and keep tuning it as the questions change. If you have an engineer with spare capacity and a clear owner for the project, building in-house is a reasonable choice, and I would say so on a call.
If you are not sure whether your company is the kind that benefits, the quickest test is a question: when did you last wish you could re-listen to a call from last month? If the answer is this week, you probably have the problem. If the answer is never, you probably do not.
This is what we build and run for owners. See how Brain works