Tribal knowledge is the silent killer of AI adoption

When an AI agent stalls partway through one of your workflows, the instinct is to blame the AI. It’s the wrong instinct. Nine times out of ten the model is fine, and what actually broke is that the step it reached has no real instructions, only a habit. Somebody on the team knows what to do here. They’ve never written it down, because they’ve never had to.

That’s tribal knowledge, and it’s quietly the biggest thing standing between most companies and any useful AI deployment. Picture a step that says “review and route appropriately.” A person who’s done the job knows “appropriately” means escalate anything over fifty grand to legal, send the mid-size stuff to the regional lead, and sit on the whole thing until January if it lands in the holiday freeze. None of that is written anywhere - not in a Confluence page, not in a Slack pin, nowhere an agent could go looking. They learned it by osmosis, one correction at a time. The agent gets six words and a dead end.

So the fix isn’t a better model. It’s finding the steps that secretly mean ask Bob, and writing down what Bob actually does, before you put any AI near the workflow. This is what AI actually needs from a business before it can help, and almost nobody sequences it right.

Why the agent can’t ask Bob

Here’s the mechanical version. An agent moves through a process by calling tools and reading instructions. When it hits a step, it needs two things: a clear description of what “done” looks like, and the tools to get there. A step that really means “use your judgment, or go ask the person who’s done this for ten years” gives it neither. There’s no ask_bob function. The judgment the step depends on lives in Bob’s head, and Bob’s head isn’t wired to anything.

This is why so much of the agent hype curdles on contact with real work. Back in early 2025 a Hacker News thread asked for real examples of AI agents doing work, and the most honest answer in the room was a shrug. The thread’s author, nomad-nigiri, pointed out that most “agents” sounded like workflow automations that had existed forever, and a commenter going by AznHisoka cut straight to it: replace the word “agent” with “algorithm” and the magic evaporates. Genuinely autonomous examples were thin on the ground, and they were thin for a specific reason. The hard parts of real jobs are tacit.

Tacit knowledge is a real concept, not a metaphor. It’s knowledge that’s hard to extract or articulate, the kind you find easier to demonstrate than to explain, like recognizing a face or knowing when bread dough feels right. The philosopher Michael Polanyi pinned the whole problem down back in 1966, in a line worth taping to your monitor: we can know more than we can tell. The thing is, most of how your operation actually runs is exactly this. It lives in the people, not the wiki. And that’s the part an agent simply can’t see, no matter how capable the model gets, because there’s nothing for it to read.

Think about the senior claims processor who glances at a file and “just knows” it needs a second look. Ask her why and you’ll get “I don’t know, something about the dates felt off.” She’s right four times out of five, and she cannot tell you the rule, because there isn’t one she could write down. That instinct is twenty years of pattern-matching compressed into a feeling. It’s enormously valuable and completely invisible to a machine. When you point an agent at her workflow, it sails right past the file she would’ve flagged, because the step that mattered was never a step. It was her.

Can your best process survive its expert taking a two-week vacation, let alone leaving for good?

An agent is the cheapest audit you’ll ever run

This is the part that turns the whole thing from a complaint into a plan. Pointing an agent at a workflow is the fastest way to find every undocumented decision in it. The agent doesn’t get embarrassed, doesn’t fill gaps from memory, and doesn’t quietly route around the missing instruction the way a polite new hire would. It just stops at the exact spot where the real process was never captured.

Every stall is a flag planted on a piece of tribal knowledge.

So run the experiment on purpose. Take your top three workflows, the ones you’d most want an agent to help with, and walk an agent through each one. Count the stalls. Each stall is a step where somebody has been carrying the process in their head, and that count is your honest documentation backlog. Which three would you hand an agent first? Whatever you just pictured, that’s where the buried knowledge is densest, and it’s usually a higher count than anyone guesses going in.

A stall doesn’t look dramatic. It looks like the agent asking a question it shouldn’t have to ask, or confidently doing the wrong thing because the step gave it no way to be right. Watch a “process invoices” workflow and the agent breezes through the mechanical parts, then freezes at “approve if it looks reasonable.” Reasonable compared to what? The agent has no benchmark, so either it stops and asks, or it guesses and you find out at month-end. Each of those moments is a decision your team has been making on autopilot, never once writing down the rule. A short workflow can hide three or four of these; a real cross-department process can hide twenty.

We had this backwards for a while ourselves. Early on we assumed the agent would be the bottleneck, and it almost never was. The bottleneck was the dozen small decisions nobody had ever bothered to make explicit. The broader cost of all that undocumented know-how, the part that hurts when people leave rather than when agents arrive, is the subject of our longer piece on capturing tribal knowledge. This post is the AI-deployment corner of the same problem.

Make the tacit explicit

Finding the ask-Bob steps is half the job. Writing them down properly is the other half, and most teams do it badly because they reach for a wiki. A wiki is where knowledge goes to be ignored. Somebody writes a page, nobody reads it, it goes stale, and within a quarter it’s a clunky, misleading relic. We’ve made the case against that pattern at length in the tribal knowledge piece, so I won’t relitigate it here. The short version: a document nobody runs rots.

The version that works treats the process itself as the document. GitLab is the loud public example. They run handbook-first, which means a decision or a process gets written into one shared, authoritative place before it gets acted on, not after. Their own framing is blunt: avoiding structured documentation “is the best way to instill a low-level sense of chaos and confusion that hampers growth across the board.” The discipline isn’t documenting for its own sake. It’s making the implicit rule visible so the next person, or the next agent, doesn’t have to go find Bob.

The point was never the documentation itself, it was getting the rule out of one person’s head and into a place anyone can find it.

For an AI agent, “visible” has a precise meaning. An escalation rule has to be a real condition, not a vibe. The acceptance test has to be checkable. Each step’s owner has to be a role, not a name you happen to know. Get the decision out of someone’s head and into the step, and basically the agent has something to follow. So does the new hire, which is the quiet bonus you weren’t expecting.

Go back to that claims processor for a second. “It felt off” can’t survive contact with a machine, but it can be interrogated into something that can. Sit with her for an hour and the feeling usually decomposes into a handful of real triggers: the claim amount jumped more than thirty percent versus the customer’s history, the dates don’t line up, the provider is one she’s seen flagged before. None of those are mystical, they were just never asked out loud. Write them down as conditions and the “instinct” becomes a rule a person can audit and an agent can check. You won’t capture all of it, and that’s fine, but capturing most of a decision that currently lives in one head beats capturing none of it, every time.

Document first, then deploy

The sequence matters more than anything else here, so let me make it boring and explicit. You document the ask-Bob steps. Then you deploy the agent. Not the other way around, and not both at once.

Teams get this backwards constantly, and you can see why. Documenting feels like overhead, and the AI demo feels like progress, so the demo wins and the documentation gets a someday. Then the agent goes live, hits the undocumented decisions, and the project quietly dies, filed under “AI didn’t work for us” when the real story was “we never finished writing down how we work.” Point an agent at a messy, half-improvised process and you get a sloppy result faster, plus a convenient scapegoat. So why does the AI take the blame when the process was the thing that was never finished?

We’ve watched this play out enough times to expect it now. The week a team actually tries the audit, the uncomfortable discovery is that the process they were proud of turns out to be mostly improvised. That’s not a failure. It’s the most useful thing the agent will ever tell you, and it’s free. The same muscle that documents a process well is the one employers keep asking new graduates to build, because clarity under ambiguity is rare and valuable whether the next worker is a person or a model.

The blunt version of where we land will annoy anyone selling autonomous everything: a fully autonomous agent turned loose on real operations is a dead end. Not because the model is weak, but because real operations are full of these unwritten judgment calls, and an unsupervised agent will confidently get them wrong, faster than anyone can catch. The move that actually works is the unglamorous one. Gate the AI inside a process you’ve defined, hand it the bounded steps where its judgment genuinely helps, and keep a person on the decisions you never managed to write down. The agent gets sharper exactly as your documentation gets better. That’s a far healthier dependency than hoping a bigger model will somehow read your team’s collective mind.

The causal arrow runs one way: clearer process, better agent, never the reverse.

This is the through-line behind why your AI agent needs a workflow engine and why a RAG system isn’t really an agent either: in every case, the AI is only as good as the process you can actually hand it. The structure isn’t a constraint on the intelligence. It’s the thing that lets the intelligence touch real work at all.

Find your ask-Bob steps

Pick the workflow you most wish an agent could run. Spend an afternoon walking it step by step and mark every place where the honest answer is “well, it depends, you’d ask Sarah.” Those marks are your map. Turn each one into a written rule with a real condition and a clear owner, and you’ve done the genuinely hard work that any AI deployment was going to demand of you anyway.

Do it with the person who actually owns the work in the room, not from a conference table. The marks land in different places than managers expect, because the real decisions hide in the gaps between the official steps. You’ll hear “oh, and then I usually check whether…” a dozen times, and each one of those is a buried rule you’re about to recover. Write it as you hear it. Don’t polish it into corporate prose; capture the actual condition the person uses, in plain language, while they can still tell you. That afternoon is worth more than the next model upgrade, and unlike the model upgrade, it’s entirely in your control.

Tools help here, but only after the thinking. A platform like Tallyfy keeps the process living and run, so the documentation stays current because people are using it, not because someone remembered to update a page. Don’t spin up an agent first and hope it teaches you your own operation. Get one process out of people’s heads and into a shape you could hand to anyone, build the documented process first, and the agent can wait a week. It’ll run a lot better when it gets there.