How to Capture Tribal Knowledge for AI Before Agents Use It

To capture tribal knowledge for AI, interview the people who do the work using real recent cases, write each answer as a short entry with a rule, a reason, exceptions and an owner, and have a second expert approve it before the agent can use it. The goal is not to record everything people know. It is to turn the judgment that lives in a few heads into reviewed context that an agent can apply and a human can audit.

Key takeaways

• Tribal knowledge is the unwritten judgment behind how work really gets done, and an agent cannot use what nobody has said out loud.
• Interview around real cases, not abstract questions. People describe what they actually do far better than what they think they do.
• Store each piece of knowledge as a small entry with a rule, a reason, exceptions, an owner and a review date.
• Nothing becomes agent context until someone other than the interviewee has checked it and the right owner has approved it.
• Capture is a routine, not a project. Knowledge that is not reviewed on a schedule becomes a confident source of wrong answers.

What counts as tribal knowledge, and why does an agent need it written down?

Tribal knowledge is everything your experienced staff know that your documents do not say. It is the reason one supplier gets a phone call instead of an email, the sign that a customer request is really a complaint, the exception that finance quietly allows, the step everyone skips because it no longer matters, and the one step nobody ever skips.

A new hire absorbs this over months by watching, asking and making small mistakes. An AI agent has none of that path. It works from the context you give it: instructions, documents, memory and tool access. If the judgment is not in that context, the agent will fill the gap with a plausible general answer. This is the pattern described in why ChatGPT gives generic answers about your business: the model is not ignoring your company, it has never been told about it.

There is also a control reason. Once knowledge is written down, it can be reviewed, corrected and removed. Knowledge that stays in someone's head cannot be audited, and knowledge that leaks into an agent through informal pasting cannot be traced. Capturing it deliberately is what makes it governable.

Which knowledge should you capture first?

Do not start with everything. Start with the knowledge that the first agent role will actually touch. If the role is order status and account questions, you do not need the history of the company. You need the rules for holds, substitutions, credit exceptions and who decides.

Use this decision guide to rank candidates:

• Capture first: knowledge that changes what the agent would say or do, and where a wrong answer reaches a customer or moves money.
• Capture next: knowledge that people ask the same experienced colleague repeatedly, because repetition shows it is both useful and undocumented.
• Capture carefully: knowledge involving personal data, legal positions, pricing logic or named individuals. It may need to stay out of agent memory entirely. See sensitive data in AI agent memory for what to exclude.
• Do not capture yet: opinions, gossip, workarounds for systems that are about to change, and anything the owner cannot confirm is still true.

A useful test is to ask what the agent would do wrong on its first week without this item. If the answer is nothing important, it can wait.

How do you interview an experienced employee for agent context?

The most common mistake is asking an expert to explain their job. They will give you the official version, which is already in a document. The unwritten part appears when you anchor the conversation to real events.

These techniques work reliably:

• Walk through a recent case. Pick something that happened last week and ask them to narrate it from the first message to the close. Stop at every decision and ask what they looked at.
• Ask about the last time something went wrong. Mistakes expose the rules that nobody wrote down because they were learned the hard way.
• Use the new hire question. Ask what a capable new colleague would most likely get wrong in the first month, and what you would tell them to prevent it.
• Ask for the exception. For every rule, ask when they would not follow it, and what tells them so.
• Climb the why ladder. When they say they always do something, ask why, then ask what would happen if they did not. Two or three levels down you usually find the real rule.
• Shadow, then confirm. Watch a few real tasks silently, note what they do that they did not mention, then ask about it afterward.
• Ask who they call. The people an expert consults when stuck show you where the real decision authority sits.

Interview in pairs when you can: one person asks, one writes. Keep each session on one task type so the notes do not blur. Record notes in the expert's own words first, and only afterward rewrite them into entries. Rewriting during the conversation tends to flatten the exceptions, and the exceptions are the valuable part.

Try to interview more than one person for the same task. Experienced staff often disagree on details, and the disagreement is information. Do not resolve it in the room. Log it and take it to the owner of the process.

How do you turn interview notes into a context entry?

Raw notes are not agent context. An entry should be small enough to be retrieved on its own and clear enough that a stranger could apply it. A reliable format has these fields:

• Situation: when this applies, in one or two sentences.
• Rule: what to do, stated as an instruction.
• Reason: why the rule exists. Agents handle edge cases better when they know the purpose.
• Exceptions: when the rule does not apply, and who can authorize it.
• Escalation: what the agent should hand to a human instead of deciding.
• Owner: the named person responsible for keeping it true.
• Last confirmed: the date someone last verified it against current practice.
• Sensitivity: whether it may appear in answers, in internal use only, or not at all.

Write in plain, concrete language. Replace "usually" and "normally" with the actual condition. Replace "talk to the team" with the role that decides. If the expert said "it depends", keep asking until you can list what it depends on.

One entry should hold one rule. Long narrative write-ups are hard to retrieve accurately and hard to review. If you are unsure how entries relate to your existing documents and records, the principle in how to give an AI agent a reliable source of truth applies: decide which system wins when two sources disagree, and say so in the entry.

How do you review and approve captured knowledge before the agent uses it?

Capture without review simply moves one person's assumptions into a system that repeats them at scale. Treat approval as a separate step with a separate person.

A practical review plan:

• Step 1: Read-back. Return the drafted entry to the interviewee and ask if it is accurate. Fix wording, not substance.
• Step 2: Second expert check. Ask a different experienced person to confirm the rule and the exceptions. Differences go to the process owner.
• Step 3: Conflict check. Compare the entry with existing documents, policies and other entries. Where they disagree, decide which is correct and retire or fix the other.
• Step 4: Sensitivity check. Remove personal data, credentials, private commercial terms and anything the agent should not repeat.
• Step 5: Owner approval. The named owner marks the entry approved, with the date. Unapproved entries stay out of the agent's reach.
• Step 6: Scenario test. Write a few realistic questions the entry should answer and check that the agent retrieves it and responds correctly. How to test retrieval quality in an AI knowledge base covers this in detail.
• Step 7: Schedule the next review. Pick a date and a trigger, such as a policy change or a supplier change, that forces an earlier check.

The last step matters most over time. Practices change, people leave, and an entry that was right once becomes a source of stale advice. A short recurring routine with named owners, as outlined in AI knowledge base maintenance: owners and a review routine, keeps the captured knowledge honest. Entries that nobody has confirmed for a long time should be flagged or expired rather than trusted by default.

One caution on framing. Approved context is still data the agent reads, not an authority that overrides its permissions. Approval boundaries for actions such as refunds, order changes or outbound messages belong in the agent's role definition and tool permissions, not only in a knowledge entry. Frameworks such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) emphasize assigned accountability and ongoing monitoring, which is the same logic applied here at the level of a single entry.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a real engagement. A regional wholesaler wants an agent to answer account and order questions. The most experienced person on the order desk, call her the desk lead, knows that a particular kind of delayed order should never get an automatic apology and a new delivery date. Instead, it needs a call from a named person, because those customers usually have a larger problem.

Nothing in the written procedures says this. In the interview, the interviewer asks the desk lead to narrate last week's delayed order. She mentions, almost in passing, that she checked the account notes before replying. Asked why, she explains that accounts flagged for contract renewal are handled differently. A second interview with an account manager confirms the flag but adds an exception: small accounts under a different arrangement can still receive the standard reply.

The resulting entry has a situation (delayed order on a flagged account), a rule (do not send a standard apology, route to the account manager), a reason (renewal risk), an exception (accounts under the other arrangement), an escalation path, an owner and a review date. The sales director approves it. A scenario test uses a flagged account, an unflagged account and an exception account, and all three are answered as intended. The agent now handles the case the way the desk lead would, and a person can see exactly why.

How does Be Human handle knowledge capture?

Be Human treats capture as part of defining the agent's role, not as a separate documentation exercise. In a first engagement we identify the one role to be filled, decide with you which knowledge that role needs, and run the interviews and reviews described here with your own experts. Entries are written with owners, sensitivity labels and review dates, and only approved entries become agent context. In managed operations, we help run the recurring review routine, check retrieval against scenario questions, and handle corrections and removals under your approval, so the knowledge stays under human control.

Frequently asked questions

How long should an interview about tribal knowledge take? Keep each session short and focused on one task type, so the notes stay specific and the expert stays engaged. It is usually better to hold several short sessions than one long one, with a review gap in between to correct the draft entries. The total effort depends on how many task types the first agent role covers.

Should we just record meetings and feed the transcripts to the agent? Raw transcripts mix opinions, outdated statements, personal details and contradictions, and they are hard to review or correct. Use recordings as source material for a person to turn into approved entries, not as agent context directly. If you do keep recordings, apply the same sensitivity rules you would to any other data.

What if experts disagree about the right way to do something? Treat disagreement as a finding, not a failure. Log both versions, take them to the person who owns the process, and let that owner decide, then record the decision and the reason. If the difference is genuinely a matter of judgment, write the entry so the agent escalates to a human instead of choosing.

How do we stop captured knowledge from going stale? Give every entry an owner and a last-confirmed date, and review entries on a schedule and whenever a related policy, supplier or system changes. Retire entries that nobody can confirm. For more on the failure mode, see how to stop stale context from misleading your AI agent.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.