RPA follows rules on a screen. Agents make their own plan. Most of your work wants rules on an API.
RPA drives a user interface by fixed rules; it is cheap per run and breaks when the screen changes. An AI agent is a model that decides its own steps; it handles the unpredictable and costs more per run. Most small-business processes want a third thing — plain rules against a proper API — and that is where we start.
Most small businesses need neither, and we build both
The honest first line: the process you are thinking about probably does not need a robot clicking through screens or a model deciding what to do. It needs a rule — when this happens, do that — running against the system’s API. That is cheaper, more reliable and easier to explain than either thing in the title, and it is what most of what we build is.
RPA and AI agents both exist for the cases where that is not possible. RPA exists because some systems have no API, so the only way in is the same screen a person uses. Agents exist because some work cannot be reduced to rules in advance. Both are real. Both are also sold hard to businesses whose actual problem is a re-keying step between two systems that both have perfectly good APIs.
So this page defines each from a published source, prices what is priced in AUD, and then says where each one genuinely belongs. If you leave it thinking you need neither, it has done its job.
Definitions from people who sell each one
RPA, from its largest vendor: “software robots handle repetitive, rule-based tasks like entering data, moving files, or processing transactions — quickly and accurately”, working by “mimicking human actions” on digital systems (UiPath, fetched 3 September 2026). The same page is candid that unstructured and semi-structured work needs AI augmentation, “not RPA alone”.
Agents, from a company that builds the models: “Workflows are systems where LLMs and tools are orchestrated through predefined code paths”, whereas “Agents … are systems where LLMs dynamically direct their own processes”. The advice attached is to “find the simplest solution possible, and only increasing complexity when needed”, because agentic systems “trade latency and cost for better task performance” (Anthropic, Building effective agents, 19 December 2024).
Put those together and you have the comparison. RPA is rules applied to a screen. An agent is judgement applied to a goal. The thing in between — rules applied to an API — is what Anthropic calls a workflow, and it is where the simplest-solution advice usually lands.
The three options side by side
We have added a third column because comparing only the two in the title would be a page written to sell one of them. The third column is what we reach for first, and it is deliberately the least exciting.
| RPA (screen robot) | AI agent | Rules on an API | |
|---|---|---|---|
| How it decides | Yes Fixed rules you wrote. Same input, same output, every time. | Partly The model plans its own steps. Same input can produce a different path. | Yes Fixed rules you wrote. Same input, same output, every time. |
| What it touches | No The user interface. Buttons, fields, screen positions. | Partly Whatever tools it is given — APIs, documents, sometimes a browser. | Yes The system’s published API. Documented fields, documented errors. |
| Breaks when | No The vendor moves a button. UiPath’s own page frames UI stability as the constraint. | Partly The task is ambiguous and the model guesses wrong. Needs a human checkpoint. | Partly The vendor changes the API, which is versioned and announced. Rare and visible. |
| Cost per run | Partly A licensed bot. Power Automate Process is AU$224.50 a bot a month ex GST, paid yearly. | No Model calls, and often several per task. Rises with volume and with how much it has to think. | Yes Near nil once built. A few API calls, most systems allow thousands a day. |
| Explainable after the fact | Yes The rule fired or it did not. A log line says which. | Partly You can log what it did. Why it chose that path is a model output, not a rule. | Yes The rule fired or it did not. A log line says which. |
| Fits a system with no API | Yes This is the case RPA exists for. | Partly A browsing agent can, slowly and expensively. Not our first choice. | No Cannot. Tradify, for example, publishes no API at all. |
| Where we start | Partly Only when there is no API and the screen is stable. Rare. | Partly Only for the step that genuinely needs judgement, with a human able to intervene. | Yes Always, if the system has one. Nine systems in our register do. |
What RPA costs in Australian dollars, and why the price is the point
Microsoft publishes Australian prices for the RPA product most small businesses would actually encounter. Power Automate Premium is AU$22.40 per user a month and includes attended desktop flows, 50 MB of process mining storage and a 250 MB Dataverse database; Power Automate Process — an unattended bot — is AU$224.50 per bot a month with a 50 MB database and 200 MB of file storage; Hosted Process, with a Microsoft-hosted virtual machine, is AU$321.80 per bot a month. All three are “paid yearly” and the page states prices “do not include GST” (Microsoft, fetched 3 September 2026).
UiPath publishes one figure — Automation Cloud Basic at US$25 a month for “basic personal automations” with “limited scale” and “99.9% service uptime” — and “Contact Sales” for its Standard and Enterprise tiers, which are where unattended robots and agents live (UiPath pricing, fetched 3 September 2026).
The point is not that AU$224.50 a month is expensive. It is that you would be paying it, every month, to have a robot click through a screen that the vendor can rearrange at any time, for a job that — if the system has an API — a rule could do for the cost of the hosting. That is why RPA is the last thing we reach for and not the first. It is a legitimate answer to “this system has no API”. It is a poor answer to “nobody checked whether it did”.
What an agent costs, and what you are buying with it
Nobody publishes a per-task price for an agent because there is not one. An agent makes model calls, usually several per task, and the number depends on how hard the task turned out to be. That is the trade Anthropic describes plainly: agents “trade latency and cost for better task performance” and suit “open-ended problems where it’s difficult or impossible to predict the required number of steps” (Anthropic, 19 December 2024).
For a small business that is a specific kind of purchase. You are buying the ability to handle the case you could not write a rule for — the email that does not fit a template, the document that is not the usual layout, the enquiry that needs a judgement before it can be routed. You are paying for it with a per-run cost that rises with difficulty and an output you cannot fully predict.
That is worth paying for the one step in a process that genuinely needs judgement. It is a waste on the other nine steps, which should be rules. The pattern that works is a workflow of rules with one agent step inside it and a human able to see what that step did — which is what inbox triage looks like when built properly.
The guardrails you would be signing up to
Australia has a published standard for this. The Voluntary AI Safety Standard, released 5 September 2024, sets out ten guardrails for organisations deploying AI (Department of Industry, Science and Resources). Four of them describe exactly the overhead an agent carries that a rule does not.
- KNDR·01Guardrail 4 — test and monitor“Test AI models and systems to evaluate model performance and monitor the system once deployed.” A rule is tested once. An agent is monitored forever, because its behaviour is not fixed.
- KNDR·02Guardrail 5 — human oversight“Enable human control or intervention in an AI system to achieve meaningful human oversight across the life cycle.” This is the human checkpoint in the matrix above. It is not optional and it is a cost.
- KNDR·03Guardrail 6 — tell people“Inform end-users regarding AI-enabled decisions, interactions with AI and AI-generated content.” If an agent drafts the reply to your customer, the standard expects the customer to know.
- KNDR·04Guardrail 9 — keep records“Keep and maintain records to allow third parties to assess compliance with guardrails.” Logging what an agent did, and why, becomes a deliverable rather than a nice-to-have.
Rules before agents: the order we work in
First, find the API. Nine systems in our capability register have one we have built against, and most small-business software does. If the API exists, the process becomes rules, and rules are cheap, testable and boring in the best sense.
Second, if a step genuinely cannot be a rule — it needs reading, classifying or judging — put an agent on that step and only that step, with a human able to see and override what it did. Guardrails 4, 5, 6 and 9 above are the price of admission, and they are why we do not put agents where rules would do.
Third, if a system has no API and the screen is stable, RPA is the honest fallback, priced at the Microsoft figures above. We have not run RPA tooling in production and would tell you that before quoting it. The ownership questions are the same for all three — who holds the code and where it runs — and they matter more for an agent than for anything else on this page, because an agent you cannot inspect is an agent you cannot govern.
What we have not assessed
RPA tooling in production. We have not run UiPath or Power Automate desktop flows for a client. The RPA column is UiPath’s and Microsoft’s own descriptions and prices, fetched and linked, plus the structural fact that a screen robot depends on the screen.
Agent error rates. We have not published a measured failure rate for any agent step we have built, and you should be suspicious of anyone who quotes one without saying how and when they measured it. The honest position is that an agent step needs a human checkpoint precisely because that number is not known in advance for your data.
Whether your process needs any of this. That is a twenty-minute conversation, not a web page, and the most common outcome of it is a rule, not a robot or an agent. What not to automate is the list of processes that should not get any of the three.
The questions people actually ask.
01Everyone is selling AI agents. Are you saying they do not work?
No. They work well on the step that needs judgement and badly as a replacement for rules that could have been written. The vendors who build the models say the same: start with the simplest thing and add complexity only when needed. We build agent steps. We build them small, inside rule-based workflows, with a human able to see what they did.
02Our main system has no API. Is RPA the answer?
It might be, and it is the case RPA exists for. Before you commit, check three things: whether the vendor has an API you were not told about, whether an export or import file would do the job on a schedule, and how often the vendor changes its screens. If the screen is stable and there is truly no other way in, price it at the Microsoft figures above and go in knowing the risk.
03What does an agent cost to run for a small business?
Nobody can tell you in advance, including us, because the cost is model calls and the number of calls depends on the task. What we can do is build the one step that needs it, log every call, and show you the running cost after a fortnight of real work. That is a better number than any estimate, and it is why we quote in two-week increments rather than up front.
Stop bending.
Start shipping.
Bring the one flow that keeps costing you a Tuesday afternoon. We map it live and tell you what we'd build, what we wouldn't, and what it costs.