What Is Tribal Knowledge? How to Capture It With AI (Examples + Checklist)

In my first week at Tenex, I spent two days building a Claude skill to answer one question: what happened here before I showed up? I wanted to know where things live, who decides what, and what in our Slack was worth turning into a story for our news series. In other words, I wanted access to Tenex’s tribal knowledge.

I tell the whole story in the video above.

Turns out, Alex already built it. He calls it the Content Machine, and it reads our Slack, Notion, email, and GitHub, pulls out the ideas worth sharing, links each one back to where it came from, and drafts content from them. It’s like a magic crystal ball I can call on any time I’m stumped, or have an inkling that this problem may have come up before.

Tribal knowledge is the know-how a company runs on that nobody wrote down. It covers why things are done a certain way, who actually approves what, which exceptions apply, and what, if anything, went wrong last time. Generally tribal knowledge doesn’t live in any one place. When someone leaves, much of that knowledge goes with them, and whatever they leave behind no longer has anyone to explain what it means.

In a 2025 SHRM survey of 1,912 HR professionals, 83% said their organizations document company policies, but only 32% document cultural norms and 43% document client relationships. Those are the areas they said would be hardest to rebuild if experienced people suddenly retired. When those people leave or are out, the people they work with are left trying to put the pieces together. What if there was a way to hold onto this knowledge and make it readily usable by anyone who needs it?

Below, we’ll take a look at examples of tribal knowledge, show how it differs from institutional knowledge, detail the five steps we use at Tenex to capture it with AI, and provide a one-page tribal-knowledge checklist. We’ll also share the free Claude skill we built for this.

Tribal knowledge examples

Tribal knowledge is usually small and specific, and not being able to access it causes real friction, especially for new hires or colleagues covering for someone who is OOO or has left.

Here are two typical cases:

• The real approver. The policy says a manager signs off on refunds, but everyone knows anything over $5k goes to CJ in finance.
• The billing exception. One account gets invoiced quarterly instead of monthly, because of a deal from two years ago that only the account lead remembers.

Tribal knowledge vs. institutional knowledge

Institutional knowledge is everything a company knows about how it operates. Tribal knowledge is the portion held by particular people or teams, often undocumented and difficult for others to access.

Lots of people use the two terms interchangeably, but there are real differences:

	Tribal knowledge	Institutional knowledge
What it is	Unwritten know-how held by a person or a small group	Everything the organization knows, written down or not
Where it lives	People’s heads, DMs, side threads, meeting chatter	Handbooks, wikis, SOPs, contracts
How you find it	Ask the right person, or dig up the traces it left	Search the docs, then ask a person
When someone leaves	It leaves with them	Whatever was written down is what remains
Example	“Anything over $5k goes to CJ”	The official refund policy page

Capturing tribal knowledge means moving it from the left column to the right one.

Why tribal knowledge is so fleeting

The question leaders bring us is some version of: “How do we make sure our company’s knowledge doesn’t walk out the door when someone leaves?” When nobody captures it, you pay in four ways:

• The departure cliff. Someone leaves, and the exceptions they handled, the reasons behind old decisions, and their client relationships go with them. You find out what they knew the first time something breaks.
• Slow onboarding. New hires don’t know what they don’t know (that’s my first week in one line), so they guess or interrupt people.
• The “go ask CJ” loop. The same few people answer the same questions over and over. Atlassian’s State of Teams 2025 survey of 12,000 knowledge workers found that leaders and teams waste 25% of their time just searching for answers.
• AI that can’t help. Your AI tools can only use what they can reach. If the real rules live in someone’s head, the assistant gives the policy-page answer, and it’s wrong.

Leaders now ask us how to make their business “legible to AI,” which means connecting their systems and writing down SOPs and tribal knowledge in ways that AI agents can easily access.

Once you do the legwork setting up MCP Connectors, AI makes building your knowledgebase a breeze. Any AI tool can read across Slack, Notion, meeting notes, and code in minutes, so finding tribal knowledge stops being a months-long documentation project. That’s the practical case for AI in knowledge management.

How to capture tribal knowledge in 5 steps

To capture tribal knowledge: connect where it lives, hunt for the traces it leaves, interview the people who hold it, source every claim, and (perhaps most importantly) set things up so new knowledge gets captured as it happens. AI can ingest fragments of information that exist digitally, and humans fill in what was never typed at all.

Step 1: Connect the places it lives

Company knowledge usually sits in five places: your messaging app (Slack, Teams), internal docs (Notion, Drive), meeting recordings and notes, fresh news (what the team is reading and sharing), and code (GitHub). I broke these down in How to Build a Claude Skill by Letting Claude Interview You.

Connect each one to your AI assistant. In Claude, these are called connectors. In my first week, connecting all of mine took “an arduous 15 minutes” (2:30 in the video). After that, Claude could search everything I’d connected, so I could stop tapping coworkers on the shoulder with questions that felt stupid.

Paste into Claude:

Before we start, list every source you can reach right now: chat, docs, meeting notes, email, code, and anything else. For each one, tell me in one line what kind of company knowledge is likely in it. Then tell me what's missing for a company like ours. Don't search anything yet.

How to tell it worked: Claude names each connected source. If one you connected is missing, start a new chat and check that the connector is turned on for it.

Step 2: Intentionally hunt for the traces and exceptions, not the “official” answer

Searching “refund policy” finds the official doc, which might be missing, out of date, or not what people actually do. Tribal knowledge leaves traces instead of answers: the same question asked by different people, exceptions, decisions that got reversed, “ask CJ,” workarounds, warnings, and docs that the chat history contradicts. I break down all seven kinds of traces in my skill post.

Paste into Claude:

I'm trying to understand [topic, e.g. how we handle refunds over $5k]. Don't search for the official answer. Look for the traces instead: the same question asked by different people, exceptions ("normally we do X, but"), decisions that got reversed, people others say to ask, workarounds, warnings, and docs that the chat record contradicts. Cover the last [12 to 18 months]. Link and date every finding. List what you couldn't find as gaps.

How to tell it worked: You get findings you didn’t already know, and each one has a link. If all you get back is the official doc, ask it to search for the questions people asked about the topic instead.

Step 3: Interview the people who hold it

A sweep of Slack and docs only finds what got typed somewhere. The judgment calls and the “never again” stories mostly don’t get typed. When we tried to piece together what happened on past client projects at Tenex from every Slack channel, meeting note, and repo, the sweep couldn’t replace a real debrief with the person who ran the work.

So let AI run the interview. It asks the follow-ups and writes it up, so the expert doesn’t have to start from a blank page. This is also what to do when someone gives two weeks’ notice: book an hour and run it before their last day.

Paste into Claude:

Interview me about [project or role] so the next person can pick it up without me. Ask one question at a time. Start with what I'd tell someone on day one. Then cover what went well, what went badly, what I'd do differently, the exceptions I handle from memory, and who I go to for what. Push for specific examples. When we're done, write it up as a handoff doc.

How to tell it worked: The handoff doc has specifics a new person could act on, like names, numbers, and “if X, do Y.” If it reads like a job description, tell Claude to ask for examples and run it again.

Step 4: Source every claim and name the gaps

Link every claim to where it came from. A claim with no source looks just as official as a real one. It gets copied into the next doc and turns into fake institutional knowledge.

Before anything goes into the doc:

• Read the thread to the end. A decision made in message three is often undone in message twenty.
• Date every finding. Something true in 2024 can be wrong today.
• Keep contradictions. If two sources disagree, show both. It means the team doesn’t actually agree, and someone should know.
• Turn dead ends into a name. If the answer is only in someone’s head, write down who and the exact question to ask them.

How to tell it worked: Every line in the doc has a link or is marked as a gap. If there are no gaps, you probably didn’t look hard enough.

Step 5: Capture it as the work happens, then make it askable

A one-time cleanup goes stale. What lasts is a few places where knowledge lands by default, during the work instead of after it. Point AI at those places, and anyone can ask a question instead of tapping a coworker on the shoulder. The next section shows the four we use.

Paste into Claude:

Have we solved something like this before? [Describe the problem.] Search our [meeting notes / project notes / memos]. Answer in plain language, link every source, and tell me who to talk to.

How to tell it worked: A new hire can answer “have we done this before?” on their own, with links. If the answer is thin, the capture habit isn’t happening yet. Go back to the database that should have caught it.

How we capture tribal knowledge at Tenex

At Tenex, tribal knowledge lands in four Notion databases as the work happens, and Claude reads across all four. We’re growing fast enough that nobody can keep the whole picture in their head, so we don’t ask anyone to.

System	What lands there	When it’s captured	Question it answers
Weekly memos	Each working group’s goals vs. actuals, decisions, open problems, and each pod’s action items	Before the weekly meeting, which starts with 5 minutes of everyone reading it	“What did we decide, and what’s off track?”
Meeting log	Every single meeting gets recorded for notes, summary, action items, and transcript, in one shared database	Right after the meeting	“What did CJ say during our brainstorm last week?”
Media Content database	Every video and article from idea to published: owner, status, publish date, why we think it’ll work, and the verdict	At each stage change	“Why did we make this, and how did it do?”
Field Notes	A long debrief for every client engagement: industry, tech stack, team type, and the full story	After the work, when Claude interviews the strategist who ran it	“Have we solved this before?”

Field Notes is the clearest example. Our strategists started out writing polished case studies, and those took too long. So they switched to a brain dump. Claude pulls the raw Slack threads and meeting transcripts first, then interviews the strategist about what went well, what went badly, and what they’d do differently.

The result is long on purpose, and Kabir Parekh, who built it, explained why in the video: “My goal for this is not for someone to read through this step by step. What I want is for people to connect their Claude instance, whether it be Cowork, Code, whatever, to Notion, and then they can point their Claude instance at Field Notes.”

When I saw Field Notes in my first week, I didn’t rebuild Kabir’s database. As I said in the video, “I don’t copy his system, I just need to copy the way he’s thinking about it.” Your company doesn’t need our four databases either. It needs one place where each kind of knowledge lands by default, and an AI that can read all of them.

Tribal knowledge capture checklist

Use this once to get started, then again any time someone gives notice.

Set up (once)

• List where your team’s knowledge lives: chat, docs, meetings, news, code
• Connect each one to your AI assistant using MCP Connectors
• Get into your company’s GitHub organization, if it has one
• Decide who can read the output and what stays out (pay, performance, HR)

Find what’s at risk (this week)

• Ask AI for the questions your team asks over and over
• Have AI list the “ask __” scenarios in public comms channels, and pattern match references to decisions in meetings which aren’t yet codified
• Find the docs everyone links to that haven’t been updated adequately

Capture it

• Run the AI interview with each person on that list, starting with whoever is most likely to leave
• Link and date every claim. Mark anything without a source as a gap
• For each gap, write down who to ask and the exact question

Keep it current (ongoing)

• Pick one place where each kind of knowledge lands: decisions, meetings, projects, client work
• Debrief at the end of every project, not just when someone leaves
• Ask a new hire to find an answer with AI alone. If they can’t, fix the gap

Someone leaving in two weeks? Skip ahead: list what only they know, then run the interview before their last day.

Make tribal knowledge findable

You don’t have to write everything down. You have to make sure the next person can find what the last person knew, with a link that proves it. Or, as I put it at the end of the video: “It doesn’t matter that it exists if you never knew it was there, or how to put it all together. So go find yours for yourself.”

Related reading

• How to Build a Claude Skill by Letting Claude Interview You: the hands-on version, including the seven kinds of traces and how to install the skill
• Building an AI-Native SDLC: how engineering teams turn tribal knowledge into shared skills
• What Do You Do With the Other 90%?: why reported AI gains say little about who’s contributing