Tribal Knowledge Is the Reason Your Automation Project Stalled.
The project started well. The process was mapped, the happy path was clear, the builder configured the first rules in a week. Then the builder asked a question: what happens when the order is under the minimum. And another: what if the customer is on credit hold. And another: what if the part is on back-order but the customer is a priority account.
Three people knew the answers. None of them agreed. The answers were not written anywhere, and when someone tried to write them, the document ran to nine pages of "it depends" and the project stopped. Six months later the automation is still ninety percent built, and the ten percent that is missing is the ten percent that handles real orders.
That is tribal knowledge, and it is the most common reason automation and AI projects stall in mid-market companies. Not the software. Not the model. The decision rules that live in people and were never stated.
What tribal knowledge actually is.
The phrase gets used loosely to mean anything undocumented. The useful definition is narrower. Tribal knowledge is a decision rule that exists only as the behaviour of experienced people. When the under-minimum order arrives, Maria does something with it, consistently, and the something is a rule. She could not tell you the rule, because she has never had to; she recognises the situation and acts.
Automation needs the rule stated. A workflow rule is a condition and an action, and a condition has to be written down. An agent needs its goal and its limits in words. There is no way to configure "do what Maria would do," so the project stops at the exact moment it meets the first decision Maria makes without thinking.
This is why the stall arrives late. The happy path is not tribal; everyone agrees what happens when a normal order comes in from a normal customer. The exceptions are tribal, and the exceptions are where the work is. We made the same argument from the documentation side in the piece on writing down the exceptions, not the happy path. This piece is about why the exceptions are unknown in the first place, and how to get them out.
Why the documentation drive fails.
The reflex response is a documentation drive: everyone writes down their processes, in a template, by Friday. It produces a shelf of documents and it does not produce the rules, for two reasons.
The first is that it asks the wrong question. "Document your process" invites people to describe the happy path, because that is what a process looks like when you are asked to describe it. The exceptions do not feel like process; they feel like judgment, and people do not write their judgment into a template.
The second is that the people who hold the rules are the busiest people in the company, which is why they hold them. The under-minimum order goes to Maria because Maria handles it. Asking Maria to stop handling orders for two days to write about handling orders does not happen, or produces a page written at eleven at night that says "use common sense."
We have also watched the documentation drive produce something worse than nothing: a confident document describing a process that is not the one the experienced people follow. The builder automates the document. The experienced people override the automation silently, because they know it is wrong, and the overrides are invisible to everyone else. The company now has an automation that reports success and a process that runs on the side.
Extract the rule from the exceptions.
The method that works starts from the opposite end. Instead of asking what the process is, collect what the exceptions were.
Take the last ninety days of the process, in whichever system holds it: the orders, the tickets, the quotes. Pull the ones that did not follow the happy path. In most mid-market companies this is between five and fifteen percent of the volume, and it is findable: the orders edited after entry, the tickets reassigned twice, the quotes with a manual discount. That list is the exception set.
Then sit with the experienced person and go through them, one at a time, asking the same question each time: what did you do with this one, and what about it told you to do that. Not "what is the rule." What did you do with this one. The rule emerges from the answers, and it is usually simpler than anyone expected. Thirty under-minimum orders turn out to follow three rules: accept it if the customer ordered last month, hold it if they are new, call them if the shortfall is over two hundred dollars. Maria never stated that, but it is what she did.
Two days of this with each of the three people, and the exception list exists. It also surfaces the disagreements, which is a separate and valuable finding: the three people handle the same exception differently, and the company has to decide which way is right. That decision is the automation's rule, and it had to be made by someone with the authority to make it, which is why the builder could not make it alone.
What the extracted rules look like.
A process that was "nine pages of it depends" usually resolves to a short table. The situation, the rule, the exception to the rule, and who decides when the exception to the exception arrives. Twelve rows is typical for a process that felt impossible to document.
That table is three things at once. It is the specification for the automation, written in the form a builder can configure. It is the training document for the next person who joins, which the company never had. And it is the first honest description of how the business actually runs, which is why a surprising number of these sessions end with the owner changing a rule they did not know existed.
It is also the precondition for anything agentic. An agent given a goal and the twelve-row table can act on the exceptions. An agent given the goal and "use common sense" will act anyway, and the cost of that shows up at the customer.
The symptom to watch for.
If an automation or AI project in your company has been ninety percent done for more than a month, ask one question: what is the ten percent. If the answer is a list of cases nobody can specify, the project is not stuck on technology. It is stuck on tribal knowledge, and no amount of builder time will move it. Two days of exception extraction with the right person will.
The people who hold the rules are not the obstacle. They are the only source of the rules, and most of them are relieved to have the rules written down, because it means the under-minimum order can finally go to someone else. The tool was never the missing piece, as we argued about process documentation software; the missing piece is the two days.
Our AI Readiness Review includes the extraction: we pull the exception set from your systems, run the sessions with your people, and hand back the table. Discovery is no-risk: you pay only if you go ahead.
Know whether your data and processes are ready for AI before you pay for it.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments