How to build a company brain on files starting from people.

Many companies think they already have a knowledge base because they have Drive, Notion, Slack, a few SOPs, and many experienced people. In reality they have fragments. Knowledge lives in documents, but above all in people’s heads: why an exception is made, which client needs extra care, which data is reliable, which written rule no one follows anymore.

The company brain makes that knowledge readable. It is the practical step after the political question we covered in Who owns the company brain: if the company’s operating memory becomes an AI feature, it should stay yours, verifiable, and portable. Tools like Claude Projects show the model well: a useful workspace does not live only in the chat, but in context the system can reread[3]. The difference is who governs that context and how clear it is.

Do not begin with “let’s put the whole company into a company brain.” That is the fastest way to create an unmanageable archive. Start small: one process, one function, one type of decision, one recurring flow.

A good boundary has three traits: it happens often, it breaks when context is missing, and today it depends on one or two experienced people. If a junior person cannot do it without asking for help, there is probably tacit knowledge to capture.

The knowledge transfer interview works because it does not ask people to “write the process.” It asks them to tell the real work. The best sources are not abstract descriptions, but episodes: the last hard case, the exception handled well, the almost-lost client, the check done before pressing send.

We usually propose 2-3 1:1 sessions with a member of the Yempik team. We record the call, ask targeted questions, then use the transcript as raw material to build structured files[1]. That is where human knowledge becomes readable by the machine without losing human judgment.

Speech-to-text shortens the slowest part: you do not need to rewrite everything by hand. Models like Whisper made transcription of calls and interviews much more accessible[4]. But the transcript remains a raw source. It can lose context, confuse names, invent words, or flatten a complex decision[5].

That is why the right flow is: record, transcribe, extract patterns, build files, then have the expert validate them. The person does not have to rewrite everything: they correct, approve, or block. That shifts the effort from blank-page writing to intelligent review.

The value is not in the recording. It is in the files that remain after it. They should be small, well-named, easy to update, and explicit enough to be read by both a person and a model.

A company brain dies when no one updates it. Minimum governance is not bureaucracy: it means knowing who can change a rule, when a source should be archived, and how wrong information gets corrected. The NIST AI RMF treats governance, mapping, measurement, and risk management as continuous functions[6]. In small-company terms: the file needs an owner.

Take a sales team preparing B2B quotes. The senior person knows when to apply a discount, when approval is required, which clients are sensitive, and which promises should never be made. None of this fully lives in the CRM.

Session 1: real flow. Rebuild the last complex quote: request, data used, checks, exceptions, final output.

Session 2: criteria. Pull out unwritten rules: discount thresholds, risks, cases to bring to the founder, words that change priority.

Session 3: validation. Bring the generated files back to the senior person: they correct rules, approve examples, and flag what should not become automatic.

At that point the company brain is not “nice documentation.” It is operating material: it can help a new person, give context to Claude Cowork, and become the foundation for an agent if the process can hold. To understand when to make that jump, the next step is integrating AI agents with the Standard-First method.