My friend and co-founder at Skan, Avinash, always talks about Polanyi’s paradox. Here is a brief detour. In 1966, the chemist-turned-philosopher Michael Polanyi published a short book called The Tacit Dimension. The line everyone remembers is the one in the opening pages: we can know more than we can tell. Polanyi was making a point about scientific discovery: the moves a working scientist makes are not fully reducible to the rules they could write down for a student. His own examples were riding a bicycle and recognizing a face: things we do fluently but cannot fully reduce to stated rules.
Sixty years later, this is the single most expensive sentence in enterprise AI.
I’ve spent most of the last decade inside large operations (claims, underwriting, KYC, contact centers, collections), watching transformation projects begin with ambition and end with anemic KPIs. The pattern is consistent enough that it no longer feels like bad luck. The model isn’t the problem. Integration isn’t the problem. The change management is downstream of the problem. The problem is that the work the AI is supposed to do has never been fully described, because the people doing it can’t fully describe it.
That’s Polanyi’s Paradox. And it’s the last mile of enterprise AI.
Three situations, one paradox
Let me describe three scenarios. None of them is unusual. All of them illustrate the same gap.
A property claims desk at a premier US carrier. The adjuster has fourteen years of experience. She’s processing a hail damage claim on a roof in central Texas. The policy documents say one thing. The photos suggest another. The contractor’s estimate is from a vendor she’s dealt with before and considers reliable for shingle replacement but optimistic about decking. She approves the shingle estimate, flags the decking line for a second look, and adds a note to the file. The whole sequence takes ninety seconds. When our team asks her to walk us through her reasoning, she says, “I just know.” She isn’t being evasive. She’s telling us the truth about how she made the decision. The reasoning happened, and it was good reasoning, but it didn’t pass through language on its way to the screen.
A senior credit underwriter at a regional bank. He’s reviewing a small-business loan application from a restaurant in a town he’s never visited. He pulls up the financials, glances at the cash-flow trend, opens the operator’s personal credit report in another tab, and then (this is the part that matters) he opens Google Maps and looks at the storefront. He spends maybe twelve seconds on Street View. He sees a clean facade, fresh signage, and two cars in the lot at 2 p.m. on a Tuesday. He moves on. When the bank’s automation team interviewed him for a process mapping project, no one asked about Street View. It wasn’t in the workflow. It wasn’t in the policy. It was in every underwriting decision he’d made for the last three years.
A tier-two contact center rep at a telecom. A customer is asking about a charge she doesn’t recognize. The rep, six months into the job, opens five applications in sequence, copies a value out of one and pastes it into another, hits a keyboard shortcut that opens a saved query in a tool that was never officially deployed (a colleague set it up two years ago and it just stayed), and resolves the call in four minutes. Average handle time for that issue type, per the official process map, is eleven minutes. The shortcut isn’t documented. It isn’t in any training material. It’s in the muscle memory of about thirty reps who learned it from each other.
In all three situations, the operative knowledge is real, valuable, and largely invisible. It’s also exactly the knowledge an AI agent would need to do the work autonomously.
Why this matters more now than it did five years ago
The tacit knowledge gap has always existed. What’s changed is how much it costs us.
In the RPA era, the gap was a tax on automation. A bot would handle the documented 70% of cases and fail loudly on the undocumented 30%. The failure mode was visible (broken bots, exception queues, the slow erosion of confidence in the automation program), and we built whole organizations to manage it: Centers of Excellence, process owners, exception handlers. The unspoken assumption was that the tacit work would stay with humans, and the bots would handle the script.
Agentic AI breaks that assumption. An agent that can reason, act across systems, and handle multi-step workflows isn’t built for the documented 70%. It’s built to attempt the whole job. Which means the tacit 30% (the Street View glance, the contractor judgment call, the keyboard shortcut nobody wrote down) is suddenly inside the scope of the system rather than outside it.
The agent won’t know what it doesn’t know. And the enterprise, having never written it down, can’t tell it.
This is the structural reason most agentic AI pilots stall after the demo. The demo runs on the documented process. The pilot runs into the undocumented one. Everyone blames the model.
What “documented process” actually means
Walk into any large enterprise and ask for a process map. You’ll get one. It will have been authored, at some point, by a combination of business analysts, Six Sigma black belts, and consultants. It will be in Visio, or BPMN, or (if the team is current) Mermaid. It will represent the process as designed.
The process as performed is a different artifact.
The honest version of that map would include the screenshare a new hire watched on her second day. The Excel file three people maintain on a shared drive that does not appear in any system inventory. The Slack channel where senior reps answer edge-case questions. The fact that, on Wednesdays, when the offshore team rotates, the policy on exception escalation quietly tightens for four hours, then relaxes again. None of this is in the map. All of it is in the work.
This is what I mean by the invisible enterprise: the layer of operational reality that lies beneath the documented one and accounts for most of what determines outcomes. It’s invisible not because anyone is hiding it, but because the tools we’ve used to describe enterprise work for the last forty years weren’t built to see it.
You can’t describe what you can’t observe. You can’t automate what you can’t describe.
The microscope
The history of science offers a useful frame for this. Whole classes of phenomena were unknowable, in any rigorous sense, before the instruments that made them visible: microorganisms before the microscope revealed them, the moons of Jupiter before Galileo’s telescope found them in 1610. The microscope did not invent microorganisms. It made it possible to do science about them. (Polanyi’s own contribution here is subtler. His idea of indwelling: we attend through a tool, the way you feel the road through a probe rather than feeling the probe, and the instrument becomes an extension of perception.)
Enterprise work is in a pre-microscope state. We have surveys, interviews, and consultant-authored maps. They produce a description that’s plausible, internally consistent, and roughly wrong in the specific ways that matter most. The tacit knowledge (the Street View glance, the keyboard shortcut, the contractor judgment) doesn’t survive the trip through a structured interview, because the person being interviewed doesn’t have conscious access to it. It’s not that they won’t tell you. It’s that they can’t.
The instrument that changes this is observation. Not survey-based observation, which inherits all the limits of self-report. Continuous, low-friction observation of how work actually flows through screens, systems, and human decisions, captured at a resolution fine enough to preserve the moves people cannot articulate.
What this produces isn’t a process map. It’s a process record: a faithful account of how the work was performed, across all the variants, in all the systems, with all the workarounds. The map is an artifact of intent. The record is an artifact of behavior. For the purposes of describing the world to an agent, behavior is what matters.
What changes when the tacit becomes legible
A caveat: making tacit work legible doesn’t mean automating all of it. Some should remain human. Some can’t be automated even in principle. Some shouldn’t be automated for reasons unrelated to technical feasibility: reputational risk, regulatory exposure, the simple fact that customers want to talk to a person when their roof is gone.
But three things become possible that were not possible before.
First, design improves. Most process redesign today is done by people who have never seen the process performed at scale. They have seen the map, talked to a few practitioners, and produced a recommendation. Redesign anchored in observed behavior is a different exercise. The redesign team sees that the four-minute call uses a keyboard shortcut that does not exist on paper, and decides whether to standardize it, automate it, or document it as the official path. The redesign team sees that the underwriter is using Street View and decides whether to bring that signal into the formal credit model. None of this is possible if the work is invisible.
Second, automation scope sharpens. The honest question for any automation initiative is not “can we automate this process” but “which variants of this process are stable enough to automate, and which are not.” A process record makes that question answerable. The variants are visible. Their frequency is countable. Their stability is measurable. The team can commit to automating, say, the top six variants that account for 73% of volume, and route the rest to a different path. This is what scoping looks like when it’s grounded in evidence rather than ambition.
Third, agents become deployable on work that previously resisted them. An agent equipped with a faithful record of how the work has actually been performed (across variants, across exceptions, with the workarounds preserved) is operating on a different substrate than an agent built from policy documents and a process map. The substrate determines whether the agent’s behavior, the first time it sees a real case it wasn’t trained on, looks like reasoning or guessing.
The shape of the next decade
If I’m right about this, the next decade of enterprise AI will be less about model capability and more about the substrate the models operate on. The models will keep getting better. They are already, for most narrowly defined enterprise tasks, capable enough. The bottleneck isn’t at the model layer. It’s at the description layer: the question of whether the enterprise can render its own work legible to a system that’s supposed to do that work.
This isn’t a glamorous problem. It doesn’t make for good keynote slides. It’s the unsexy infrastructure work of building, for the first time, a faithful record of how an enterprise actually operates. Most large organizations don’t have one. Most have never thought to want one. They have a CRM that records customer interactions, an ERP that records transactions, a data warehouse that records outcomes, and a process map that records intent. They don’t have a record of work: the connective tissue between intent and outcome where most of the operational performance lives.
Polanyi’s Paradox isn’t going away. Humans will continue to know more than they can tell. What can change is whether enterprises have the instruments to observe what their people can’t describe. The companies that build those instruments (or buy them) will spend the next decade deploying AI on a different substrate than the companies that don’t build them. The gap between those two groups will be larger than the gap between any two foundation models.
The last mile of enterprise AI isn’t a modeling problem. It’s a seeing problem. And the enterprise that learns to see its own work, the way the microscope let science see the cell, will be the enterprise where the agents actually work.
The adjuster in central Texas will still know things she can’t tell us. That’s fine. The question is whether anyone is watching closely enough to learn what she knows from how she works.