Process Automation: RPA or an AI Agent?

What is the difference between RPA and an AI agent?

RPA (robotic process automation) repeats a fixed sequence of steps on screens and files exactly as it was built to, while an AI agent uses a language model to choose its next step from what it reads along the way. RPA behaves like a fast and very literal clerk: it opens the application, finds the field, copies the value and presses the button. Microsoft describes its Power Automate desktop flows as automation for "rule-based tasks" that can work with modern and legacy applications, including terminal emulators, by interacting with UI elements, images or screen coordinates. That is the core strength of RPA: it can automate a system that has no API without changing the system.

An AI agent works differently. It receives a goal, reads unstructured input such as an email, a scanned document or a free-text complaint, and decides which tool to call next: look up an order, read a contract clause, draft a reply. Anthropic's engineering guidance on building effective agents separates workflows, where models and tools follow predefined code paths, from agents, which direct their own process. The same guidance recommends finding the simplest solution that works and adding complexity only when it is needed, and it names the price of autonomy: higher cost and the potential for compounding errors.

Between the two sits the pattern most real projects end up with: a fixed workflow with one AI step. The process is still defined in code or in an RPA tool, but one step, such as classifying an email or reading fields from a PDF, is handled by a model. Name this middle option explicitly, because the question "RPA or AI?" is often really "RPA alone, or RPA with one AI step?"

Which processes are a good fit for RPA?

RPA fits processes whose inputs are structured, whose steps are the same every time and whose screens rarely change. Typical examples are copying approved records from one system to another, downloading statements from a bank or supplier portal every morning, and entering data into an old desktop application that has no integration interface. When a decision can be written as a rule ("if the amount is under the limit and the supplier is on the approved list, post it"), RPA applies that rule the same way every time and leaves a clear record of what it did.

The weak point is the screen itself. A robot finds a button or a field through stored attributes of the user interface. UiPath's documentation on selectors stresses that these attributes must have constant values: if a value changes each time the application starts, the selector can no longer identify the element, and applications with changing layouts need selectors built by hand. Running robots unattended adds conditions of its own. Microsoft's guide to unattended desktop flows notes that the machine needs all users signed out, that unattended runs require a specific licence plan, and that a different screen resolution in the remote session can make the robot miss an element or click the wrong one.

None of this makes RPA a poor choice. It means RPA is a sound choice for stable screens and an expensive one for screens that change often. One more question belongs at the start: does the target system already offer an API? If it does, a direct integration is usually sturdier than a robot that imitates a user.

Which processes need an AI agent?

An AI agent earns its place when the input is unstructured, the next step depends on what has just been found and several systems are involved. A customer writes, "The delivery arrived damaged and the invoice still has our old address." The right action depends on the order record, the shipment status and the invoice, and the order in which to check them is not fixed. Writing rules for every combination is impractical; a model that reads the message and decides which record to open next is not.

That flexibility brings new risks. OWASP lists excessive agency among the main risks of language model applications: tools with more functions than the task needs, permissions wider than necessary, and high-impact actions taken without human verification. Its recommended controls are narrow tools, minimum permissions and human approval before high-impact actions. The second risk is that an agent reads text written by outsiders. OWASP's entry on prompt injection describes how content inside a website or file can change a model's behaviour, and recommends separating and clearly marking untrusted content. An RPA robot that reads an email does not follow instructions written in it; an agent might, unless the design prevents it.

Decision matrix: which approach for which process type?

Start from the process, not the technology. The matrix below covers common process types. Read each row as a starting point to test against a sample of your own cases, not as a final answer.

Process type	Input	Exceptions	Suggested approach	Watch out for
Moving records between two systems with fixed fields	Structured	Rare, mostly technical	API integration if one exists; otherwise RPA	Screen changes stop the robot; ask for an API first
Scheduled downloads and reports from portals	Structured, fixed screens	Login changes, portal outages	RPA or a scheduled script	Credential storage, two-factor sign-in, portal redesigns
Data entry into a legacy application without an API	Structured	Validation errors in the target system	RPA	Upgrades of the legacy application
Invoices and forms arriving as PDFs in many layouts	Semi-structured	Missing fields, poor scans	Workflow with an AI extraction step, rule checks, then RPA or API for posting	Low-confidence fields must go to a person
Sorting incoming emails and requests	Unstructured text	Mixed or unclear requests	Workflow with AI classification and fixed routing rules	Instructions hidden in emails; overlapping categories
Investigating a case across several systems	Unstructured, several records	Frequent; each case differs	Bounded AI agent with read-only tools; a person decides	Loops, cost per case, opening the wrong record
Actions involving money, deletions or customer messages	Any	Costly when wrong	Fixed workflow with mandatory human approval; an agent may only propose	Approval enforced on the server, not in the prompt
Judgements with legal or regulatory effect	Unstructured	High	AI prepares a draft with sources; a professional decides	Accountability stays with the person

Two questions settle most rows. First, can the input be read without understanding language? If yes, RPA or an integration is usually enough. Second, can the steps be listed in advance? If yes, keep them in a fixed workflow even when one step needs a model. An agent is the answer only when both answers are no, and even then it should usually propose actions rather than carry them out.

How do exceptions change the decision?

Exceptions decide whether an automation pays off, so measure them before you choose. UiPath's orchestration documentation separates two kinds. An application exception is a technical problem, such as an application that stops responding; a business exception means the data the process depends on is incomplete or missing. By default the queue does not retry business exceptions, because trying again does not fix bad data.

The distinction is useful whatever tool you choose. Application exceptions are an engineering problem: retries, monitoring, a more stable interface. Business exceptions are a process problem: someone has to look at the case. If a process produces many business exceptions, RPA alone hands most of them back to people and the savings shrink. This is where AI helps, not by replacing the robot but by absorbing part of the variation: reading a supplier's free-text note, matching an invoice line to the right purchase order, and sending only the cases it is unsure about to a person.

Before deciding, take a sample of real cases from recent weeks and sort them into three groups: cases that follow the rule, cases that fail for technical reasons and cases that need judgement. The size of the third group tells you more about the right approach than any product demonstration.

What does maintenance look like for each?

Both approaches need an owner after go-live; they simply break in different places.

Area	RPA	AI agent
What usually breaks	Screen layout, field names, sign-in flow, screen resolution	Model version, prompts, new kinds of input, changes in tool interfaces
How you notice	The robot stops with an element-not-found error	Quality drifts quietly; answers look plausible but are wrong
What you need	Selector maintenance and test runs after each release of the target system	An evaluation set of real cases, re-run after every change
What to log	Each step, the input record, the outcome	Each tool call with inputs and outputs, the model version, the approver
Who owns it	Process owner and automation team	Process owner and AI engineering team

The asymmetry matters. When RPA fails, it usually fails loudly and stops. When a model's behaviour shifts, the process can keep running with worse results. An agent project without an evaluation set and step-by-step logs is not ready for production, however convincing the demonstration was.

What drives the cost of RPA and of an AI agent?

Neither approach has a single price; each has cost drivers you can list before asking for a quote.

• RPA platform licences: Often priced per robot, per unattended runtime or per user. Unattended automation may need its own plan, as it does with Microsoft.
• RPA machines: The physical or virtual machines and user sessions the robots run on.
• RPA development: Effort per process, driven by the number of screens, systems and branches.
• RPA maintenance: Work after every change in the target applications.
• Exception handling: The people who work the exception queue, for both approaches.
• Model usage: Token cost per task with a hosted model, or the hardware if the model runs on your own servers.
• Tools and integrations: The connections an agent uses, including their permissions.
• Evaluation: Building and maintaining a test set of real cases.
• Human review: Time spent checking proposals and approving actions.
• Logging, monitoring and security review: Needed for both, heavier for agents.

When comparing quotes, ask each vendor to state how many processes, systems and exception paths they priced, which licence model they assumed and who maintains the automation after go-live. Two quotes that look far apart may simply describe different scopes.

How do you combine RPA and AI in one process?

Combining the two is often the practical answer: let AI read and classify where language is involved, and let RPA or an integration act where the steps are fixed. Platform vendors are moving the same way; Microsoft's AI Builder, for example, adds prebuilt and custom AI models to Power Automate flows and gives document processing as one of its examples. Four patterns cover most designs:

• AI reads, the robot types: A model extracts fields from a document, rules validate them, and the robot or an API enters them into the target system.
• The robot collects, AI sorts: The robot downloads attachments or tickets on a schedule, a model classifies them, and fixed rules route each class.
• AI works the exception queue: The robot processes standard cases; cases it cannot handle go to a model that prepares a summary and a suggested resolution for a person.
• The robot as an agent's tool: An agent may trigger a specific, narrowly scoped robot ("download the statement for this account"), never a general one that can do anything on the screen.

Whatever the pattern, put a validation step between the AI output and the robot's action. An extracted amount should be checked against the purchase order before a robot posts it, and actions with financial or customer impact should wait for human approval.

Hypothetical example: supplier invoices

This is a hypothetical example; the figures are illustrative, not measurements. Suppose a company receives 1,000 supplier invoices a month. 600 arrive as structured e-invoices, 300 arrive as PDFs in a dozen layouts, and 100 have problems: a missing purchase order number, a price that differs from the order, or an unregistered supplier. Today an accounts team enters all of them by hand into an ERP that has no interface for posting invoices.

1. Structured e-invoices (600): No AI is needed. Read the structured data, match it to the purchase order with rules and let the robot post it. Anything that fails a rule goes to the exception queue.
2. PDF invoices (300): A model extracts supplier, date, lines and totals; rules check the totals and compare them with the order. Suppose 30 have a low-confidence field. Those go to a person with the field highlighted, and the robot posts the other 270.
3. Problem invoices (100): These need judgement. An agent with read-only access gathers the order, the delivery note and earlier correspondence with the supplier, then drafts a summary with a suggested action. A person decides and approves.

Under these assumptions, people handle 130 invoices instead of 1,000, and the 100 hardest cases arrive with the evidence already collected. The example also shows what to avoid. Sending all 1,000 through an agent would add model cost and new failure modes to 600 invoices that rules already handle; RPA alone would leave the 300 PDFs and the 100 problem cases manual. Run the same sort on your own sample before trusting any version of these numbers.

Questions to ask before choosing a vendor or a tool

1. Which steps will be automated, and which will stay with people?
2. How many of the sampled cases did the proposal assume are standard, and how was that measured?
3. What happens when a target screen or form changes, and who fixes it?
4. Where is AI output validated before any system is changed?
5. Which actions need human approval, and is that approval enforced on the server?
6. What is logged for each case, and can we trace a single case from start to finish?
7. Which licences, machines and model usage did the quote assume?
8. How will success be measured after go-live, and against which baseline?

Common mistakes

• Automating a broken process instead of fixing it first.
• Choosing RPA for screens that change every few weeks, then paying for constant repairs.
• Choosing an agent for a process with fixed steps, and paying for flexibility nobody needs.
• Leaving the exception queue out of the savings calculation.
• Letting a model's output change a system without validation or approval.
• Building a robot on top of an application that already offers an API.

How Hatson Tech approaches this

In our AI agent development work, the first question is whether the job needs an agent at all. When a fixed workflow with one AI step is enough, or when an existing automation only needs an AI step in front of it, that is what we recommend. We go deeper into the agent-or-workflow decision in AI agent or fixed workflow? and into approval design in human approval before agent actions. If you have a process in mind, bring a sample of real cases to a first meeting. It is free, and sorting those cases together is usually a quick way to see which approach fits.