Every few years, automation gets a new name. Workflow tools, RPA, low-code, and now agents. The technology changes; the failure mode does not. Teams automate their existing processes, congratulate themselves on the efficiency gain, and discover six months later that they have entrenched the wrong process at higher speed.
Automation is a forcing function. It accelerates whatever it touches. The discipline is choosing what to touch.
The trap of automating bad processes
The first instinct, when given a budget for automation, is to find the most painful manual task and automate it. This is correct only if the painful task is one that should exist at all. Most are not. Most are scar tissue from old systems, old org charts, or old compliance requirements that no one has revisited.
Before automating, the question to ask is not "how do we do this faster?" but "why are we doing this at all?" In our experience, somewhere between a third and half of "obviously automatable" workflows turn out, on inspection, to be things that should be eliminated entirely.
Map the work first
The teams that get automation right do something that looks slow upfront and pays back many times over: they map the actual work, not the documented work. Sit with the people doing the task. Watch the workarounds. Note the spreadsheet they keep on their second monitor that nobody else knows about. That spreadsheet is usually the thing being automated, not the official process.
A two-week mapping exercise often produces a different recommendation than the one that was originally requested. That is success, not scope creep.
Replace the worst part, not the whole thing
The most resilient automations we have shipped are the ones that did the least. They replaced the single worst step of a workflow — usually data entry, usually the part where someone is copying values from one system to another at 5pm — and left everything else alone.
This is unfashionable. Vendors want to sell end-to-end. Internal teams want to ship something visible. But end-to-end automations are brittle, expensive to maintain, and tend to fail in the most expensive way: silently, in the middle of a quarter, when the upstream system changes its CSV format.
A replaceable component beats an integrated platform every time.
Human-in-the-loop is not a step backward
The strongest pattern we have seen for automation in 2026 is one where the human remains in the loop, but at a higher level of abstraction. Instead of triaging fifty emails, they review fifty AI-drafted responses. Instead of writing a report, they edit a generated draft. Instead of approving each invoice, they approve the exceptions.
This is not a fallback to manual work. It is automation calibrated correctly. The human stays in the loop because the cost of a mistake is high, not because the system is incapable.
The cost no one budgets for
Brittle automation has a hidden cost: the team spends 20% of its time keeping the automation running. Logs, alerts, retries, edge cases, the occasional 2am page. This cost compounds. Every new automation added to a fragile pile makes the existing pile harder to maintain.
The right test, before shipping any new automation, is the maintenance test: who owns this in eighteen months? If the answer is "we'll figure it out," the answer is really "the next person on call."
The teams getting compounding returns from automation are not the teams automating the most. They are the teams automating the right things, replaceably, with humans where the cost of being wrong is high. The leverage is in the choosing.