Automation makes a bad process faster and more expensive. This is not a new observation, but it's one that gets ignored regularly when an organisation is excited about AI. We've seen it from both sides — as the people being hired to automate something, and as the people who had to explain why the automation was making things worse, not better.
The question isn't whether AI can handle a workflow. With enough effort, you can automate almost anything. The question is whether automating it is a good idea, and whether the process underneath is stable enough to hand to a system.
The readiness criteria we use
In our workflow audit phase, we evaluate every candidate workflow against five criteria. A workflow that fails more than two of them is not ready for automation. Fixing it is the right next step — not building an agent.
Is the decision logic consistent? Could two people, given the same input, reliably reach the same decision by following the same rules? If the answer is "it depends on who's doing it", the variation needs to be understood and resolved before an agent can encode it. Agents reflect the rules you give them. Inconsistent rules produce inconsistent automation.
Is the input well-defined? What does the agent receive, and in what form? If the answer is "various formats, it depends" — that's not a definition, it's a description of the problem. Agents need defined input schemas or robust pre-processing pipelines. Both are buildable. Neither is free.
Is there a ground truth you can measure against? Can you look at an agent's output and determine objectively whether it was correct? If correctness is subjective or contextual, building evaluation infrastructure is very difficult. You need historical examples of correct decisions to test against.
What happens when it's wrong? An agent running at 95% accuracy on 1,000 items a day produces 50 errors a day. Are those 50 errors catchable before they cause damage? Is there a human review step? Is the cost of a wrong decision acceptable while the human review queue clears? If errors are costly and hard to catch, the agent threshold may need to be higher than 95%.
Who owns the process after deployment? There must be a named person or team who is responsible for the agent's outputs once it's live. "The AI is responsible" is not an acceptable answer. Someone needs to own the monitoring, handle escalations, and make decisions when the agent's performance degrades. If there's no answer to this question, the deployment will drift without oversight.
What to fix before you build the agent
The most common situation we encounter is a workflow that fails one or two criteria in recoverable ways. Here's what that usually means in practice:
Inconsistent decision logic is usually fixable through working sessions with the people who do the work. The goal is to surface the implicit rules they're following and make them explicit. This is slower than it sounds, because people often don't know their own decision rules until they're confronted with edge cases. A structured set of 50–100 historical examples, discussed case by case, usually gets you there.
Undefined input formats require a pre-processing layer before the agent. This is engineering work, not AI work. The agent receives clean, structured input. The pre-processing layer handles the variation. These are separate problems that are better solved separately.
The workflows that automate most cleanly are rarely the most complex. They're the ones where someone spent time being rigorous about what the rules actually are.
When the honest answer is "not yet"
Sometimes the audit surfaces a workflow that isn't ready and can't be made ready quickly. The decision logic is genuinely contextual. The errors are genuinely costly. The input variation is too wide.
The honest answer in this situation is: automate a smaller scope. Take the part of the workflow that is consistent, has defined inputs, and produces errors with recoverable costs — and automate that. Leave the rest with humans.
A partial automation that runs reliably is more valuable than a full automation that needs constant intervention. Start with what the process can actually support.