Automation is a multiplier, not a fix. Point it at a good process and you get the same good outcome, faster and more consistently. Point it at a broken one and you get the broken outcome faster, more consistently, and at a volume nobody can review.
This is the most common expensive mistake we see, and AI has made it easier to make.
What actually goes wrong
Errors scale before anyone notices. A person doing a task badly produces a handful of bad outputs a day and usually catches the worst of them. A system doing the same task badly produces thousands, and each one looks as authoritative as the last.
The exceptions disappear. In a manual process, the awkward cases stop on someone’s desk and get handled. Automate without designing for them and they get forced down the happy path — miscoded, misrouted, or silently dropped. The work looks finished. It isn’t.
The workaround becomes permanent. Most real processes contain a step someone invented to get around a problem years ago. Automating it does not remove the problem; it makes the workaround infrastructure, and it will still be there long after everyone has forgotten why.
Fix the workflow first
Before automating anything, three questions are worth more than any tool:
- What is this step actually for? If nobody can say, that is the finding. Some steps exist only because a former system required them.
- What happens on the exceptions? Not the typical case — the 5% that are awkward. Those determine whether automation helps or quietly causes damage.
- What should never run unattended? Anything irreversible, anything that reaches a patient, a payer, or a customer. Decide this before you build, not after an incident.
Answering these usually removes steps. It is common for a workflow to get shorter before any software is written, and that is a better outcome than automating the long version.
Then gate what you build
Once the process is worth automating, the system should still assume it can be wrong. Every operational agent we ship starts in approval mode: it proposes, a named person disposes. Reversible and irreversible actions are separated in code. When an agent needs a human and doesn’t get one, the work parks in a resumable state and waits rather than guessing in order to finish.
You loosen those gates as a workflow proves itself on your own volume — not because a vendor told you the model is accurate enough.
The uncomfortable version
Sometimes the honest recommendation is that a process should not be automated at all, or not yet. We would rather say that during a two-week assessment than eighteen months into a build. That is what the readiness audit is for — and “don’t automate this” is a legitimate result.