No agent works on fiction

No agent works on fiction, and most of the process manuals I read are well-written fiction.

I've seen an operation with a 34-page manual. Beautiful. Signed. Approved by the board. Then I asked the people on the front line to show me what they actually did day to day. It was a different process. The real one lived in WhatsApp, in a side spreadsheet, in the workaround the team invented when the system went down and nobody ever fixed.

Nobody there was wrong. The manual described how the company would like to work. The team described how it does work. Those are two different things, and only one of them can be automated.

Where the fiction lives

When I start mapping a process, I always look in the same places:

• WhatsApp groups where the team decides "who takes this lead" outside the CRM.
• Side spreadsheets that exist because the system lacks the field someone needs.
• Shortcuts created on a firefighting day (system down, campaign blowing up) that became routine.
• Funnel stages everyone skips because "it doesn't make sense for our case."
• Approvals that go through three people on paper and through one voice note in practice.

Picture a developer whose manual says every lead goes into the CRM, gets qualified within two hours and is assigned by round robin. On the ground, the broker gets the lead on his phone, replies from his personal WhatsApp and only enters the ones that moved forward into the CRM. If I build an agent from the manual, it will qualify leads the broker already handled, chase steps nobody performs and assign leads to people who are no longer on the schedule. The agent isn't wrong. It's just obeying a process that doesn't exist.

Why this blocks automation

An AI agent needs three things to operate: know what the input is, know what the rule is, and know what to do when the rule doesn't cover the case. When the documented process differs from the real one, all three break at once. The input comes from a place nobody mapped. The rule was written for a flow that doesn't happen. And the exceptions, which in the real world get handled by someone who "knows how it works," aren't written down anywhere.

The outcome is predictable. The automation goes in, gets in the way, the team works around it and creates one more workaround. Now the company has the manual, the real process and the automation: three versions of the same operation, none talking to the others.

The answer is not more tools

If your operation still runs on improvisation, the next step isn't buying another system or hiring another AI. It's documenting what actually happens. In practice, that means:

1. Sit with the people on the front line, not with whoever designed the process. Ask them to show you the screen, the group, the spreadsheet. Watch, don't just listen.
2. Write the flow as it is today, workarounds included. A workaround is information, not shame. It shows where the official process failed.
3. For each step, note what happens when it goes wrong. That's where the agent needs a rule the most.
4. Only then decide what's worth fixing, what's worth making official and what's worth automating.

Often this mapping alone solves half the problem, before a single line of automation. The company discovers it has two service processes, that the side spreadsheet is actually the real system, or that an entire funnel stage can be deleted.

After that, yes, automate. With an agent that reads the real process, operates inside it and knows who to hand off to when a case falls outside the rule.

Which manual in your company does nobody follow? If you can't answer that, that's the best place to start.

If you want to see where the document and reality split in your operation, the diagnostic is the starting point we use for that.