Comparison
A script replays a click path and breaks when the interface changes
RPA replays a recorded click path through a user interface and breaks when that interface changes. An intelligence layer reads the same systems at the boundary, applies rules kept in plain text, and escalates what it should not decide alone. When a rule is wrong, someone edits the note and the next run follows it.
Why bots break
The failure mode is structural rather than a quality problem. A script is bound to a screen, so a screen change is a breakage — and screens change for reasons nobody in your automation team controls.
Reported RPA project failure rates run 30–50%, with maintenance frequently exceeding original build cost, according to a 2026 market survey and vendor analysis of the same shift. Blue Prism now publishes on fusing RPA with agents rather than defending scripts.
Those are other people's measurements, reported as theirs. We have measured nothing about anyone's RPA estate and this page never says otherwise.
Is RPA dead?
No. A script is the right tool where the interface is stable, the path is deterministic and the volume is high. That is what it was built for, and replacing those is a waste of everybody's time.
What it cannot do is judge an ambiguous case, read across systems that disagree, or explain which source it believed. Those are different problems, and they were never what a recorded click path was for.
The difference, in one line
A script replays a click path and breaks when the interface changes. The layer reads systems at the boundary and applies rules kept in plain text. When a rule is wrong, someone edits the note and the next run follows the new rule — no redeploy, no model change, and the correction is in the audit trail.
Intelligence layer, iPaaS and RPA compared
| Intelligence layer | iPaaS | RPA | |
|---|---|---|---|
| What it moves | Decisions, and the result of one | Data, on a defined mapping | Keystrokes and clicks |
| Where it reads | At each system's boundary, read-only | At an API, on both ends | At the screen |
| When a screen changes | Nothing — it never read the screen | Nothing — it never read the screen | It breaks |
| On an ambiguous case | Applies your rule, escalates outside tolerance | No concept of one | No concept of one |
| How a rule changes | An operator edits a note; next run follows it | A change request to the mapping | An engineer re-records the script |
| What it leaves behind | The decision, the rule and the source believed | A transfer log | A run log |
Categories, not products. No vendor is named in this table — naming one would imply a relationship that has not been stated. The iPaaS column describes what integration platforms do as a category: move data between systems on defined mappings, without judgement.
What replaces the maintenance bill
Correctable. A reviewer edits the rule. The next run behaves differently. No redeploy, and the change is attributable.
The fix was not a better model. The fix was writing down what "matching" actually means here, so the agent stops inferring it.
ops/vendor-onboarding.md
The honest caveat, and it stays: this is a different shape of maintenance, not the absence of maintenance. The knowledge base needs owners. The note's own open section is the proof — two vendors send consolidated invoices covering several POs, current behaviour splits them, wrong about a third of the time, not yet solved.
This is a services engagement, not a product swap
There is no licence to switch to. Delivery is map, build and run, and the layer sits over the systems you already run — so the question is not which product replaces which, it is which workflow is worth scoping first.
Anyone arriving here looking for a product to compare against their current one should know that in the first screen rather than the last.
What we would leave your bots doing
Stable-interface, high-volume, deterministic paths stay exactly where they are. The layer takes the work that crosses systems, needs judgement, or produces an exception — which is usually the work nobody managed to automate in the first place.
The mechanics are on what the intelligence layer reads and writes back, the rules on rules kept in plain text an operator can edit, and the trail on where the correction lands in the audit trail. The category argument behind the comparison is on enterprise intelligence, defined.
Questions
Straight answers.
Is RPA dead?
No. A script is the right tool where the interface is stable, the path is deterministic and the volume is high. What it cannot do is judge an ambiguous case, read across systems that disagree, or explain which source it believed. Those were never its job.
What is the difference between RPA and an intelligence layer?
A script replays a click path at the screen and breaks when the screen changes. A layer reads at each system's boundary and applies rules kept in plain text, so a rule change is an edit to a note rather than a re-recording by an engineer.
Why do RPA bots keep breaking?
Because they are bound to a user interface they do not control. Any change to a screen — a field moved, a step added, a vendor release — breaks the recorded path. Reported project failure rates run 30–50%, with maintenance often exceeding the original build cost.
Do we have to switch off our existing bots?
No, and mostly you should not. Stable, high-volume, deterministic paths are exactly what a script is good at. The layer takes the work that crosses systems, needs judgement, or produces exceptions — which is usually the work nobody managed to automate anyway.
Does this cost less to maintain than RPA?
We have no cost figure and will not invent one. What changes is the shape: maintenance moves from engineering re-recording scripts to the people who own the rule editing a note. That is cheaper in most estates and it is still maintenance, not its absence.
Start here
Bring us one workflow.
Tell us the process that crosses the most systems. You get a scope, a measure and a delivery plan back — and a straight answer if we think it is not worth building.
Get in touch