Before we write a single line of agent code, we spend time with the people who currently do the work. Not with their manager. Not with the person who approved the project. With the people who handle the process every day — including the ones who know the unofficial workarounds that never made it into the documentation.
This is the process audit, and it's not a preliminary formality. It's where most of the real work happens.
Why most AI projects fail at the process layer
The pattern is consistent. A company identifies a process that seems automatable — say, routing inbound enquiries. They buy a platform or hire a developer. The tool is built around the documented version of the process. It goes live. Within a few weeks, it's handling only a fraction of cases correctly because the documented process and the actual process are different things.
The actual process includes the email that comes in from a known client with no subject line that everyone knows goes straight to the account manager. The invoice that arrives as a photo of a piece of paper taken with someone's phone. The support ticket that's classified as billing but is actually a cancellation request written politely. None of these are in the documentation, but all of them happen weekly.
An agent that doesn't know about these cases either fails silently or escalates everything — both of which defeat the purpose.
What we map in the audit
We're looking for five things in the audit sessions:
The trigger. What exactly starts this process? An email arriving, a form submitted, a calendar event, a database record changing? The trigger needs to be precise — not "when we get an enquiry" but "when an email arrives in the info@ inbox between 08:00 and 18:00 CET." The precision matters because the agent needs to know when to act.
The decision points. At what moments does the current process require a judgment call? Who makes that call and based on what information? Decision points are where the process is hard to automate — and knowing where they are tells us whether a Type 2 or Type 3 agent is appropriate.
The exceptions. What cases break the normal pattern? We ask the team to name the five most awkward situations they've handled in the last month. These are the edge cases the agent will encounter in production, and they need a defined handling path before we start building.
The outputs. What exactly does a successful completion of this process look like? A record updated in a CRM? An email sent? A document filed? We need to know not just what happens but where it happens — which system, which field, which folder.
The error indicators. How does the current team know when something has gone wrong? An agent that fails silently is worse than a manual process. We need to design the detection and escalation before we can trust the agent to run unsupervised.
When the team disagrees
This is the most useful part of the audit and also the one that produces the most discomfort. When we ask three people who handle the same process how a decision is made, we often get three different answers.
This doesn't mean the process is broken. It means it's undocumented. The team has developed different local conventions, and because the process has been running without problems, no one has ever needed to reconcile them. Until now.
An agent has to follow one consistent logic. If the team disagrees on how the decision is made, we can't build the agent until that disagreement is resolved — not by us, but by the process owner. We facilitate that conversation; we don't make the call.
In practice, this often means the audit is the most valuable thing we deliver, independent of whether a build follows. Getting a process fully documented and its edge cases agreed often uncovers problems that were invisible when a human was handling everything through intuition.
What the audit produces
The audit outputs a written document that contains: the process map with all identified decision points, the exception inventory with agreed handling for each, the acceptance criteria for the agent, and a recommendation on which agent type is appropriate and why.
If the process isn't ready for automation — if the edge case rate is too high, or the team can't agree on the decision logic, or the error cost is too high to start with full autonomy — we say so in the audit document. Sometimes the right recommendation is to fix the process manually before involving an agent. We'd rather say that now than deliver an agent that sits unused.
If the process is ready, the audit document becomes the specification. We build exactly what it describes. The agent is measurable against it, and the team can hold us to it.