"The knowledge that makes an expert irreplaceable is almost never the knowledge they think makes them irreplaceable. The visible expertise: the frameworks, the models, the tools: is the part that gets documented. The invisible expertise: the judgement, the pattern recognition, the instinct for which rule to break and when: is the part that makes the difference. That is exactly what you are trying to extract."
Chapter 26 gave you the architecture. You understand what a SKILL.md is, what the Agent Skills Pattern produces, and how the three components of a Cowork plugin fit together. You could, at this point, open a text editor and begin writing a SKILL.md for your domain. Most people who try that produce an agent that is roughly useful in obvious situations and unreliable in the ones that matter.
The reason is not a formatting error or a misconfigured connector. It is the problem that sits at the heart of every domain agent deployment and that no platform, no model improvement, and no prompt engineering technique can solve on its own: the knowledge that makes an agent genuinely useful in a professional domain is not the knowledge that is easy to articulate. It is the knowledge that professionals have spent years accumulating precisely because it resists articulation.
This lesson introduces the problem that the rest of the chapter solves. By the end, you will understand why tacit knowledge is the bottleneck, why the articulation gap makes it resistant to naive documentation, and why the Knowledge Extraction Method exists as a structured response to both.
Consider what a senior credit analyst at a bank actually does when she looks at a loan application. She reads the financials. She checks the debt service coverage ratio, the loan-to-value, the sector exposure. All of that is documented methodology: the kind of knowledge that anyone can learn from a textbook, a compliance manual, or a credit training programme.
But the thing that makes her judgement valuable: the thing her junior colleagues are trying to absorb by sitting next to her for eighteen months: is the pattern she recognises in the gap between what a set of financials says and what it implies. The company with clean accounts and a CEO who cannot answer a direct question about working capital management. The sector that looks stable on the headline data and is quietly being repriced by a supply chain shift that has not hit the reported numbers yet. The covenant that looks standard but has been structured in a way that will matter in a stress scenario.
None of that is in a textbook. Almost none of it is written down anywhere. It lives in the analyst's head, accumulated through years of deals that went well and deals that did not.
The distinction the credit analyst illustrates is the distinction between explicit and tacit knowledge. The terms come from the philosopher Michael Polanyi, and the distinction has been studied extensively in organisational knowledge management since Nonaka and Takeuchi's work in the 1990s. For the purpose of this chapter, the distinction is practical rather than philosophical.
Explicit knowledge is knowledge that can be articulated, documented, and transferred through formal channels. The credit analyst's documented methodology is explicit. The bank's credit policy manual is explicit. The regulatory requirements for debt service coverage ratios are explicit. If you can write it in a policy document and a competent professional can follow it, the knowledge is explicit.
Tacit knowledge is knowledge that professionals hold but cannot easily express. It is accumulated through experience rather than instruction. The credit analyst's ability to sense that a set of financials tells a different story from the one it appears to tell is tacit. Her instinct for which covenant structures will matter under stress is tacit. Her calibration of when to escalate and when to proceed, not based on a documented threshold, but on a pattern she has seen before and recognises, is tacit.
The relationship between the two types is not symmetrical. Explicit knowledge is necessary but not sufficient. Tacit knowledge is what makes the difference between competent and expert, between reliable and genuinely valuable.
Knowledge Type
What It Contains
Where It Lives
How It Transfers
Explicit
Documented methodology, procedures, regulations, frameworks
Policy manuals, training programmes, textbooks
Formal instruction: can be taught from a document
Tacit
Judgement, pattern recognition, calibration, exception handling
Expert heads, accumulated through experience
Apprenticeship: absorbed through proximity over time
Asking the credit analyst to describe her tacit knowledge is like asking someone to describe how they ride a bicycle. The moment they try to articulate the unconscious adjustments: the micro-corrections of balance, the anticipatory lean into a turn, the constant recalibration of speed against terrain: the description is both incomplete and slightly wrong. The knowledge is real. The performance is reliable. But the verbal account of it does not capture the operational reality.
This is the articulation gap: the structural barrier between what an expert knows and what they can express when asked to describe it. The gap is not a communication failure. It is a property of tacit knowledge itself. The knowledge is encoded in neural patterns shaped by thousands of specific experiences, not in propositional statements that can be dictated and transcribed.
The articulation gap has three specific consequences for SKILL.md authorship.
The first is that experts asked to describe their expertise default to describing the explicit component. The credit analyst, asked what she does, will describe the documented methodology: the ratios she checks, the frameworks she applies, the regulatory thresholds she monitors. This is the official version of her expertise: accurate, but incomplete. The tacit component: the pattern recognition, the exception instinct, the calibration: remains below the surface because she has never needed to articulate it.
The second consequence is that when experts do attempt to describe their tacit knowledge, the description is typically too abstract to be actionable. "I look for inconsistencies in the narrative" is a genuine description of what the analyst does, but it is not specific enough to produce reliable agent behaviour. Which inconsistencies? In which parts of the narrative? How does she distinguish a meaningful inconsistency from normal variation? The specificity that makes her judgement valuable is precisely the specificity that resists articulation.
The third consequence is that a SKILL.md written from the expert's self-report (without structured extraction) encodes the explicit knowledge faithfully and the tacit knowledge poorly or not at all. The resulting agent can recite the documented methodology. It can apply the standard frameworks. It can check the ratios. But it cannot recognise the pattern in the gap between what the financials say and what they imply, because that pattern was never surfaced, specified, and encoded in the Principles section.
The distinction between a SKILL.md written without extraction methodology and one written with it is the difference between an agent that paraphrases general knowledge about a domain and an agent that reasons the way a specific expert in a specific context actually reasons. For simple queries, both agents look similar. For the queries that matter: the edge cases, the ambiguous situations, the moments where generic advice is actively misleading: the difference is the entire value proposition.
This is not a theoretical concern. It is the failure mode that appears in the majority of first-draft SKILL.md files. The author, typically a domain expert with genuine expertise, sits down and writes what they know. What they produce is a description of their explicit knowledge: thorough, accurate, and insufficient. The tacit knowledge that makes their judgement valuable remains unextracted, because no one asked the questions that would surface it.
The Knowledge Extraction Method is designed for exactly this problem. It is a structured process for surfacing tacit professional knowledge and translating it into the explicit, testable agent instructions that produce consistent, reliable outputs in a Cowork deployment. It has two modes.
Method A: The Expert Interview Framework is used when the knowledge lives primarily in the heads of experienced professionals. It applies to domains where the most important expertise is tacit: the financial analyst's risk calibration, the lead architect's coordination judgement, the compliance officer's instinct for which contract clause deserves more scrutiny than its surface reading suggests. Method A is structured around five questions that reliably surface the three kinds of tacit knowledge a SKILL.md needs: decision-making logic, exceptions and edge cases, and escalation conditions. The next two lessons teach Method A in full.
Method B: The Document Extraction Framework is used when the knowledge lives primarily in documents: policy manuals, compliance frameworks, standard operating procedures, clinical protocols, legal guidelines. The fundamental challenge with documents is not finding them: it is reading them correctly. Method B uses a three-pass extraction process that surfaces the contradictions, gaps, and decontextualised rules that naive document reading misses. Lesson 4 teaches Method B.
For domains where knowledge lives in both heads and documents (which is most professional domains) both methods are applied, and a reconciliation step resolves conflicts between expert judgement and written standards. Lesson 5 teaches the choosing and combining process.
Both modes produce the same output: a well-structured SKILL.md that encodes something worth encoding. The lessons that follow teach each mode in the detail required to execute it, and the final lessons of the chapter teach the validation process that takes a first-draft SKILL.md to production readiness.
Use these prompts in Anthropic Cowork or your preferred AI assistant to deepen your understanding of this lesson's concepts.
What you're learning: The tacit/explicit distinction is not abstract when applied to your own expertise. This exercise trains you to recognise where your professional knowledge is explicit (and therefore easy to encode in a SKILL.md) and where it is tacit (and therefore requires the structured extraction that the rest of this chapter teaches). The follow-up questions preview the interview technique in Lesson 2.
What you're learning: The articulation gap is a property of tacit knowledge, not a communication failure. By examining it through a non-professional example first, you build an intuitive understanding of why the gap exists before applying it to professional contexts. The credit analyst parallel connects this understanding directly to SKILL.md authorship.
What you're learning: The cost of the articulation gap is not theoretical: it manifests as specific, predictable failure modes in deployed agents. By analysing these failures concretely, you build the case for structured extraction that the rest of the chapter delivers. This analysis also previews the validation scenario categories you will learn in Lesson 7.
The knowledge that makes a domain agent genuinely useful is tacit: it resists articulation because it operates below conscious awareness. No platform improvement, model upgrade, or prompt engineering technique solves this without a structured extraction methodology. The articulation gap: the structural barrier between what an expert knows and what they can express in written instructions: is the fundamental problem the Knowledge Extraction Method exists to solve.
📋Quick Reference
Access condensed key takeaways and quick reference notes for efficient review.
Free forever. No credit card required.