A customer support team hands its refund process to an agent. The documented policy is clear: refunds over a set amount need a team lead's approval, refunds after thirty days are declined, and every refund gets one of eleven reason codes. The agent follows it to the letter. Within a week the team lead's queue has tripled, customers of ten years' standing are being turned away on day thirty-one, and the reason codes reveal that almost everything is "Other", because that is what the team had been picking all along.
The agent did nothing wrong. It did exactly what the company said it did. That turned out to be the problem.
Every organisation runs two processes
There is the process on the wiki, and the process people actually follow. The first was written at some point by someone conscientious, often for an audit, a certification or a new manager who wanted to understand things. The second has been evolving ever since, one sensible shortcut at a time.
The gap between them is rarely sloppiness. It is adaptation. The support agent who refunds a loyal customer on day thirty-four is making a judgement the policy didn't foresee. The procurement clerk who splits a purchase to stay under the approval threshold is working around a limit nobody has updated since prices went up. The HR coordinator who skips step four of onboarding does so because step four refers to a system the company stopped using two years ago.
Trade unions have understood this for a long time. Working to rule is a form of industrial action in which employees follow every written procedure exactly, and nothing more. It works as a protest precisely because organisations cannot function on their written procedures. If obeying the rules is a reliable way to grind the place to a halt, the rules are not a description of how the place runs.
Agents are the first employees who work to rule
A new human hire picks up the real process within weeks. They sit next to someone, watch what they do, hear "oh, ignore that bit, nobody does that any more". The fiction gets corrected by osmosis, and the documentation stays wrong because nobody needs it to be right.
An agent has no desk neighbour. It gets the documented process, perhaps a few examples, and executes. It does not pick up the unwritten exceptions from a raised eyebrow in the kitchen. So the first time you automate a workflow, you are in effect running a work-to-rule action against yourself, and discovering in real time which rules nobody follows.
This tends to go one of two ways. Either the team concludes the agent is stupid ("it doesn't understand how we do things here"), or someone notices that the agent understands precisely how the company says it does things, and that the two have drifted apart. The first reaction kills the project. The second is the most useful thing to happen to that process in years.
Agents also leave a trail that people don't. Every case the agent escalated, every rule it couldn't apply, every time a human stepped in and overrode it, gets logged. For the first time the deviations are countable. A month of override records describes your real process better than anything on the wiki, provided someone reads it as evidence rather than patching each override as a bug.
Why the gap stays invisible
If the gap is so wide, why doesn't anyone fix the documentation? Partly because nobody is rewarded for it. Writing down what actually happens is tedious, unglamorous and sometimes mildly incriminating. A written record that the team routinely skips the second credit check is a record an auditor might one day read.
There is a quieter reason too. The unwritten version gives people discretion, and discretion is valuable to whoever holds it. The senior account manager who knows which clients get flexible payment terms has influence partly because that rule isn't written anywhere. Formalise it and anyone can apply it, including an agent. Some of the resistance to "documenting the real process" is resistance to giving that influence away.
And managers often don't know. The further you sit from the work, the more the documented process is the only one you can see. A head of operations may sincerely believe all eleven reason codes are in use, because the dashboard shows codes, and the dashboard does not mention that most of them say "Other".
Read the gap before you close it
Once the gap appears, the temptation is to pick a side. Either enforce the written process because the policy is the policy, or throw it out and let the agent learn from whatever people actually do. Both are mistakes.
Some deviations are wisdom. The day-thirty-four refund for a ten-year customer is a good decision the policy failed to capture. Some deviations are rot: the split purchase order is a workaround that hides spending from people who ought to see it. And some are neither, just habits that outlived their reason. Chesterton's fence applies in both directions here. Before you remove a written rule, find out why it was put up. Before you formalise an unwritten workaround, find out what it is protecting. Then sort accordingly: write the wisdom down, close the rot, and retire the habits without ceremony.
The practical way to do this is to watch the work rather than interview people about it. Ask a team to describe their process and you get the wiki version with some embarrassment around the edges. Sit with them for a morning, or trace a sample of real cases end to end, and you get the truth. The useful question is not "what is the process?" but "what did you do with the last five of these, and why?" This is also why the most valuable hour in an AI workshop is often the one spent mapping what a team really does, before anyone mentions a tool.
What to write down instead
Documentation built for agents has to differ from documentation built for audits. Audit documents describe the happy path and assume a human will handle everything else. Agent instructions need the everything else. In practice that means writing down:
- The judgement calls, stated as judgement calls: refunds after thirty days are usually declined, but long-standing customers with no previous refunds are generally approved.
- The thresholds as they are actually applied, not as they were originally set.
- Who handles escalations, and for what, named by role rather than by committee.
- The things everyone knows and no one has recorded: which system is the source of truth, which field is never filled in, which client is always a special case.
This is uncomfortable work. It turns quiet discretion into explicit policy, and explicit policy can be argued with. Some of those arguments will be overdue. A team that has never agreed out loud on when to bend the refund rule will discover that three people have been bending it in three different directions, and that customers have noticed even if management hasn't.
That conversation is often worth more than the automation that forced it. A process that has finally been described honestly can be improved, measured and handed to new staff in a day instead of a quarter. The agent was merely the first colleague literal-minded enough to demand it.
The description will drift again, because work always does. The difference is that the drift now announces itself. A step that agents keep getting overridden on is a step whose written rule has fallen behind practice, and a rising override count is a prompt to revisit the rule before anyone blames the people.
A good first exercise costs nothing. Take one documented process, hand the document to someone from a different team, and ask them to work three real cases using only what is written. Wherever they get stuck is where your real process lives. Write that down, then give it to the agent.
