Loop vs RPA

Robotic process automation records clicks on screens. A standing-order loop records a recipe that runs when a signal fires, skips when nothing changed, and leaves a run page. Gartner defines RPA as software that automates tasks by using scripts that emulate human interaction with an application user interface. That definition is honest about the superpower — any screen — and the weakness — the screen.

The two categories are cousins, not synonyms. Both sit above systems of record. Both can run unattended. Both fail when nobody owns the definition of the job. They fail for different mechanical reasons, and programmes that collapse them into “automation” spend years fixing the wrong fragility.

Three adjacent nouns, so they do not leak into this comparison:

• Loop. Compiled repeat work with triggers and a run page. See loop engineering and six things that start a loop.
• Eval loop. Independent verification that a job finished — not UI replay, not a trigger. See eval loops for enterprise agent harnesses.
• Agentic workflow. A person-designed sequence with stops — often interactive. See what is an agentic workflow. Different from both RPA and loops.

IBM’s explainer on robotic process automation describes the same pattern in plainer language: software robots execute repetitive office tasks by interacting with applications the way a person would — extracting data, filling forms, moving files. IBM is also careful to separate process-driven replay from data-driven AI. That split is the educational core of this page. A bot follows a recording. A standing-order loop follows a recipe attached to a signal. A model, if it appears at all, is an optional step for messy reads — not the reason the job exists.

This is not a hit piece on UiPath, Automation Anywhere, Blue Prism, or desktop flows in Power Automate. Those products built real value on a real constraint: when the only path into a 1990s terminal or a thick-client ERP is click-type-click, RPA is still the right hammer. Deloitte’s Global Intelligent Automation survey found RPA in the mainstream — seventy-four percent of respondents were already implementing it — and also found that toolkits widen because one technology does not cover the work. Integration debt, not model quality, is what usually caps scale.

The mistake is using the hammer when the job already has an API, a webhook, or a file drop — and then calling the recording “AI transformation.”

What RPA is, as a category

RPA’s contract is the user interface. A person performs a task; a recorder or a low-code author turns that performance into a script; a runtime called a bot or robot executes the script against the same screens. Gartner’s wording matters: the executable is the robot; the thing being automated is a task inside a process, not necessarily the process end to end.

That is why IBM’s companion note on types of RPA is worth reading even if you never buy IBM. The piece argues that “robotic process automation” is partly a misnomer — the technology is often robotic task automation — and that orchestration across humans, decisions, and multiple automations is a different job, closer to business process management. Standing-order loops live on that orchestration side of the line: they care about the signal, the skip, and the run, not about whether the fetch happened by API or by a leftover bot.

RPA shines in constrained, UI-only environments:

• Legacy green-screen or thick-client ERP with no stable API
• High-volume, low-variance data entry where the steps never change and the screen rarely does
• Short-lived bridge automation while IT delivers a proper integration
• Attended automation where a person still drives the session and the bot takes the repetitive keystrokes

Operator virtues of a mature RPA programme are real:

• Deterministic steps when the UI cooperates
• A central bot inventory, if the CoE actually has one
• Audit logs of bot accounts, if IT enforces service identities instead of shared logins
• Speed to a first automation when the alternative is a twelve-month interface project

Operator failures everyone has seen are also real:

• Brittle selectors — CSS changes, A/B tests, localisation, a vendor’s “minor” redesign
• Timing flakes — load spinners, network blips, a pop-up that was not on the recording
• No skip semantics — the bot runs, clicks through zero rows, and emails success
• Outcomes in bot logs, not on a roster-facing run page
• Shadow bots on personal laptops when the IT backlog is measured in quarters

Deloitte’s survey is useful because it normalises the second list. Organisations started with RPA and OCR, got value, then hit the limit of automating the current process with one or two tools. The response was a wider toolkit and, often, process redesign. That is the mature reading. The immature reading is “replace the CoE with agents.”

What a standing-order loop is, as a category

A loop is a standing order in the company’s automation library:

• Triggers — schedule, file, data change, drop, ping, run now. See six things that start a loop.
• Recipe — the trusted sequence, versioned, replayable
• Run page — what ran, skipped, produced, notified
• Skip when nothing changed — quiet success is success

Loops prefer structured paths: a CRM field changed, a file hash matches last week, a billing webhook is idempotent. When inputs are messy — a PDF allowance list, a scanned statement — a loop may include a bounded model step, then return to deterministic writes with write-back governance. The model is not the loop. The loop is the standing order that decided to call a reader.

Compare loop vs workflow vs agent: loops compile repeat work; agents reason on novel paths; workflows carry explicit human stops. RPA is a fourth cousin — UI replay — not a substitute for any of the three. If you only remember one sentence from this page, remember that.

Operator test from how to evaluate loop engineering: run ten times with empty inputs. Do you get ten skipped run pages — or ten green checkmarks that lied? RPA programmes often fail that test because “the script finished” is treated as success. Finishing a script that had nothing to do is how Finance learns to ignore the 6am email.

McKinsey’s 2025 State of AI is not an argument to rip out RPA. It is an argument to stop treating screen bots as the only automation language while models make reading cheap and governed writes remain hard. Usage without redesign is the survey’s recurring theme. Redesign, for repeat work, looks like a recipe library with start conditions — not a larger bot farm.

Side by side

Neither row replaces your system of record. Both sit above CRM and ERP. They are part of the automate pillar in the four pillars of an enterprise AI platform, not a second ledger. If a bot or a loop writes without a quoted payload and a signer, you have a control problem that no category name will fix. See what is AI governance.

When RPA is still the right tool

Choose RPA — or keep the bot you have — when most of the following are true:

1. No integration exists and IT has not prioritized one. The screen is the only door, not the door a citizen developer preferred.
2. The UI path is stable. That module has not been redesigned in years, and the vendor’s roadmap does not threaten it this quarter.
3. Volume justifies babysitting. Operations accepts selector maintenance as opex and has a named owner for break-fix, not a hero who “knows the recording.”
4. The action is fetch-shaped. Scrape, download, paste into a governed folder that a standing-order loop picks up next. The bot’s job ends when the file lands.

That last pattern is common and sensible: RPA fetches; the loop processes. The bot is a temporary or permanent adapter. The loop owns variance checks, notifications, and draft writes waiting on sign. You have not “failed at AI” because a 1990s terminal still needs a click. You have been honest about the interface.

Also keep RPA for attended automation where a person is already in the session. A desktop helper that types the next twenty fields while a clerk reviews exceptions is a different object from an unattended Monday close. Do not force that helper into a standing-order costume.

NIST’s AI Risk Management Framework still applies if the bot’s output later feeds a model or a write. Map the system. Measure the outcomes. Do not pretend a bot log is Measure if only the CoE can read it.

When a standing-order loop is the right tool

Choose a loop when:

1. The signal is already digital — webhook, CRM field, calendar, a file hash, an event from billing
2. Skip semantics matter — month-end with no exceptions should not spam Legal
3. The roster needs a run page — audit, handoffs, collaborative AI
4. You will reuse the recipe across teams without copying Slack threads

IBM on event-driven architecture is the right adjacent reading for this side of the comparison. Something happened elsewhere; your process responds with idempotence and a record. If the same event arrives twice, one run should process and one should skip. Bots can be written that way. They often are not, because the recording did not include “check whether we already did this.”

Loops are also the right tool when the “RPA job” is actually document intelligence wearing a bot costume. Bots should not pretend to read contracts. A loop step may use a model to extract tables; the write still quotes a payload and waits on sign. See loops for legal and compliance.

What goes wrong in hybrid programmes

Lift-and-shift the bot into a loop skin. Changing the logo does not add skip semantics or a roster. If the runtime is still clicking Production with a god account, you kept the brittleness and added a new name.

Loop that secretly RPAs the CRM. If your “AI automation” is still one service identity clicking through a web UI because “the connector was slower,” you have not moved categories. You have hidden a bot behind a recipe.

RPA for PDF intelligence. Screen replay is a poor reader. If the job is “understand this invoice,” you need a document step with evals — see eval loops for enterprise agent harnesses — not a tighter selector on the PDF viewer.

No ownership. RPA bots die when Linda leaves. Loops die when “the recipe” lives in Linda’s channel. Loop engineering is org-owned recipes — the same discipline as shared close checklists. Deloitte’s wider-toolkit finding is really an ownership finding: more tools without a named owner is how shadow automation returns.

Automation that cannot refuse. Whether the runtime clicks or reacts to a webhook, an unsigned write should not land. What is write-back governance is category-agnostic. If your CoE cannot show a refused payload and an unchanged system of record, you are scoring the wrong success metric.

A practical migration path

Treat migration as an inventory problem, not a branding problem.

1. Inventory bots. For each one: which screen, how often, how brittle, which service account, who gets the failure email, what the last three incidents were.
2. Mark API-available jobs. If the system now exposes an event, a file export, or a documented API, migrate those jobs to standing-order loops first. Stop paying selector tax on work that no longer needs a screen.
3. Pair fetch bots with loops. Where the screen remains the only door, shrink the bot to fetch-and-drop. The loop owns processing, skip, notify, and any draft write.
4. Keep one honest bot where the screen is the only door and the UI is stable. Review it quarterly with IT for an integration. Do not hide it. Name it in the architecture review.
5. Score new buys with how to evaluate loop engineering and your existing RPA ops metrics — hours lost to break-fix, mean time to repair a selector, percentage of “success” emails that were empty runs.

A sensible first quarter is not “zero bots.” It is “zero bots clicking a system that already had an API,” plus “every remaining bot has a named owner and a fetch-shaped job.” That is a programme a CFO can understand and an auditor can follow.

Department starting points for the loop side of the hybrid:

• Loops for finance and planning — scheduled packs, quiet skips
• Loops for revenue operations — stage-triggered hygiene
• Loops for legal and compliance — inbound redlines without click bots

Related reading: what is an enterprise AI operating system for the kernel metaphor, and loop engineering vs harness engineering when interactive agents need different stops than repeat recipes.

How this shows up in Nimbus

Nimbus Loops are standing orders on workstreams with governance — not a bot farm and not a recorder. They prefer events, files, and APIs; they record skipped runs; they notify a roster. When a legacy screen is still the only door, the honest pattern is the one above: let the incumbent RPA tool click, land the file in Conflux or a governed folder, and let the Loop compile what happens next.

That is one vendor’s implementation of the category split, not a requirement that every bot be replaced. If you are scoring platforms, keep Gartner’s UI-emulation definition for RPA and keep this page’s run-page tests for standing orders. Run both. The companies that get hurt are the ones that buy a single noun for both jobs.