The Knowledge Is Not in the System. It Is in People's Heads.
The budget was approved. The tools were purchased. The accounts were provisioned. The vendor ran two rounds of demos. Three months later, the organization looks back and realizes AI has not actually taken over a single thing.
This pattern has a real cause that managers tend to reach last. The model is not too weak. The employees are not resisting. The problem is that AI has no idea how this company's work actually runs. It does not know how many exception paths your refund approval process has. It does not know how the sales director evaluates a prospective client. It does not know why certain contracts received a discount and others did not. None of that is in any system, any document, or anywhere AI can read — it is in employees' heads, in chat message threads, in things a senior colleague told you once over coffee.
YC's 2026 Request for Startups named this directly: the biggest blocker in AI adoption is not technical capability, it is domain knowledge. Every company has critical know-how scattered across emails, tickets, spreadsheets, and the individual minds of its employees. AI cannot reach any of it.
Tom Blomfield — co-founder of Monzo, the UK digital bank, and subsequently a partner at YC — described the solution as the "company brain": a system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into executable skills files for AI. Not a static document library, but a living map of how the company actually works — how refunds get handled, how pricing exceptions get decided, how engineers respond to incidents. His underlying logic, as he has articulated it publicly: what is recorded happened to the AI — and what is not recorded simply does not exist from AI's perspective. A veteran employee who intuitively knows that a certain client category should never get a discount beyond a certain threshold, or who can tell when a candidate will not fit the team — if those judgments live only in intuition, AI has nothing to work with. Not because AI is incapable, but because it has no raw material.
This is not a comfortable problem to sit with. Extracting employee know-how operates on three levels. The technical level is about converting tacit knowledge into machine-readable structures. The methodological level is about which nodes are worth extracting and in what priority order. The negotiation level is whether employees have any incentive to participate, and whether the organization has designed a credible mechanism to make participation worthwhile. Leave all three unsolved and the company brain remains a concept on a slide — or worse, produces data that looks organized on the surface but has been hollowed out of the knowledge that matters.
An organization's AI learning capacity has an upper limit: its recording capacity. This is how YC's 2026 RFS frames it, and it is the wall that every manager serious about AI adoption will eventually run into. Seeing the wall clearly is the prerequisite for understanding what has to be dismantled.
The manager's first check: this week, find the person on your team who is best at their job, and ask them one question: "When you make that judgment call, does it get recorded anywhere in the system?" If the answer is no, you have just located the first gap in your company brain.
What Know-How Is, and Why It Is So Hard to Extract
When managers talk about "extracting employee experience," the word "experience" is too vague to be useful — so vague that the extraction effort goes sideways from the start.
Scholar and practitioner Fang Shentao, in his book on organizational leadership (Chief Organizational Officer, in Chinese), applies a three-layer classification of employee knowledge to the organizational context — a framework widely used in organizational-learning literature — as follows. Know-what: knowing what something is, understanding the facts and concepts, the cognitive foundation. Know-how: knowing how to do something, the skill dimension, deeply correlated with practice and accumulated experience, the layer that actually produces results. Know-why: knowing why something works, understanding the underlying principles, the basis for inference and innovation.
Of the three, know-how is the hardest to learn, the hardest to transfer, and the hardest for machines to directly replicate. Know-what can be acquired through reading and memory. Know-why can be reached through reasoning and synthesis. But know-how cannot be shortcut — it is bound to long practice, and no amount of study substitutes for having done the work enough times. An interviewer's ability to read whether a candidate will perform is not built from having read recruitment manuals. It is built from having assessed hundreds of people. That pattern recognition has no instructable version. You develop it only by having done it.
In organizational settings, know-how carries an additional difficulty: it transfers poorly. The same performance management approach that runs well in one company can fail in another with a sufficiently different culture. Not because the approach is wrong, but because organizational know-how is embedded in its specific context. Remove it from that context and it loses the conditions it needs to work.
This explains why "just get the documentation right" does not solve the problem. Documentation primarily captures know-what — rules, processes, policies. Know-how resists documentation because its core is "in this kind of situation, what does experience say to do?" — and the contextual dependence, accumulated experience, and judgment logic inside that are extremely difficult to communicate in writing.
Here is the critical shift that AI introduces. Generative AI has dramatically lowered the cost of acquiring know-what and know-why — you no longer have to read every source, the model summarizes; you no longer have to reason through every principle, AI can derive it. Know-what used to be a senior employee's advantage. It is already being equalized. But know-how is different. Real organizational judgment capacity is still embedded in experience, still requires practice to develop.
AI has not eliminated know-how. It has made it scarcer. This is the philosophical foundation of this chapter: extracting know-how matters not only because it is scattered across individuals, but also because in the AI era it has become the increasingly scarce asset in the organization — the part that humans genuinely have over machines, the part machines cannot directly copy. Precisely because of that, it has become the most worth structuring, preserving, and transmitting.
For managers: before designing a knowledge extraction mechanism, get clear on which layer of knowledge you are actually trying to extract. If the primary target is know-what — processes, rules, policies — a well-structured document library is sufficient. If the target is know-how, the method is different: not asking employees to write manuals, but making their judgment structures explicit so machines can learn "under what conditions, based on what reasoning, did they make this call?" The gap between these two approaches is larger than most managers expect.
Where to Start — Process Decomposition to Find the Highest-Density Nodes
Knowing that know-how is what needs extracting, the natural next move is "bring in the most senior employee for an interview." That will probably produce nothing useful — not because the employee will not cooperate, but because you will not know what to ask.
The first step in extracting know-how is not interviews, not training, not asking employees to write experience summaries. It is pulling the workflow apart: what stages does this role's work go through, what type of judgment does each stage require, and which nodes have the highest knowledge density? Only after answering these questions do you know what to go after.
A counterintuitive finding: the nodes where AI is easiest to deploy are usually not the nodes where employee knowledge is most valuable. Information lookup, standard responses, form completion — AI can handle these efficiently, and whatever "experience" employees have accumulated here is not particularly valuable. The know-how worth extracting is concentrated in the nodes with high complexity, high stakes, and low standardization — deciding how to handle an anomalous situation, evaluating which path a borderline case should take, making a call when signals conflict. Those are precisely where AI's potential to intervene is lowest, and where the density of human judgment is highest.
This means the priority ordering for extraction should be inverted: the hardest things to automate are often the most worth structuring.
Using three dimensions — task complexity, risk level, and degree of standardization — to analyze each workflow node gives a workable picture: low complexity, low risk, high standardization nodes have high AI entry potential but low know-how extraction value; high complexity, high risk, low standardization nodes have low AI entry potential but are exactly where employee know-how is most concentrated, making them the highest-value targets for extraction investment.
A practical recommendation: before starting any knowledge extraction initiative, build a process map. List every work node for this role. Then ask two questions at each node — is this node currently handled by AI? How serious are the consequences if this node produces the wrong result? Any node that is both "not yet handled by AI" and "serious consequences if wrong" is where know-how density is highest. That is where extraction work should start.
The manager's first move: take the role you most want AI to take over, break its workflow into five or more nodes, and ask at each one: if AI makes an error here, who is responsible and how serious is it? Any node you cannot answer that question for is the highest-risk point in this role's AI transition.
Writing Know-How Into an Agent — Externalizing Judgment Structure, Not Writing a Manual
Once the high-density know-how nodes are identified, the next question is: how do you convert them into something machines can actually learn?
Most managers at this point conduct interviews — ask senior employees to present in meetings, have HR take notes, compile experience handbooks or training materials. That path is not without value, but it has a fundamental ceiling: handbooks capture know-what, not know-how. Employees can describe what they did; they cannot fully describe why they judged it that way, or under what conditions they would have judged it differently.
Structuring know-how into an Agent requires not asking employees to write manuals, but externalizing their judgment structures. A complete Agent identity definition covers eight modules: what it believes (behavioral anchors), what it owns and what it does not (responsibility boundaries), how it decides in typical situations (if-then rules), what its reasoning steps look like (thinking framework), what qualifies as low-quality output (externalized quality intuition), how its workflow runs (deliverable flow), how it improves over time (growth mechanism), and what underlying capabilities transfer across contexts (meta-skills). These eight modules correspond not to a feature list but to all the important dimensions of how a person's judgment is structured.
The most important thing is not "what does this person know?" It is "how do they choose when facing ambiguity, and how do they prioritize when demands conflict?" Judgment structures can be trained. Generic experience cannot. The core trap in converting employee experience to an Agent is equating "knowing a lot" with know-how — the former can be filled with words, the latter is only genuinely converted once the judgment structure has been written out clearly.
The extraction process can be broken into four stages. Domain boundary discovery: what professional judgment does this person concentrate in, what are the trigger conditions for the decisions they handle best, and how wide is the range of contexts they cover? Purposeful design: based on whether this role involves write operations, cross-session memory, and multi-party collaboration, determine the emphasis in the Agent identity design. Depth test: swap out this Agent's name — if with a different name the identity definition still holds, it has not captured this person's distinctive judgment, only described a generic function. The definition must not hold under a name swap to count as having captured genuine domain depth. Usability verification: independent, sufficiently small, clearly bounded, replaceable, reusable — all five criteria required.
I began two years ago systematically writing my own judgment into the multi-Agent knowledge production system I built for myself. Every time I made an error, rather than writing a reflection note, I structured it into a callable rule — describing the trigger condition, the underlying pattern, and the correction mechanism in a form machines can read. These rules have accumulated into a rule library that now serves as the baseline constraints every Agent starts with. This is not a knowledge base. This is what converting the work process into data looks like in practice.
I have also run through one costly validation: in an AI initiative inside one organization, twenty Agent role descriptions were written, but only one was actually running. The problem was not technical. The role descriptions had been written — but the judgment structures had not been written into them. Most of the roles were descriptions with the wiring not connected, not Agents capable of operating. The manager reviewing the deliverable could not see the gap, because the documents all looked complete.
Judgment structures can be trained. Document descriptions cannot. That is the most fundamental difference between writing know-how into an Agent and writing know-how into a manual.
The manager's first move: find the core judgment you most want to capture from your best performer. Describe it in four sentences: what trigger condition typically brings this judgment into play; which factors they prioritize; what output they consider acceptable; in which situations they make an exception. If you can answer all four, you have completed the first step of structuring know-how. If you cannot, your knowledge extraction is still at the know-what layer and has not yet reached know-how.
The Negotiation Layer — Why Employees May Not Cooperate
The technical path is now clear: locate the high-density nodes, externalize the judgment structure, write it into Agent identity across eight modules. If this were only a technical problem, it would be tractable.
The problem is that know-how is not scattered across a system with no will of its own. It is scattered across people who have interests and intentions.
In 2026, an open-source project called Colleague.Skill (GitHub: titanwings/colleague-skill) appeared — reported by MIT Technology Review in April 2026 as part of a broader wave of employees training their own AI doubles in response to concerns about AI-driven displacement. Its core function: distill a colleague's working style, judgment patterns, and handling approach into skills files that AI can learn from. The project went viral in developer communities — a signal that the demand for converting a colleague's know-how into AI-usable files is not a niche experiment.
In the same period, a counter-movement also appeared in developer communities: tools and techniques specifically designed to produce skills documentation that looks complete and professional on the surface but has had its core judgment hollowed out — with a private copy retained elsewhere. The fact that such approaches are being openly discussed and shared signals that the demand for protecting one's own judgment assets has already found a code-level answer.
Two impulses surfacing at the same time in the same developer communities — one toward extraction, one toward resistance — is not a coincidence. It is a genuine organizational signal: once the technical capability to extract know-how becomes real, employees start protecting their interests.
This is not employees resisting AI. It is not employees refusing to contribute. These protective approaches emerge as self-help measures in the absence of contractual protection. If an employee contributes core judgment, AI learns it, the organization benefits — but the employee's irreplaceability declines with no mechanism to recognize or reward the contribution. Why would they contribute the real thing?
There is a simple and stark logic here: the quality of employee know-how contribution depends on how much employees believe contributing is in their favor. Under high trust, with well-designed benefits and transparent boundaries, employees contribute high-quality judgment structures — the kind that actually give AI something to learn. Under low trust, with no contractual protection and opaque benefit sharing, employees learn to sand-bag. On the surface they produce voluminous and thorough experience summaries, but the core judgment has been quietly withheld, kept outside the system. What the organization receives is high-quality form, low-quality content — data noise. AI learns nothing worth learning.
Know-how extraction is not only a technical project. It is a trust project. Whether you get real know-how does not depend on how sophisticated your extraction tools are. It depends on whether employees believe that contributing is in their interest. Technology solves "how to capture." It does not solve "why employees would contribute something worth capturing."
The most common management error at this layer is treating it as a communication problem — more training sessions, more messaging about AI's benefits, asking employees to "change their mindset." But mindset is not the issue. Incentive structure is. If the actual consequence of contributing know-how is a reduction in the employee's irreplaceability, with no corresponding benefit from the organization, then any amount of communication is only a delay tactic.
The manager's first move: before launching a knowledge extraction initiative, answer this question: if employees hand over their most critical judgment, what do they get? If you cannot answer that, your extraction initiative does not yet have the operating conditions it needs.
What to Extract and What to Keep — Injection Depth and Judgment Residual
Even if the trust problem is solved, managers face another operational challenge: even when employees are willing to participate, you still do not know what to prioritize extracting.
I use two dimensions to analyze the extraction priority of employee know-how.
The first dimension is injection depth — how much of this employee's work process they contribute to the system each day. Every time they write a rule, annotate a case, record a failure's cause, or build a checklist for a workflow, that is an injection. Employees with high injection depth are continuously converting their daily judgments into structures the system can learn; employees with low injection depth keep all their judgment in their heads and personal communication records, invisible to the organization's AI system.
The second dimension is judgment residual — after AI runs through a process node, how much judgment this employee still needs to make, and how difficult that judgment is. Some process nodes, once AI takes them over, barely require human intervention again; other process nodes, however capable AI becomes, still require the final call to sit with a person — because the judgment there involves value trade-offs, risk ownership, client relationship considerations, or regulatory constraints that AI can support but not replace.
These two dimensions determine the direction of extraction: prioritize extracting from high-injection-depth work processes; prioritize preserving high-judgment-residual role fragments.
Mapping both dimensions into a two-by-two gives a rough guide for handling each quadrant:
Low injection depth, low judgment residual — AI substitution happens most naturally here; extraction priority is lowest.
High injection depth, low judgment residual — this is where know-how extraction value is highest. Large amounts of learnable process data exist, and extraction enables subsequent AI to perform better.
High injection depth, high judgment residual — the "extract plus human upgrade" zone. Extraction lets AI understand background and context, but decision authority stays with the person, who judges with better information support.
Low injection depth, high judgment residual — the most complex quadrant. The employee's judgment is highly valuable, but the work process has never been systematically recorded. What is needed here is not immediate extraction but first creating incentives for this employee to start writing their judgments into the system — let injection depth increase first, then revisit extraction.
The rules, cases, checklists, and failure post-mortems that employees write down, if they sit scattered in documents, are still just the old knowledge library. The organization needs to treat them as reusable assets: who contributed them, to which process, how many times they have been called, what errors they have corrected, what quality changes they have driven. This is how "injection has an asset record" works in practice — and it is the most direct mechanism for making know-how contribution genuinely beneficial to the employee.
Note: these two dimensions are analytical instruments, not a formula validated to produce a specific outcome. What they help with is sequencing — extract this first, that later, do not touch this yet — not a promise that extraction will improve AI learning quality by any particular amount.
The manager's first move: take two or three of your most critical roles and ask two questions at each: what proportion of this person's daily work is currently recorded in the system (injection depth)? After AI fully takes over this role, what judgments still have to be made by a person (judgment residual)? Use those two questions to rank the roles. High injection depth combined with high judgment residual: first-priority experimental ground for know-how extraction.
What Lies at the End of Extraction — Taking Up a Question That Has Gone Unanswered
By this point, the argument in this chapter has traced a complete arc: scattered know-how is the real bottleneck in AI transformation; extracting it requires process decomposition first; it requires externalizing judgment structures into Agent identity; it requires solving the trust question of why employees would participate; and it needs a prioritization framework for what to extract and what to preserve.
But the argument has one higher dimension it has not yet touched: why is all of this unavoidable?
Daniel Miessler, in a 2024 technical blog post, pushed this logic to a stark conclusion. His foundational premise: "companies are just a collection of algorithms." "No matter how special the product or company, it still operates as a pipeline of steps." And his sharpest formulation: "Explainability is the new currency." His point is not that AI will replace humans — it is that AI-driven process transparency will expose the algorithmic logic of every work step, including the tacit judgments that have always lived inside employees' heads. This process is not something you choose to initiate or avoid. Once AI enters the organization, it begins happening.
That judgment is correct, and its force is stronger than most managers appreciate. The layer of tacit judgment that employees have long depended on for their irreplaceability will, node by node, be rendered as points on an algorithmic map. This is the deep logic behind why know-how externalization pressure is unavoidable.
Miessler's analysis is sound, and I accept it fully. But at the end of his piece, he noted that a future article would address "which human work I think might remain." In everything I have read since, no article of his directly answers that question — including "The End of Work," where he argues for an ideal of zero employees, and "The Bubble Is Labor," where he contends that employment itself trends toward obsolescence. He can take the algorithmic-map-absorbs-everything argument all the way to its conclusion, and still he never gives the direct answer — which work stays, for whom, and on what basis.
What I want to address is precisely that gap he stepped around.
What remains is not "certain jobs." It is the node that no algorithmic map can ever draw: judgment.
Know-how externalization pressure is real. Process transparency is a structural trend. The tacit know-how employees carry faces increasing pressure to be made explicit — Miessler got all of that right. What he did not say is: extraction does not end in an empty room. It ends with humans repositioned — somewhere the algorithmic map is constitutionally unable to reach. That place holds: choosing under uncertainty, deciding when there is no standard answer, and making the calls that should not be delegated to machines.
This is not a technical limitation. It is not a temporary transitional state. It is the terminus of the division of labor: AI handles the process, humans hold the judgment.
Extracting know-how is not preparation for humans to disappear. It is what makes the human role clearer — from spending time completing processes, to applying judgment to gatekeeping results. That shift is the foundation for understanding what human-in-the-loop actually means, and it is the core of what organizational rewriting looks like in the AI era.
Three Things to Do This Week
Knowing all this is not enough. The manager's perennial question is: what do I do first?
Find the role with the highest injection depth. On your team right now, whose work process has already left the most records in the system? Daily prompt logs, annotation records, operation logs, case libraries — which person or which role has accumulated the most today? That is where injection depth is highest. That is the first priority for know-how extraction. Not the most senior employee — the person or process most systematically recorded in the system.
Check for data contract gaps. When employees on your team are feeding AI tools with their judgments and contributing their work process, has anyone clearly told them: who owns this data, what it will be used for, and what they receive in return for contributing? If not, that is a data contract gap. A gap does not mean no risk. It means risk is being concealed — employees do not know what their knowledge is being used for, and the motivation to sand-bag will surface at some point. Getting ahead of that conversation is considerably easier than managing a trust breakdown after the fact.
Run a sovereignty-respecting extraction experiment. Not a broad rollout. Not running know-how extraction for every role. Find one employee who is willing, whose judgment is genuinely valuable, and run a small experiment together: you both decide which judgments are worth extracting, you both confirm how the extracted data will be used, and the employee's contribution will be recognized through a named mechanism. Then record the process and watch the response — did they participate willingly, what was the quality of their contribution, did they find it worthwhile? The results of that experiment are worth more than any theoretical discussion about knowledge management.
Of the three actions, finding the highest injection depth is most immediately executable — completable within a week. Checking for data contract gaps is most consequential — it determines the ceiling of extraction quality. Running the experiment delivers the most learning — it shows a manager what know-how extraction actually looks like inside their own organization.
Know-how extraction is a technical project, and it is a trust project. Trust is not built through explaining the rationale. It is built through employees seeing firsthand that contributing is in their interest. Run the experiment first. Expand from there.