An awkward discovery
Teams documenting rules for an AI employee routinely find the rules don’t make sense, contradict each other, or exist because of a constraint that disappeared years ago. The documentation exercise turns into a process audit nobody requested.
The system asks questions people stopped asking
Writing down why an exception exists forces an answer, and “because we always have” is a common one. This is the genuine second benefit of building the knowledge base, and often the more valuable of the two.
Half the value of documenting a process for a machine is discovering the process was never justified.
Distinguish better from merely different
A system taking a shorter path may have found genuine waste, or may be skipping a step that exists for a reason nobody wrote down — a compliance check, a courtesy, a control. The distinction is not visible in the output, only in asking why the step existed.
Test the change like a change
Where the shorter path looks right, run it deliberately on a subset and measure, rather than letting it become the default by drift. Undocumented process change is how a system quietly stops doing something that mattered.
Feed the finding back to the humans
If a step is genuinely unnecessary, remove it for everyone, not just for the automation. Otherwise you have two processes — one for people and one for the machine — which is the worst outcome and a guaranteed source of inconsistency.
Give the finding somewhere to go
This only works if someone is reviewing the system’s behaviour regularly and has the authority to change the process. Without an owner in the business, the insight is generated and discarded.