What is tribal knowledge, and what does it cost?
Tribal knowledge is what the people in a company know and apply without writing it down.
The cost is easy to see in a furniture workshop. Its sheet-cutting software was built for the people who sell sheet material, and it does not minimize waste in production. On a large order the foreman re-nests the last sheets by hand, overnight. He saves a fifth of the sheet material. The owner did not raise this with the software’s developers: the foreman sat up one night and did it. The saving is real, and nothing in the system has learned it.
Where the geometry is non-standard, such as ventilation ducts in private houses, the software gives up and the foreman works it out by hand. A new worker learns by being shown once.
AI meets the same wall. A general-purpose model is trained on the internet and holds no detail on your products, processes and customers. Company knowledge fails an AI in four ways: it was not written down, it was written down selectively, it went stale, or it sits only in people’s heads. Where a gap exists, the model fills it with a guess, because its own knowledge of a niche field is vague and often contradictory.
Where does tribal knowledge live in a company?
Tribal knowledge lives in four places.
- In people. Product know-how can sit with the owners and the long-serving staff, while the technical cards that list materials and fittings per product have only just been started. Rules of exception sit there too: a drilling mistake in a hidden spot is re-drilled, and in a visible spot the part is replaced.
- In customer-facing teams. In one software company, each customer site runs more than a hundred business rules of its own. The customer-facing project team owns them. The engineering team that builds the product does not know which rules a given site uses, and in a rebuild these rules are the part that cannot be thrown away.
- In chats and folders. In small firms the messenger is the system of record. A machine shop keeps a folder for each client and pulls a proven program out of the messenger history with a freelance designer. A small manufacturer runs replenishment through a chat: workers post when a material runs out, and the owners read the chat and buy. When we took inventory of one business’s systems, the first list, built from the website and from memory, missed the telephony platform and the messenger. Work enters and moves through those two.
- In code and neglected documents. A product built by a small team and handed to a new one after the people who knew it left can become something no one can support. Without a formal architecture, one feature estimate takes many conversations and a dive into the code, and the answer is a wide range.
Why does connecting all our documents not fix wrong AI answers?
Access to documents is a precondition. It does not solve the problem. Connecting every wiki, mailbox and ticket system to an AI tool, through your own retrieval pipeline or a platform feature such as company knowledge in ChatGPT, gives the model what was written down. It cannot restore what was not. Where a piece of the process is missing, the model invents it, and the invention changes from one day to the next.
Standard retrieval returns the passages most similar to the question and hands them to the model. It has no view on recency, on which team’s version is authoritative or on which passage contradicts another. Retrieval-augmented generation (RAG) is explained in the FAQ on the AI Knowledge Base page.
A company wiki shows how this goes wrong. Wikis often turn into what one engineering manager called a write-only database: people add articles, then no one can find or read them. Nobody updates the pages, they lose accuracy, and people stop trusting what they find. They read less, and the wiki decays further. Connecting it to AI hands the same stale pages to a model that cannot tell they are stale.
What works is a curated set of sources with rules for conflict. We are building rules of this kind into our own agents. When two sources conflict, the AI does not average them. It follows a known order of authority, or it surfaces the conflict and asks the owner to decide. It prefers approved material to drafts and copies, and a source it cannot open is not evidence that the information does not exist.
What is knowledge engineering?
Knowledge engineering is the work of preparing what a business knows so that people and AI can use it. It does not depend on any AI tool. A knowledge engineer takes four steps:
- Define the structure. Decide what knowledge the work needs and which processes use it.
- Find what exists and what is missing. Take inventory of the sources and analyze the gap.
- Extract the gap. Pull the missing knowledge out of people, systems, code and recorded meetings.
- Restructure. Reshape the knowledge so that it has continuing owners and is ready for AI.
An AI knowledge base adds the AI side. AI automation specialists choose and tune models, decide which knowledge is static and which is dynamic, connect each kind to AI, and monitor cost, drift and permissions. Static knowledge goes in as files or into a tuned model, and fast-changing knowledge is pulled in at the moment of the request. The engineered knowledge stays valid when the model or the platform changes.
Restructuring is physical work. We rename files, reorganize folders, restructure data in a database or a codebase, and add annotations and attributes that help people and retrieval alike. Knowledge is organized by meaning, and the system where a document happens to sit does not decide where it goes. Decision logic and exception logic go in alongside documents. A diagram gets a detailed text description beside it, because AI reads text. Each item carries its owner, source, version and validity period.
How do you audit what your company knows?
A knowledge audit asks what the work needs to know, where that knowledge lives today and what is missing. It is the first two steps of knowledge engineering done in detail. For one process or knowledge area, we run it in this order:
- Build the knowledge model. Before touching real data, we model the knowledge itself: its containers, what each one holds, the dependencies between them, who is responsible for each part and which processes use it. The model is derived from the domain model and the process definitions, which is why process work comes first.
- Take inventory of the sources, people first. Document stores, databases, source code and unstructured material go on the list. So do the people, and what each of them may know. Chats and informal channels belong on it as well.
- Run the gap analysis. Compare the model with the inventory and mark what is missing, outdated, inaccessible, inconsistent or dependent on a person.
In a modeling interview we ask where critical knowledge is undocumented, inconsistent, fragmented or dependent on specific people. We listen for three symptoms. The first is tribal knowledge itself. The second is inconsistency: different teams read the same rule or term differently. The third is dependency risk: single points of failure, people everything waits for and the risk of losing knowledge.
We also ask which source is the source of truth, and we end by asking for documents that will check what we heard, such as process maps and issue logs.
How do you capture knowledge that exists only in people’s heads?
Structured interviews
We prepare an interview plan and run the interview by chat or voice, often with an AI interviewer. The generated questions are only a scaffold: the assistant asks follow-ups and, for some questions, proposes an answer that the person confirms or disputes. The transcript becomes documents, and the person who holds that knowledge verifies them. Meaning is confirmed in the interviewee’s own terms before anything becomes a finding.
Draft first, then correct
Where we know the domain, we bring a draft model for the person to correct. In an interview for an appliance repair business, an AI-drafted model said emergencies are handled differently from standard repairs. The person answered that every repair is treated as urgent and only the technician’s availability matters. The draft listed the call steps flat. The person pointed out that the diagnostic fee is explained before customer details are collected. The order of the steps carries a rule. The corrections are where the tacit knowledge surfaced.
Reverse engineering
Knowledge that lives in code is recovered from the code. AI walks the codebase, extracts the transactions and interfaces, assembles a draft architecture and derives the requirements from it. This used to be hard because someone had to study the code by hand, and AI has made it much simpler. Databases and recorded meetings are processed the same way.
Mining chat history
In small firms the real archive is the messenger. In one case under way, an owner fed the whole chat history of the team to a model, which picked out the situations that keep coming up in dispute and looked for how each was resolved. The aim is to take the person who settles these disputes today out of the daily loop. It is under test, and the result is not yet proven.
What should you capture first?
Do not try to capture everything. Full capture takes a long time and costs a lot. The gap analysis ranks the missing knowledge, and the ranking starts from the work:
- Can the priority workflow run without it? Pick one workflow worth improving and list the knowledge it depends on. Those gaps come first.
- Does only one person hold it? Single points of failure rank high, especially where the holder may no longer be available.
- Is it already shaped like a rule? Some tacit knowledge can be written down directly. A quoting rule that multiplies material cost and adjusts for how full the order book is becomes usable by an assistant once it is written down and connected to the order-book data.
Some gaps need more work than a rule. A dispatcher’s mental map of which service areas neighbor each other, and what makes a good route out and back, can be captured as a graph of neighboring areas.
Who owns the knowledge after it is captured?
Your organization does, with a structure we set up during the work. The structure is a governance model: who uses each piece of knowledge, who updates it, who may read it and who may change it. Every knowledge area gets a named owner, a review cycle, update rules and checks for completeness, accuracy, conflicts and freshness.
The owners are named during the engagement, not after it. Knowledge nobody maintains goes stale fast, and so does every assistant and agent built on it. The wiki described earlier decayed for exactly this reason: no one was responsible for it.
Knowledge engineering is not a one-off clean-up. In our five stages of AI adoption, tailored knowledge is Stage 3, and it comes with ongoing knowledge updates. Where you prefer, we keep maintaining the knowledge as processes, systems and AI platforms change.
Tribal knowledge, knowledge management system or AI knowledge base: what is the difference?
| Tribal knowledge | Knowledge management system | AI knowledge base | |
|---|---|---|---|
| What it is | What people know and apply without writing it down | Knowledge management software and the practices around it: wikis, document stores and help centers where people look things up | Structured, governed knowledge that AI uses when it executes work |
| Who uses it | The people who hold it | People who search and read | AI assistants and agents |
| What it holds | Rules, exceptions, judgment, context | Documents and articles | Rules, procedures, decisions, examples, exceptions and reference data |
| How it fails | It leaves with the person | It turns into a write-only database | Wrong answers when sources are stale, conflicting or unowned |
Knowledge management tools serve a reader: they return documents for a person to interpret. An AI knowledge base serves an executor: it hands AI the current rule, the approved example and the exception it needs to act, together with a model of what AI must know, a map of where it lives, the gaps filled, and owners with review and update rules. The two are not rivals. A company’s SharePoint can be reorganized and connected to AI so that assistants rely on it instead of a search box.
Knowledge engineering is the work that turns tribal knowledge into an AI knowledge base.
How EIC builds an AI knowledge base
AI Knowledge Base turns scattered know-how into governed context that assistants and agents use when they execute work. We work in three steps. We build the knowledge model. We map, restructure and fill the sources with the methods described above. We deliver, validate and govern: we choose how each type of knowledge reaches AI, test its use in the output, and assign owners with update and review rules.
The question to ask any AI knowledge base company, or a knowledge management consultant, is what stays with you when the engagement ends. From us you receive an organizational knowledge model and source map, AI-ready knowledge assets and access design, and a quality and lifecycle model. The next assistant or agent starts from a foundation that already exists.
The knowledge model is derived from the processes, and we start with one priority workflow. Where its process is not yet defined, AI Process Reengineering defines it first. Where the process is in place, the knowledge work can start on its own. When we build the automation of one process, the order is the process, the knowledge, the connections to systems through AI Connectivity, and then the skills, assistants and agents that use all three. That is the build order for one process. It does not describe a rollout across the company.
Short answers to buyers’ questions on capturing knowledge, RAG, enterprise search and ownership are in the FAQ on the AI Knowledge Base page.
