The most common AI automation request I hear starts in the wrong place: take this process and automate it.
The process in question is usually one nobody has examined in years. It grew by accretion. It has steps that exist because of a system that was retired, approvals that exist because of a person who left, and handoffs that exist because two teams never agreed on ownership. It survives because people quietly work around its worst parts every day.
Automation does not inherit the workarounds. It inherits the workflow.
That sentence is the whole argument. In practice, it changes where an automation initiative begins: not with the tool, but with the gap between the process the organization describes and the one people actually operate.
What automation actually amplifies
An automated process is the version of the work you have encoded, executed faithfully and at speed, without the human judgment that may have been holding it together.
Consider a composite example assembled from patterns I have seen repeatedly. An operations team automates order intake. The documented process is simple: an order arrives, the system validates it, and fulfillment begins. The automation is built to that description and behaves exactly as configured.
Within a month, fulfillment quality drops. Nobody can explain it because the automation is performing perfectly against its specification.
What the document never captured was that an intake coordinator had been catching a recurring mismatch between the ordering system and the inventory system. It was a known defect that two teams had argued about for a year without resolving ownership. Her correction took thirty seconds per order. It appeared in no process document because, from her perspective, it was not a step. It was just knowing the system.
The automation did not remove her step. It removed her from the loop, and with her went the correction that made the workflow viable. The defect she had been absorbing flowed straight through to customers at machine speed. Throughput metrics improved while the outcome deteriorated, so the damage compounded before anyone connected the two.
This is the strange signature of automating a broken process: faster, better on the activity metrics, worse in the outcome. The organization did not automate the work. It automated the version of the work that existed on paper.
The workarounds are the map
Before automating anything, find the gap between the documented process and the operated process. The gap is where the risk lives.
People rarely invent extra work without a reason. When someone re-keys data between two systems, checks a number against a second source, or walks an approval to a specific person instead of submitting it through the queue, they are compensating for something. It may be bad data, a broken integration, an ownership gap, a control that fails silently, or an exception path the official process never captured.
Every workaround marks a place where the documented process is incomplete: a defect, a missing exception path, or a control that lives only in someone's head.
Finding these takes more than asking someone to describe the process. People tend to describe the official version. The compensations are invisible to them precisely because they have become skill. Three questions surface them better than most process documents:
- What do you check before you trust what the system tells you? Each answer points to a data, integration, or control risk with a name and a location.
- Where do you go around the official path, and when did you start? The timing often points to the system change, policy decision, or reorganization that created the gap.
- What would break first if you were out for a month? People usually know which quiet corrections nobody else performs. This question gives them permission to name them.
Run this conversation across a workflow and you produce something more valuable than a process map. You produce an inventory of defects, controls, exceptions, and tacit judgment, ranked by business impact, frequency, detectability, and the human effort currently required to contain each risk.
What fixing the workflow actually means
"Fix the workflow first" is easy to say and vague enough to be useless. Concretely, it involves four kinds of work, usually in this order.
Remove before you improve. A meaningful fraction of most aging workflows no longer earns its place: approvals that no longer control real risk, reports nobody reads, and steps that exist because of a constraint that disappeared years ago. Automating a step creates an ongoing obligation to maintain, secure, and debug it. Deleting a step costs one decision. Every step you remove is a step you never have to automate.
Resolve ownership before you resolve technology. In the composite example, the underlying defect was not only the data mismatch. It was that two teams had spent a year not owning it. Persistent workflow defects often survive at boundaries where accountability is contested or absent. Tooling does not settle a boundary dispute. Someone with authority has to assign the seam to an owner. This is unglamorous organizational work, and it is a prerequisite for automation because an agent operating across an unowned seam has no one accountable for what happens there.
Repair the data the process depends on. Automation applies its configured trust rules consistently, including when those rules select the wrong source. If two systems disagree about the state of the same record, an experienced person may know which one to trust and under what conditions. An automated process needs that authority made explicit. The data risks surfaced by the workaround inventory are not cleanup items to schedule for later. They are load-bearing.
Make the judgment explicit. Define the exception paths, validation checks, stopping conditions, and escalation ownership that experienced people have been carrying in their heads. Decide what the automation may resolve, what requires confirmation, and what must stop and wait for a person. If the automation cannot recognize when routine work has become an exception, it is not ready.
Only after this does automation enter. Last does not mean waiting for a perfect process. It means understanding and simplifying the bounded piece you are about to encode, then automating it in controlled increments with outcome measures, exception measures, and visible failure states.
By then, something interesting has usually happened: the workflow is dramatically better before a line of automation exists. I have seen cases where the removal-and-ownership pass captured much of the available benefit, and the automation that followed was smaller, cheaper, and safer than the original request. That is not a failure of the automation initiative. That is what it looks like when the sequence is right.
Where AI changes this, and where it does not
It is fair to ask whether modern AI changes the calculus. Agents can read context, handle ambiguity, and adapt in ways that traditional scripted automation cannot. Does workflow-first still hold?
It holds more, not less. Traditional automation often fails at an explicit boundary. An AI agent may cross the same boundary by making a plausible inference. That can make the failure quieter, more variable, and harder to detect. A process that stops draws attention. A process that continues while producing plausible errors may survive until a customer complaint, a reconciliation, or an audit.
What AI genuinely changes is the cost of the diagnostic work. It can transcribe and synthesize workaround conversations, compare the documented process with system logs, and surface places where the two diverge. Work that once required substantial manual effort can be compressed dramatically.
AI cannot decide whether every divergence is a defect, a necessary control, or sound judgment applied to an exception. The people who operate and own the workflow still have to validate what the evidence means. Used this way, AI accelerates the understanding that must precede automation. It is often one of the highest-return early AI deployments in the initiative.
Automation is not a way to avoid understanding a process. It is a reward for having understood it.