Knowledge vs. Know-How: The Distinction Quietly Killing Your AI Agents

Why 95% of enterprise AI pilots fail isn’t a model problem. It’s a category error.

The gap nobody names

Most conversations about enterprise AI revolve around a single word: knowledge. We talk about knowledge bases, knowledge graphs, retrieval, RAG, fine-tuning on proprietary data. The implicit assumption is that if an AI agent knows enough about your business, it will do the right thing.

It won’t. And the reason is a distinction philosophers have drawn for decades, but that the AI industry keeps ignoring.

There are two kinds of knowing:

• Knowing-that — propositional knowledge. Facts, policies, documentation, data. Paris is the capital of France. Our refund policy allows returns within 30 days. Invoice #4521 is overdue.
• Knowing-how — procedural knowledge. The ability to actually perform a task correctly in context. Riding a bike. Closing a deal. Processing that overdue invoice the way this specific company expects it to be processed.

Gilbert Ryle called this the difference between “intellectual” and “practical” knowledge. Michael Polanyi called the practical kind “tacit knowledge” — the things an expert knows but can’t fully write down. Call it whatever you like. The point is: knowing the facts of a job is not the same as knowing how to do the job.

And right now, most enterprise AI investments are buying the first and expecting the second.

Why this matters for agents, specifically

For chatbots, the knowledge/know-how gap was tolerable. A chatbot that knows your policies but doesn’t know how to apply them is still useful — a human reads the answer and decides what to do.

Agents change the equation. An agent isn’t answering questions; it’s taking actions. It’s sending the email, updating the CRM, approving the expense, filing the ticket. The gap between knowing and doing stops being philosophical and becomes operational. A knowledge-rich, know-how-poor agent is a confident employee who’s read the manual but has never done the job. That’s not an asset. That’s a liability with API access.

This is, empirically, what’s happening. MIT’s 2025 NANDA study found 95% of enterprise AI pilots deliver zero measurable P&L impact. S&P Global reports 42% of companies abandoned most AI initiatives in 2025, up from 17% the year before. The headline explanation is usually “context” — but “context” is a vague word that blurs the real issue. The missing context isn’t more documents to retrieve. It’s the procedural, tacit, institutional know-how that tells an agent how this company actually does this task.

What know-how looks like in practice

Consider a real example. A project manager prepares a weekly executive briefing. The documents are available. An LLM can read them. A knowledge-based system can retrieve them on demand.

But the actual job requires know-how the documents don’t contain:

• Which items count as a “key decision” for this leadership team (not the textbook definition)
• Who has sign-off authority on what — and the unwritten exceptions
• How to phrase a risk flag so the CFO takes it seriously without triggering a fire drill
• Which stakeholders get pre-briefed before the meeting, and which get the synthesis after
• The format conventions that have evolved over eighteen months of feedback

None of that is in a document. It’s in the PM’s head. It’s in the patterns of past briefings. It’s in the tone of last quarter’s Slack thread. It’s how the work actually gets done here — and it’s precisely the layer that generic AI agents, no matter how capable the underlying model, cannot access.

The category error executives are making

When AI initiatives stall, the instinct is usually to buy more of the same category. More documents indexed. Better retrieval. A bigger model. A more sophisticated RAG pipeline. Occasionally, fine-tuning — at $10K–$35K per model, plus data scientists in a tightening talent market.

This is rational if the problem is knowledge. It’s the wrong prescription if the problem is know-how.

Know-how doesn’t live in documents. It lives in procedures, constraints, exceptions, judgment calls, and role-specific conventions. And it doesn’t generalize — the way your compliance team handles an exception is not the way your sales ops team handles an exception, even inside the same company. Packaging know-how means encoding not just what to do, but how this team, in this role, under these constraints, wants it done.

That’s a different kind of asset than a knowledge base. It needs to be:

• Procedural — describing a sequence and its exceptions, not just facts
• Role-bound — tied to who’s doing the work, not just what’s being done
• Composable — so one piece of know-how can be reused across agents and contexts
• Auditable — so when the agent acts, you can trace the reasoning back to the instruction

Why this is skilder’s starting point

We don’t think the current AI stack is broken. We think it’s incomplete. Models have become astonishingly capable. Tool-calling standards like MCP have made connectivity tractable. What’s missing is the layer between the two — the layer that turns generic capability into this company’s way of working.

That’s what we build. We package know-how into what we call Hats — role-based bundles that capture how a specific job gets done in a specific organization. An agent puts on a Hat the way a new hire steps into a role: it inherits the procedures, the constraints, the exceptions, and the judgment calls that define competent work in that seat. One agent can wear multiple Hats and shift between contexts. One Hat can be worn by many agents, so know-how compounds instead of fragmenting. And because Hats are decoupled from any specific model, the same know-how works across Claude, GPT, Gemini, or whatever comes next.

The shift, if you zoom out, is this: enterprises spent the last three years buying knowledge for their AI. The next three will be spent teaching it how to work.

The Takeaway

If your AI pilots are stalling, the diagnostic question isn’t “does our agent have access to enough information?” — it’s “does our agent know how we actually do this job?”

Knowledge gets you a well-read intern. Know-how gets you a trained employee. The difference, in production, is the difference between a demo and a deployment.