- A company’s operating knowledge is almost all tacit: it lives in the heads of the people who do the work, not in documents, and no one has ever written it down in full.
- The paradox is that the person who’s good at a process can no longer explain it: they’ve automated it, and to "how do you do it?" they answer "it depends" or "usually".
- The trick isn’t to ask for the theory, it’s to ask for the real last time: a concrete case, with names and numbers, and then dig into every "usually" and "it depends".
- That knowledge becomes useful to an agent only when it’s written as rules with a source, validated by whoever said them. From there the company brain, and the agent that works on it.
What holds the company together is written down nowhere
In almost every company, the part that matters about how the work gets done isn’t in a manual: it’s in the head of the person who does it every day. Which supplier to call when the trusted one is full, how to handle a customer who complains, when to make an exception and when not to. It’s tacit knowledge: real, valuable, and invisible, because no one has ever written it down in full. As long as that person is around, everything runs. The day they’re out, or the team doubles, the process jams.
There’s a paradox that makes the problem harder than it looks: the person who’s truly good at a process can no longer explain that process. They’ve repeated it so many times it has become automatic, like driving or tying your shoes. Ask "how do you decide?" and the honest answer is "it depends", or "I usually do it this way, but not always". They’re not hiding anything: the knowledge has simply dropped below the level of words. Getting it out is the real work.
The person who’s good at a process can’t explain it to you, because they’ve automated it inside themselves. Your job isn’t to ask for the rule: it’s to make it resurface from a real case.
Don’t ask "how does it work": ask "how did the last time go"
The question that doesn’t work is the abstract one: "how do you handle a complaint?". It forces the person to invent a clean, theoretical version that doesn’t match how they actually work, and fills you with "usually" and "in general". The question that works is concrete and in the past tense: "the last time a complaint came in, what happened? Who was the customer, what did they write, what did you do, line by line?". A real case can’t be sugar-coated: it has names, timing, an outcome.
From there the method is to dig, not to nod. Every time you hear an "usually" or an "it depends", stop and ask what it depends on: "I usually reply within an hour, except when…", and that "except when" is the real rule, and it’s exactly what an agent needs to know. Have them walk through two or three different cases, including the one that went wrong, and the exceptions surface on their own. You’re not doing a journalistic interview: you’re bringing to the surface an algorithm the person runs without seeing it.
Interview, transcript, rules with a source
The method, in full, is simple and repeatable: two or three 1:1 interviews with the people who know the work, recorded and transcribed, then turned into structured files, decisions, rules, glossary, open questions, and validated with the person. It isn’t a technical process: it’s a transfer of knowledge from a head into readable files. We wrote it step by step here: how to build a company brain on files.
Plus the instructions, the routine automations, and a real, already filled-in example to copy from.
The open-source cowork-os kit gives you the ready structure where those answers can land: folders for context, decisions, and rules, with an already filled-in example to copy from. You don’t start from a blank page: you paste in a file, answer six questions, and the workspace builds itself, ready to hold the knowledge you’re pulling out of the interviews.
A rule with a source is something an agent can apply
The difference between a note and an operating rule is the source. "Returns after 30 days are refused" is an opinion until it’s traceable; "returns after 30 days are refused, decided on March 12 because logistics can’t hold beyond that, except for premium customers" is a rule: it has a reason, a date, an exception. Written that way, a new hire applies it without asking, and so does an agent. That’s what makes a company brain different from a wiki: it doesn’t tell you how it’s built, it tells you how you decide, right now.
This is also the jump that moves a company up the maturity ladder: from knowledge that lives in heads (L0) to structured, live context that people and agents read. If you want to know the level you start from and what the next step is, take the self-check. When you then want to go from context to an actual agent inside the workspace, the method for working on it is in Claude Cowork.
This is the extraction step, not the whole job
It’s worth being honest about the scope: pulling out tacit knowledge is only the first step, not the whole company brain. The interview is worth it when the knowledge lives in one head and no one has ever written it down; it isn’t worth it when the process is already well documented and stable, or when it changes every week and any written rule is stale on arrival. And on its own it isn’t enough: the extracted rules have to be structured into files, validated, and maintained as reality changes. The full method, from the interview to the governed workspace, is here: how to build a company brain on files.
If you already have the context and want to move to the agent that works on a real process, with a fixed price and timeline, see AI agents for companies.
From tacit to agent, in practice
What is tacit knowledge, in a company?
It’s the operating knowledge that lives in the head of the person who does the work and that no one has ever written down in full: which exception to make, which supplier to call, how to handle a hard case. It’s real and valuable, but invisible, and it disappears when the person is out or the team grows. Turning it into readable context is the first step to getting an agent to work on the process.
Why can’t the person who knows a process explain it?
Because they’ve repeated it so many times it has become automatic, like driving. The knowledge has dropped below the level of words, and to "how do you do it?" the honest answer is "it depends". It isn’t reticence: it’s automated expertise. That’s why you don’t ask for the theory, you start from a real case and dig into the "usually" and the "it depends".
How do you run an interview to extract tacit knowledge?
Not by asking "how does it work", but "how did the last time go": a concrete case, with names and numbers, told line by line. Every "usually" or "it depends" is a signal: stop and ask what it depends on, because that’s where the real rule is. Have them walk through two or three cases, including the one that went wrong, record, transcribe, and turn the answers into rules with a source.
What does an agent need to know to apply a process?
Rules with a source, not notes. An operating rule has a reason, a date, and an exception: that way a new hire applies it without asking, and so does an agent. An agent doesn’t fail because the model is weak, but because it doesn’t know the company’s context: the company brain is that context, written so it’s readable by people and agents together.
Sources
- [1]cowork-os, open-source repository. github.com
This page is written by Raffaele Zarrelli and Simone Bova, founders of Yempik, with editing done with Claude. The company brain and its maturity model are Yempik editorial models. The kit cited is our open-source cowork-os (MIT license). The process examples are illustrative.
Do you have someone who "knows everything" and no time to write it down?
We do the interview. We start from a real process, pull out the rules and the exceptions, and put them into files you own, governed, that the team and an agent can re-read and apply. Fixed price and timeline, the code is yours.