Three different tools, three different jobs
Most automation projects that go badly went badly at the tool-selection stage, and usually because the tool was chosen before anyone had looked closely at the process. So it helps to be precise about what these three things are, because they are usually discussed as though they compete and they mostly do not.
- No-code connectors such as Zapier, Make and Microsoft Power Automate move structured data between systems when something happens.
- RPA, or robotic process automation, drives an application's user interface the way a person would, because there is no other way in.
- AI automation reads unstructured input, applies judgement against rules, and acts.
They fail differently, they cost differently, and the sensible answer for a real process is often two of them working together.
No-code connectors: Zapier, Make, Power Automate
What they are genuinely good at: a trigger fires, structured data moves, a record is created. Form submission creates a CRM lead. New row in a sheet posts to Teams. Invoice paid in Xero updates a project. These tools are excellent at this, cheap, and fast to build with. If your problem is this shape, use one, and be sceptical of anyone who tells you otherwise, including us.
Where they run out of road:
- The input is a PDF, an email body or a document. Connectors move data; they do not interpret it.
- The decision has more than a handful of branches. Multi-branch flows become a wall of connected boxes that nobody will touch six months later.
- Genuine exception handling. Most flows have a happy path and an error notification, and the error notification is where work goes to be forgotten.
- Volume economics. Per-task pricing is cheap at hundreds and surprising at hundreds of thousands.
- Auditability. You can usually see that a step ran. Reconstructing why a decision went one way eighteen months later is a different question.
The honest summary: if the trigger and the data are already structured and the logic is simple, a connector is the right answer and anything else is over-engineering.
RPA: robots driving a screen
RPA exists for one reason: a system you must use has no API, cannot be changed, and someone has to click through it. That is a real problem and RPA is a real answer to it.
Where it works: legacy line-of-business software, a government portal with no integration, a vendor system whose API costs more than the automation is worth.
What it costs you: RPA is inherently brittle, because it depends on a user interface staying exactly where it was. A vendor update that moves a button breaks the robot. A screen resolution change breaks the robot. A slow-loading page breaks the robot. Maintenance is not an occasional tax; it is the running cost, and it is routinely underestimated at purchase.
There is a second cost. RPA lets you avoid fixing the underlying integration problem, which is comfortable in year one and expensive by year three.
The honest summary: use RPA when there is no other door, size the maintenance realistically, and treat it as a bridge rather than a destination.
AI automation: reading and deciding
What it is genuinely good at: input that varies. A purchase order from one customer looks nothing like one from another. An email describing a problem is written differently every time. A supplier's invoice layout changes without notice. Language models read these the way a person does, by understanding the content rather than matching a coordinate on a page, which is why the previous generation of template-based extraction never solved this and this generation does.
It is also good at decisions that need a small amount of judgement inside firm rules: is this the same request that arrived by email yesterday, does this variance fall within tolerance, is this complaint about billing or delivery.
What it costs you: more per run than a connector, because it is doing more work. It requires an evaluation set to know it still works after a model update. And it needs designing for uncertainty (confidence thresholds, escalation paths, approval gates) which is engineering effort a connector does not demand.
Where it is oversold: as a replacement for deterministic logic. If your rule is "apply the contract price", encode the rule. Asking a model to remember your pricing policy on every run is slower, more expensive and less reliable than a lookup, and it is the most common design mistake we see.
The honest summary: reach for AI when the input is unstructured or the decision needs interpretation. Not before.
The comparison, side by side
| No-code connectors | RPA | AI automation | |
|---|---|---|---|
| Handles unstructured input | No | Only what it can see on screen | Yes, that is the point |
| Needs an API | Yes | No | Preferred, not required |
| Build effort | Hours to days | Days to weeks | Weeks |
| Running cost per item | Very low | Low | Moderate, scales with volume |
| Maintenance burden | Low | High: UI changes break it | Moderate: needs evals |
| Predictability | Total | Total until it breaks | Bounded by rules and gates |
| Exception handling | Weak | Weak | Designed in |
| Audit trail | Basic | Basic | As detailed as you specify |
| Fails by | Erroring loudly | Breaking on a UI change | Drifting quietly without evals |
The last row is the one to sit with. Connectors and RPA fail loudly, because something stops and someone notices. AI automation can fail quietly, becoming gradually less accurate as inputs or the underlying model shift. That is not an argument against it; it is an argument for evaluation suites, which is why any serious proposal includes one.
Why real systems combine them
A well-designed automation for, say, purchase order intake looks like this:
- A connector watches the orders mailbox and drops attachments into a queue. Cheap, reliable, boring.
- AI reads the purchase order (line items, part numbers, quantities, delivery instructions, whatever the customer put in the email body instead of the document) and returns structured data with a confidence score per field.
- Deterministic code applies the rules: catalogue matching, contract pricing, unit conversion, credit check. These are lookups and comparisons, not judgement calls, so nothing here goes near a model.
- A connector or API call creates the sales order in the ERP.
- Anything below the confidence threshold, or failing a rule, goes to a person with the source document and the specific uncertainty highlighted.
Each tool is doing the thing it is best at. The AI is used at exactly one step, the one that requires reading, which is also what keeps the per-run cost sensible.
How to choose
A short decision path that gets it right most of the time:
Is the input already structured? If yes, and the logic is simple, use a connector. You are done.
Does the target system have an API? If no, and you cannot get one, RPA may be the only route. Budget for maintenance honestly.
Does the process require reading or interpretation? If yes, AI belongs in the design, but only at the reading and interpretation steps, with deterministic code doing the rules and a connector doing the plumbing.
Is the rule set stable and writable? If yes, encode it. If the rules turn out to be inconsistent, that is a process finding and it is worth more than any tool decision.
And one that applies regardless of which you pick: map the process before you choose. Almost every expensive automation mistake we see was made by selecting a tool first and then discovering the process did not have the shape the tool assumed.