For nearly two decades, "automation anywhere" was a reasonable ambition. Robotic Process Automation (RPA) promised to take repetitive, rule-based work off people's desks — copy this field, log into that system, paste it there, repeat ten thousand times without complaint. It worked because the logic was deterministic. A bot either found the button or it didn't. When something broke, it broke loudly: a missing selector, a mismatched field, a stalled process waiting for a human to notice.
That failure mode was brittle, but it was honest. The bot told you it was stuck.
AI-driven automation does not fail the same way — and that difference is the reason the old playbook needs revisiting before organizations bolt large language models onto their existing automation stacks.
The New Failure Mode: Confident, Not Broken
An RPA bot that hits an unexpected input stops. An LLM that hits an unexpected input keeps going — and produces something fluent, plausible, and often wrong. It doesn't raise an error. It generates an answer that looks exactly like a correct one.
Chain a few AI-driven steps together — extract data, interpret it, decide on an action, execute the action — and you get a process that never visibly stumbles. Each step hands a confident-looking output to the next, and by the time a mistake surfaces downstream, it has often already been acted on: a wrong figure has entered a report, a misclassified case has been auto-routed, a generated message has been sent.
This is the core risk of applying "automate anywhere" thinking to AI without adjustment. The bigger and more end-to-end the task an LLM is given, the more surface area there is for an undetected error to compound before a human ever sees it. Speed and scale, the very selling points of automation, become the mechanism that turns a small mistake into a large one.
The Real Question Has Changed
With RPA, governance mostly asked: did the bot complete the task correctly? It was a binary, verifiable question, because the underlying logic was deterministic.
With AI in the loop, the governing question becomes: who is checking the model's output, and at which point in the process? This is a design question, not just an oversight question — it has to be answered before the workflow is built, not patched on after something goes wrong.
That reframing matters for how organizations should think about tooling.
Why Decomposed, Orchestrated Workflows Are a Better Default Than Monolithic AI Agents
The instinct in a lot of AI adoption right now is to hand a single, capable model an entire process end-to-end — "read the invoice, validate it, update the ledger, notify finance" — and trust it to reason through every step. This mirrors the old "automation anywhere" ambition, just with a smarter engine underneath. But it inherits the same blind spot: one large, opaque task with no natural seams for a human or a rule to intervene.
Modern workflow orchestration platforms — n8n, Zapier, Make, and similar tools, alongside enterprise iPaaS platforms — offer a structurally different pattern. Rather than one model reasoning across an entire business process, the process is decomposed into discrete nodes, each with a narrow, bounded job. This has become a common enough distinction in how practitioners now talk about applied AI: workflows, where an LLM is called at specific, predefined points in an inspectable path, versus agents, where a model dynamically decides its own steps with far less imposed structure. Workflows trade some flexibility for predictability — a trade that makes sense wherever a hidden mistake is costly.
Three structural properties fall out of this approach, regardless of which specific tool is used:
Explicit checkpoints. A human-approval step can sit between "the model proposes an action" and "the system executes it," rather than relying on an agent's internal judgment about when to ask for help. The checkpoint is a property of the workflow's design, not the model's discretion.
Bounded scope per step. Each AI call handles one narrow task — classify this, extract that, summarize this section — instead of one model reasoning end-to-end across an entire process. A smaller task has a smaller blast radius when it fails.
Separation of deterministic and probabilistic logic. Business rules, validations, and calculations that have a single correct answer can be handled by real logic — code, conditionals, lookups — rather than delegated to a model that will produce a plausible-sounding number even when it's wrong. The model is used where judgment or language understanding is genuinely needed, and nowhere else.
A useful side effect: because each node's input and output can be logged individually, a failure can be traced to the specific step that produced it, rather than requiring someone to untangle an opaque end-to-end transcript to figure out where things went wrong.
Where This Framing Has Limits
This isn't a case for structure over capability in every situation, and it's worth being honest about where it breaks down:
Decomposition isn't free, and forcing it onto the wrong task costs something too. Some processes are genuinely exploratory — the right next step depends on what the model discovers at the step before, not on a path anyone could sketch out in advance. Research synthesis, open-ended troubleshooting, and unscripted customer conversations often fall here. Pre-defining every seam in a workflow like that doesn't add safety; it mostly adds friction, and the usual workaround is a wide "catch-all" node that quietly recreates the opaque, end-to-end reasoning the structure was meant to avoid.
Checkpoints only work if someone actually reviews them. At scale, approval steps easily become rubber stamps. Alert fatigue is a real phenomenon, and a review step that nobody meaningfully engages with quietly recreates the unchecked-automation problem it was meant to solve. Designing for attention — fewer, higher-stakes checkpoints rather than many low-stakes ones — matters as much as having checkpoints at all.
Validating a model's output with another model isn't a safety layer. If the "check" step is itself an LLM call, the organization hasn't added a deterministic safeguard — it has added a second probabilistic step that can fail in the same way as the first, sometimes agreeing with the original error rather than catching it.
Orchestration tools widen the credential surface. Workflow platforms typically connect to many systems via stored API credentials. That's a separate governance problem — access control, credential rotation, audit of what each workflow can touch — distinct from the question of whether the AI's output is correct. Solving one doesn't solve the other.
Governance maturity varies by platform. Established enterprise RPA vendors have spent a decade building audit trails, role-based access, and compliance tooling. Newer, more flexible orchestration tools like n8n offer speed and openness — including self-hosting — but organizations should evaluate their audit and access-control maturity on its own merits rather than assuming parity with legacy enterprise platforms.
The Shift in Framing
The lesson isn't that AI shouldn't be used for automation — it's that the unit of automation needs to shrink before the ambition can safely grow. "Automation anywhere" assumed that once a process was automated, correctness was mostly a solved problem, and the remaining job was scaling coverage. That assumption doesn't survive contact with models that fail silently.
The organizations that get this right won't be the ones that automate the most. They'll be the ones that can answer, for every automated step touching a real decision, a real customer, or a real number: where exactly is the check, and does anyone actually look at it?
That's a workflow design question first, and a tooling question second — but having the right tooling, built around decomposition rather than delegation, makes the design question much easier to answer well.