Illustrative scenario. A bookkeeping firm wants an agent to reconcile client payments. They ask Marta, who has done it for twelve years, how she does it. "Easy," she says, "you match the bank statement against the invoices." They build the agent from that description and, in the first few weeks, it fails exactly where Marta never stopped to think: the client who pays three invoices in one transfer, the amount that always arrives short by a discount agreed out loud, the quarter close where nothing is touched until an email shows up. None of it was written down. Marta didn't know she knew it, either.
The thesis in one line: before you automate a process, you have to get out of the head of the person who runs it whatever was never written down, and that step often delivers more than the automation itself.
Why document processes before automating with AI?
Because an agent does what you tell it, not what the company actually does. The gap between the two is tacit knowledge: criteria, exceptions and shortcuts that the person doing the work applies without noticing, which is exactly why they can't explain them. Ask "how do you do it?" and you get the official version, the one that fits in a sentence. The agent gets built on that version and breaks on everything else.
This isn't a rollout footnote. RAND's analysis of why AI projects fail, based on interviews with engineers and data scientists, lists among the most common causes that the problem to be solved was misunderstood or miscommunicated (RAND, 2024). It's the same pattern we describe in why AI automation projects fail: the project doesn't fail in the demo, it fails in the gap between what each side assumed.
How do you know a process only lives in one person's head?
There are fairly reliable signs, and you don't need an audit to spot them.
- Two people do it differently and both say they do it right. Each applies their own judgment and nobody has ever put the two side by side.
- When that person is out, the process stalls or degrades. If someone's holiday is an operational risk, the process lives in their head (the same problem, seen from the agent's side, in what happens to your agent when the person who built it leaves).
- The explanation starts with "it depends". When every step comes with an "it depends" and nobody knows on what, there are unwritten rules.
- Exceptions get settled by phone or by message. What's decided outside the system never makes it into the system, and the agent only sees the system.
How do you extract the real process in a week?
Not with a questionnaire or a two-hour meeting. With real cases, watched by someone who isn't the person doing the work. A method that fits in five days:
- Monday: pick one process and one person. A single process, the one that gets the most traffic, and whoever runs it daily. Tell them upfront they're not being evaluated: the goal is to understand, not to audit.
- Tuesday: watch cases, don't ask how it's done. Sit with them while they work real cases, odd ones included, and note every decision. A sample of the latest cases beats any description.
- Wednesday: ask why at every decision. "Why this one and not that one?", "what would have happened with a different amount?". This is where the criteria they thought were obvious come out.
- Thursday: write the business rule, not the clicks. Condition, exception and who gets told, one page per process. The format is in how to document automations.
- Friday: test against cases they haven't seen. Give them new cases without showing the rule and compare their decision with what you wrote. Every difference is a missing rule.
| What the official version says | What the person actually does | How it surfaces |
|---|---|---|
| "I match the statement to the invoices" | Groups payments, applies discounts agreed out loud and parks certain clients | Watching real cases, not hearing them described |
| "It's approved if it meets policy" | Approves things outside policy when they know the client | Asking why at every exception |
| "It's reviewed before sending" | Only checks what looks off, going on a gut feel they can't name | Giving them new cases and comparing their call with the written rule |
Look at the last column: in no case is the fix to ask more, it's to watch more. People who describe their work describe the ideal; people who do it in front of you show the real thing. And the real thing is the only one an agent will meet on Monday morning, with the cases nobody foresaw in the kickoff meeting.
What if documenting shows it shouldn't be automated?
It happens more than people admit. Documenting turns up inconsistencies between people, steps nobody remembers the reason for, and decisions that hinge on judgment that won't reduce to rules. That leaves three exits: simplify the process before touching anything, automate only the part that is already a rule and leave the judgment part with a person, or decide the process isn't for an agent (the underlying reasoning is in when not to automate with AI). Any of the three costs less than finding out with the agent already in production.
And the judgment part doesn't go away: it sets how much autonomy you can give the agent. That's decided with an agent's autonomy levels, and you can only decide it if you know first where the judgment sits.
When is documenting the process first not worth it?
When the process is short, reversible and cheap to get wrong: three steps, no money or personal data involved. Just try it and fix as you go. It's also not worth documenting to that level of detail a process that changes every month; there you write down the stable principles, not every step (more in automating a process that changes every month).
If you have several candidates and don't know which to start with, auditing your processes for AI answers which one deserves the effort first; this week's exercise is what you do next, with the one you picked.
The line to take with you: the process you're about to automate isn't the one in the manual, it's the one the person runs, and until that one is written down, the agent is built on a guess.
Sources (accessed 28 October 2026): "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed", RAND Corporation (2024), used qualitatively. The opening scenario is illustrative, not a real case.