What automation actually preserves
When a business automates a process, the process is not replaced. It is executed at a different speed by a different actor. Every rule, every assumption and every workaround currently embedded in how the work gets done is carried across intact, and the one thing that does not get carried across is the person who used to notice when the rules did not fit.
This is why automation programmes so often produce disappointing results on processes that had obvious problems. The obvious problem was never the process; it was the gap between the written process and the actual one, and that gap was being closed, slowly and imperfectly, by individuals every day. Removing the individual removes the gap.
Three process defects that automation makes worse
Process problems
The process has an undefined decision. Somebody decides whether a discount applies, whether a shipment can be expedited, whether an exception is acceptable — using judgement built from years of experience, without stating the criteria. An agent asked to make the same decision will either refuse most cases or improvise, and both outcomes are worse than the informal judgement they replaced.
Data problems
The process depends on data that is duplicated, stale or contradictory across systems, and a person resolves the ambiguity by asking a colleague. Two records disagree about the same field; the person knows which one is right because they know the history. An agent reading the same two records has a coin to toss, and nobody will notice the toss because the output still looks plausible.
Organisational problems
The process crosses a boundary that nobody owns end to end. Sales owns the order, operations owns the schedule, finance owns the invoice, and each optimises its own measure. An agent spanning the boundary does not resolve the conflict; it surfaces the conflict sooner, with less tolerance, and no more authority than the person who used to absorb it.
The diagnostic that distinguishes the two cases
Before commissioning a workflow, one question separates a process worth automating from a process that needs redesign, and it is answerable in an afternoon: what would an expert do differently from a competent newcomer?
If the answer is nothing — the process is genuinely procedural, the steps are unambiguous, and an expert is simply faster — then it is a good candidate for automation as it stands, and the business case is mostly about cost per transaction and volume.
If the answer is a long list of judgement calls, context, relationships and exception handling, then the process is not yet specified well enough to automate, and the work is to specify it. That specification is the expensive, valuable part, and it is usually done by the people doing the work rather than by the technology team. The method for doing it properly is described in mapping a process before you build the agent.
Redesign is not the same as improvement
There is a version of this argument that becomes an excuse to do nothing, and it is worth naming directly. Redesign can take eighteen months, involve every stakeholder, and end in a document nobody uses. The claim is not that redesign should precede all automation; it is that redesign should precede the automation of decisions the business has never actually defined.
In practice this usually means a narrower scope. Automate the well-understood majority of transactions, route the ambiguous remainder to the people who handle them today, and let the proportion of ambiguous cases tell you what to redesign. That sequence produces a measurable result in weeks, keeps the human judgement that the process depends on, and generates the evidence about where the redesign is actually needed. The distinction between measurement and guesswork is the same one that separates a defensible business case from a forecast in calculating the value of enterprise AI.
What to do with the agent catalogue
Most enterprises now have a list of intended agent use cases, and it is usually long, usually prioritised by enthusiasm, and usually untested against the questions that would determine whether any of them is worth building.
- Take the list and add one column: what decision does this system make, and who is accountable for it today? Entries with no answer are not agent projects. They are requests for better data or clearer policy.
- Sort the remainder by the cost of the current handling, not by the sophistication of the proposed solution. A forty percent saving on a low-volume, low-consequence process is worth less than a modest improvement on the one where errors are expensive.
- For the top handful, run the diagnostic from the previous section before committing anything. If the process is genuinely procedural, build it. If it is judgement, specify the judgement first, and decide explicitly who will own it after the system is in place.
None of this argues against automation. It argues for sequencing it after the work that determines whether it will help, which is cheaper than discovering afterwards that the system faithfully reproduced every problem the organisation already had. The distinction between the two outcomes is set out in more detail in when to use AI, rules or conventional automation.