RPA vs. IPA: the actual difference (not the marketing one)

Every vendor page will tell you Intelligent Process Automation is “RPA plus AI.” That’s technically true and almost useless, because it implies the difference is a feature you bolt on. It isn’t. The real dividing line is about who — or what — owns the decision the moment the process leaves the happy path.

Classic RPA is a script wearing a human costume. It clicks the buttons, copies the fields, and fills the form exactly the way a person would — right up until the screen looks slightly different than expected, at which point it stops, because it was never told what to do next. That’s not a flaw to be embarrassed about; it’s the design. RPA is deliberately deterministic, which is exactly why it’s auditable, cheap, and safe enough to run unattended in a bank at 3 a.m.

IPA is what you get when you wrap that deterministic execution layer in judgment: document understanding that can read an invoice it’s never seen before, a process-mining layer that tells you what actually happens (not what the SOP says happens), and — as of 2025 and 2026 — LLM-based reasoning that can decide what to do when the defined path runs out, instead of just stopping.

RPA — the execution layer Decision model Deterministic. If X, then Y. No judgment calls. Handles change well? N…

That last row is the one people skip past, and it’s the important one. An RPA bot fails loudly — it stops, and someone gets a ticket. A poorly-governed IPA agent can fail quietly, by taking a wrong action with total confidence. That’s not an argument against IPA. It’s an argument for building the observability layer before you turn the agent loose, not after the first incident.

A researcher at the National University of Singapore’s Institute of Systems Science put the underlying problem plainly at an NUS-ISS learning day years before “agentic AI” was a buzzword — the quote holds up better than most of what’s been written since: Yu Chen Kuang argued that there is much more to implementing RPA than simply plugging in a software package. Swap “RPA” for “an AI agent” and the sentence hasn’t aged a day.

Exception Debt: the real reason automation projects die

Here’s the unpopular take: most of what gets blamed on “the AI” or “the bot” in a failed automation program isn’t a technology problem. It’s an accounting problem. I’m going to give it a name, because once you can name it, you can measure it and budget for it instead of getting surprised by it eighteen months in.

Exception Debt is the gap between the exception paths your automation actually handles and the exception paths your process actually generates in the real world. Every automation launches with a happy path and a handful of anticipated exceptions the team could think of in a workshop. Production doesn’t care what you thought of in a workshop. It generates edge cases nobody wrote down — the customer with two middle names, the invoice in a currency the template didn’t expect, the PDF that’s actually a scanned photo of a PDF.

The reason EDR matters more than almost any other metric in an automation program is that it doesn’t grow in a straight line. It grows combinatorially. Every additional system your process touches — a new CRM field, a second ERP, a partner API — doesn’t just add its own failure modes; it adds failure modes at the seams between systems, and seams are where nobody owns the exception. Touch four or five systems and the number of realistic edge cases isn’t 20% higher than a two-system process. It’s multiples higher.

This is also why “add an LLM to the RPA bot” so often disappoints. If the underlying process was never mapped well enough to know its own exception surface, bolting a language model onto a brittle foundation doesn’t erase the debt — it just changes the failure mode from a loud stop to a confident, wrong, unaudited action. Several of the 2026 surveys on agentic AI project cancellations essentially describe Exception Debt without naming it: Gartner’s research on the topic points to unclear business value and inadequate risk controls — not model quality — as the leading reasons more than 40% of agentic AI projects are expected to be cancelled by the end of 2027.

What the market data really says (and where analysts flatly disagree)

Nearly every article in this space opens with a single, suspiciously precise market-size number, as if one research firm’s spreadsheet were gospel. It isn’t, and pretending otherwise is itself a small trust problem. So instead of picking the most flattering figure, here’s what seven current research firms actually estimated for the 2026 global IPA market when I pulled their published numbers side by side:

The honest takeaway isn’t “the market is worth $X.” It’s that seven credible firms, using different methodologies and market definitions, land within a fairly tight band of roughly $17.7–22.8 billion for 2026, with projected CAGRs mostly clustering between 13% and 17% (Grand View Research is the outlier at 22.6%, likely reflecting a narrower market definition weighted toward faster-growing services). If someone hands you a single decimal-precise figure without a range, they either haven’t checked the other six reports or they’re rounding to the number that sells the pitch.

Process mining — the discovery layer that tells you what your process actually does, as opposed to what the SOP says — shows the same pattern of definitional chaos, with estimates for 2026 ranging from roughly $0.85 billion to $5.45 billion, depending on whether the analyst is counting pure-play process mining or bundling in adjacent process-intelligence spend. Directionally, though, every single firm agrees on one thing: this is one of the fastest-growing corners of enterprise software, with most CAGR estimates sitting in the 30–50% range through the early 2030s.