How to capture tribal knowledge before you deploy AI agents

AI agents do not need your most experienced people to write a giant SOP. They need the judgment those people use when the SOP runs out. When someone says, "I've been selling this product for 20 years," the next sentence often contains the rule an agent cannot read anywhere else.

We saw the cost of that gap on a manufacturing quoting project. A rep had to work from more than 50 machine brochures in SharePoint, alongside the call transcript and the customer's requirements. The first chat version produced a good answer for one example and broke on the next four. The useful agent needed the product library, explicit guardrails, and a human reviewer who could judge the recommendation.

That is why connecting an agent to HubSpot, SharePoint, or an ERP is only the start. The systems hold records. Your experienced people carry the conditions, exceptions, and tradeoffs that tell them how to use those records. Before you automate a high-skill task, you have to extract that context in a form the agent can follow and the expert can challenge.

Tribal knowledge is a trail of decisions

Tribal knowledge becomes usable by an AI agent when it is turned into explicit, testable decisions connected to source material. It is not a page of general advice or a prompt that says, "think like our best salesperson."

Start with a real piece of work that an experienced person has already completed. Ask them to walk through the decision, not to describe their job in the abstract. A quote, a renewal, a qualification call, or a deal handoff gives the conversation something concrete to hold onto.

Capture	What the agent needs to know
Trigger	What event starts this decision, and which record or transcript should the agent read first?
Inputs	Which facts, documents, and product rules are authoritative?
Decision rule	What signals lead to one recommendation instead of another?
Exceptions	Which cases look normal but require a different path?
Review boundary	What can the agent prepare, and what must a person approve or decide?

The table is deliberately small. If an expert cannot point to the source behind a rule, the agent should not treat it as settled fact. That is how you stop a useful shortcut from becoming a confident guess.

Do not ask experts to document themselves out of a job

The wrong request is, "Write down everything you know so we can automate it." People hear a replacement plan, and they are right to be cautious. Their contribution is not just a set of steps. It is knowing which steps matter when the facts do not line up.

The better request is to make that judgment visible and reviewable. In the quoting project, the rep did not disappear from the process. The agent assembled a recommendation from the transcript and the brochure library; the rep reviewed the proposed machine and the quote. Research moved from the rep's memory into a repeatable system. Accountability for the decision stayed with the person who understood the customer and the product.

This changes the conversation. You are not asking an expert to hand over their value. You are asking them to define the work they should no longer have to repeat, and the cases where their judgment should still lead.

Test the context against live work

The test is not whether the knowledge document sounds sensible. The test is whether an agent can apply it to a real record and show its reasoning clearly enough for an expert to correct it.

Begin with a narrow set of examples. Let the agent prepare an output, show the sources it used, and state where it was unsure. Then compare its result with the expert's decision. When the expert corrects it, update the rule, the exception, or the source list. This is how context improves without pretending that one workshop will capture 20 years of experience.

It also gives you a meaningful review loop. A reviewer should be able to inspect the decision, not just click approve on work they cannot evaluate. We have written before about treating an AI agent like a new hire: it needs scoped access, context, and a review process that a human can genuinely supervise. That onboarding discipline matters here too.

Knowledge extraction belongs in the agent build

AI projects often start with a model choice or an integration plan. They should start with one repeated decision that matters, the person who makes it well, and the evidence they use to make it. The model can come later.

Pick one task this week. Sit with the expert while they work through a live example. Record the inputs, the rule, the exceptions, and the point where they would take over. You will have the beginning of an agent specification, and the expert will have a clearer role in making it safe.

FAQ

What is tribal knowledge in an AI project?

Tribal knowledge is the unwritten judgment people use to interpret records, choose between options, and recognize exceptions. For an AI project, it includes the sources to trust, the decision rules to apply, and the situations where the agent must stop for human review.

Why can an AI agent not learn tribal knowledge from a CRM alone?

A CRM can provide the records an agent reads, but it does not reliably contain the conventions and exceptions people apply to those records. An agent needs those rules connected to authoritative sources, or it may fill gaps with a plausible but unsupported answer.

How do you document expert judgment for an AI agent?

Use real examples and record the trigger, authoritative inputs, decision rule, exceptions, and review boundary for each decision. Test the result on more live work, then revise the context when the expert finds a missing rule or a case the agent should escalate.

Will documenting tribal knowledge replace the expert?

It can remove repeated research and preparation, but it should make the expert's judgment easier to apply and review. The expert remains responsible for defining the boundaries, correcting the system, and handling the cases that do not fit the rule.