Every operating business we walk into keeps a binder, or a SharePoint folder, or a wiki, that purports to describe how the work gets done, and in almost every case the document stopped matching the work long ago. The accounts-payable lead can recite the official three-way match procedure, then immediately explain the four vendors it doesn't apply to, the one branch that codes freight differently, and the reason invoices over a certain amount route through a person whose name appears nowhere in the file. None of that is in the SOP, and none of it is ever going to be. The instinct is to treat the gap as a discipline problem, the predictable result of people being too busy to keep documentation current, but that diagnosis is wrong, and acting on it produces more binders that rot at the same rate.
The knowledge that resists being written down
The deeper reason was named by Michael Polanyi in The Tacit Dimension in 1966, in a sentence that has held up for sixty years: we can know more than we can tell. A skilled clerk recognizes that an invoice is wrong before being able to articulate which field tipped them off. The recognition is real, it is reliable, and it is not fully reducible to a rule you can transcribe. This is the ordinary structure of expertise. The part of any process that a practitioner can state out loud is the explicit layer, and it is the smallest and most stable part. The larger part, the judgment about which exception applies when, the practitioner cannot put into words, which is exactly why it never makes it into the procedure.
Why "just document everything" was never going to work
Ikujiro Nonaka and Hirotaka Takeuchi gave the mechanics a name in The Knowledge-Creating Company in 1995. Their SECI model describes knowledge moving through four conversions, and the one that matters here is externalization, the step where tacit knowledge becomes explicit and writable. They were clear that this step is the hard one, costly and lossy, because turning a felt sense of "that doesn't look right" into a stated rule strips out most of what made the judgment work. An SOP records the output of one externalization effort on one day. The work, meanwhile, keeps moving: a new vendor arrives, a system gets patched, a customer negotiates a one-off term that becomes a standing exception. The document loses information when it's written and goes stale the moment the underlying process shifts, which is to say immediately and continuously. Etienne Wenger's Communities of Practice, in 1998, pointed at where the live version actually resides, not in any artifact but in the practitioners themselves, transmitted by watching, asking, and doing alongside one another. The binder holds one day's record; the practitioners hold the current process.
There's a cost to pretending otherwise. The McKinsey Global Institute estimated back in 2012, in The Social Economy, that knowledge workers spend close to a fifth of the work week just searching for and gathering information, a figure old enough now that we'd cite it as illustration rather than current measurement. The shape of the problem hasn't changed: when the authored record can't be trusted to match reality, people stop consulting it and start asking the person who knows, which is rational and also the precise behavior that keeps the critical knowledge tacit and undocumented.
Reading the SOP versus watching the work
This is why interviewing people about their process, or worse, reading what they once wrote about it, recovers only the layer that was always going to be easy to capture and was never the hard part. Ask someone to describe their job and they give you the explicit version, the one that fits in sentences, the normal case. The exceptions and the workarounds, where the real difficulty and most of the labor actually sit, surface only when you watch the work happen against live cases over enough time that the long tail shows up. We've made the same argument from the angle of method elsewhere, that observation beats interviews in the discovery phase because of what interviews structurally miss, and the tacit-knowledge literature is why that holds. You aren't catching people in inaccuracy; you're recovering knowledge they genuinely possess and genuinely cannot tell you, the kind that only shows itself in the doing. What a capture agent records is precisely this layer: the actual sequence of actions, the cases that broke the rule, the hesitation before a judgment call, none of which the binder ever held.
Designing the agent around what it cannot know
The same principle that condemns the SOP should govern the system you build to replace the human's role in the process, and this is the part most teams get backward. If a large share of any process is tacit and resistant to capture, then an agent built on the assumption that the documented procedure is the whole of the work will fail on the exceptions, the place the human handled correctly. The durable design does the opposite. It treats the explicit, observed, high-frequency path as the part it can safely run, and it detects the moments where a reliable answer would require the tacit judgment it doesn't have, sending those to a person rather than producing a confident guess. A system that knows the boundary of its own knowledge and respects it is sturdier than one that assumes the documented procedure is the whole process, which is the same reason an aligned engagement is built around watching the work first and automating second, rather than reading the procedure and assuming it's true.
A reasonable objection
A fair counter is that good documentation discipline really can keep an SOP alive, and that plenty of regulated, high-volume processes run on procedures that are genuinely followed to the letter. There's something to this. Some work is mostly explicit by nature, codified by law or by a system that won't let you deviate, and for that work a maintained procedure is close to sufficient. But two things hold even there. The procedure still describes the path, not the exceptions the path generates, and it is exactly the exception handling that determines whether an automation can run unattended or has to hand back to a human. The more codified and stable a process is, moreover, the less interesting it is as a candidate, because it was already the easy part. The work worth our attention is the work where the binder and the actual process diverged, which is most of it. You recover that layer by watching, not by reading, and you build the agent to honor the same limit the document always admitted by leaving the hard cases out.