RPA, Workflow Automation and AI Agents: What Each Term Means

Three words that quotes treat as three price levels of one service are three different mechanisms. How each differs, what the buyer actually receives, and why the difference is now a legal question as well.

Three words tend to appear in one quote as if they were three price levels of one and the same service: robotic process automation (RPA), workflow automation and AI agents. That gives the buyer the impression that they have to choose one of three products, and the dearest is usually chosen, because it sounds more modern.

In fact they are three different mechanisms, which solve different problems, and most real tasks need precisely the one that costs least. This article does not compare tools and does not recommend a platform; it explains how each mechanism differs technically, what the buyer receives in each case, and why this very difference has in the last two years become a legal question as well.

Three mechanisms that answer three different questions

The simplest way to keep them apart is to ask how each one knows what it is supposed to do. Robotic process automation repeats the actions a person showed it; workflow automation follows a path someone drew; an AI agent infers the path itself from a goal it was given. Almost everything else follows from that one difference, including the price, the fragility, and what happens when the situation is unexpected. The mechanism that repeats stops in an unexpected situation; the mechanism that follows a drawn path takes the error branch, if one was provided; the mechanism that infers invents something new, and that is exactly why it needs supervision the other two do not.

It is worth trying this on one concrete task, which looks the same in almost every company: an invoice that has arrived by email has to be put into the accounting system. Robotic process automation would do this work by opening the email program, downloading the attachment, opening the accounting window and filling in the fields in exactly the order an employee would. A workflow would do it by receiving the document through an interface and calling the accounting system’s interface with the fields already prepared, without opening a single window. An agent would do it by receiving the task “book this invoice” and deciding for itself which tools to call and what to do if something is missing.

All three variants can complete this task, and that is precisely what misleads. The difference appears not when everything is in order, but when the supplier changes the invoice form, when a new mandatory field appears in the system, or when one and the same product has been named in two ways, and it is precisely those cases that make up most of the real work.

Robotic process automation repeats actions on screen

Robotic process automation, known in everyday use as RPA, is a software robot that works in exactly the same interfaces a person works in: it opens a window, clicks, copies a field, presses save. The systems it works with remain completely unchanged, and that is both its main advantage and its main weakness. The advantage is that RPA copes with programs that have no interface for exchanging data and that nobody is going to rebuild, so it is often the only path into old accounting or industry systems. The weakness is that the robot sees the screen, not the data, so any change on the screen — a moved button, a new field, a different version after an update — stops the work, and maintenance becomes a standing cost, not a one-off.

The buyer here receives a licence for the robot, its runtime environment and a management tool, a description of the process and a log of the actions taken. It is worth knowing that in the industry itself this name is regarded as an unfortunate one: what RPA usually automates is a separate task, not a whole process, and it is precisely this mismatch between the name and the content that creates some of the buyer expectations that later go unfulfilled.

Another feature that tends to surprise in RPA projects is that the robot works at the same access level as the person whose actions it repeats. That means the robot needs its own user in each system, that this user’s rights have to be thought through just as they would for anyone else, and that the robot’s actions look like a person’s actions in the system log, unless it has a separate account. In companies where this has not been thought about, it is later hard to answer a simple question about who made a particular record.

Workflow automation connects systems, not screens

Workflow automation works one layer deeper: it does not talk to the screen, but to the systems themselves, through their application programming interfaces. A workflow is a graph of steps drawn in advance — an event starts a chain, the chain calls actions in other systems, and between them there can also be a step in which a person confirms something. Because the data is exchanged through an interface, not through an image, changes to how the system looks do not affect this mechanism, and that is the main reason why, wherever an interface is available, it is almost always the more robust and cheaper-to-maintain choice than repeating the screen. The drawback is obvious: if the system has no interface, or it is not available at your licence level, this path simply does not exist.

The buyer here receives the workflow itself, the credentials, an execution log and an error branch, and it is the last of these that a quote is worth judging by, because a workflow without error handling only works for as long as everything is fine.

A word that is useful here and worth using precisely is software robot: it is a program that imitates a person’s actions in an interface, and it is not a physical robot. The distinction still matters, because in everyday speech “robot” means a machine, and it is from that misunderstanding that some of the questions come about what the robot “sees” and what it “understands”. It understands nothing: it repeats what it was shown.

An AI agent infers the path itself

An agent differs from both of the previous two in that it is not given a path, but a goal, and it chooses the path itself, calling tools that are available to it — search, a database, a system interface, another model. It is precisely acting with tools that is the feature which distinguishes an agent from a chatbot: a chatbot answers, an agent acts. From that it follows that an agent copes with tasks in which the order of steps is not known in advance, and at the same time it is the only one of the three mechanisms whose result is not fully predictable. Two identical runs can choose different paths, and that means both supervision and clearly set bounds are needed: on what the agent may do itself, and on where it has to stop and ask a person.

In practical work that tends to mean the agent is the right mechanism where the input is unstructured and varied, but the wrong one where the task is tightly specified and repeats hundreds of times a day. In the second case a workflow is both cheaper and safer, and using an agent there is spending money on unpredictability nobody needed.

In the agent’s case the buyer receives something different from the other two cases, and in quotes this is often not described at all. Besides the agent itself, the tools it may call are needed, bounds on what it may do without confirmation, a log of what it did on each run, and a way of stopping it. A quote that contains only a model and a prompt describes a demonstration, not a working tool.

There is also a cost difference that project plans tend to leave out. Running a workflow costs almost nothing, because it is a couple of calls, and RPA costs are mainly the licence and the maintenance. Each run of an agent, by contrast, is billed for the use of the model, and that cost grows with volume, so the mechanism that seemed cheap in a trial can, at hundreds of runs a day, turn out to be the dearest of the three.

Where automation ends and artificial intelligence begins

This boundary has in recent years become a legal question, because the duties that do exist attach to what the system actually does, not to the product name on the quote. The OECD definition of an AI system describes it as a machine-based system that infers, from the input it receives, how to generate an output such as a prediction, content, a recommendation or a decision. Just as important is what stays outside. A system that only follows rules defined by people, in order to execute operations automatically, does not infer a path; it executes one that was already written, and that is the characteristic the definition turns on.

The same line is the one that decides, in practice, whether a quote is selling automation or selling artificial intelligence. Robotic process automation and business-rules engines that execute predetermined steps, without inferring a new path, sit on the automation side of it. That is a reading of the definition, not a United Kingdom Act, but it is the clearest available formulation of the difference. The practical consequence is direct: an RPA robot that copies data between two windows, and a workflow that calls an interface along a drawn path, do not become artificial intelligence merely by being automated. An agent that infers can, and that is why mixing the names in a quote is not only a matter of style.

What the buyer actually receives in each case

Quotes are easier to compare if you look not at the name, but at what remains in the company when the work is finished. In the case of robotic process automation there remains a licence, a runtime environment, a management tool, a description of the process and a log of the actions taken, and of all of that the most important is the process description, because it is the process description that says what the robot does when something does not match what was expected.

In the case of a workflow there remains the workflow itself, credentials to each connected system, an execution log and an error branch, and here it is worth paying attention to who owns the credentials and where the workflow runs. If it runs in the supplier’s account with the supplier’s keys, then a break in the relationship also means a break in the work, and that is easier to put in order at the moment the contract is signed than later.

In the case of an agent, on top of everything previous, there also remains responsibility for what it did, and that is why the log there is not a technical detail, but the substance. If you cannot say why the agent acted as it acted in a particular case, then you also cannot answer a customer who asks why their application was handled in exactly this way.

Which deadlines have already started

Because the duties that do apply arrived in stages, it is worth knowing what is already in force today and what is not. The duty not to mislead a person into thinking they are talking to a human, when they are talking to an AI agent or a chatbot, is already in force under consumer law, and the Competition and Markets Authority’s guidance of March 2026 names it expressly: if you use an AI agent and the fact they are dealing with AI rather than a person might affect people’s decisions, you should tell them. If a customer-visible AI agent or chatbot is on your website, that is a question to settle now, not later.

There is no United Kingdom statute that imposes high-risk AI-system duties on recruitment and employment decisions from a set future date. What is coming in 2027 is the Information Commissioner’s statutory code of practice on artificial intelligence and automated decision-making, and some articles still treat that code as if it were already in force, or still describe the old Article 22 prohibition as if it had not been replaced.

Independently of any AI-specific instrument, the data-protection requirement remains in force for decisions based solely on automated processing that produce legal effects or similarly significantly affect a person. Articles 22A to 22D of the UK GDPR, which have applied since 5 February 2026, do not depend on whether the mechanism is an agent or a simple workflow: what matters is whether a machine alone takes the decision about a person.

It is also worth understanding why this boundary has been drawn through inference, not through complexity. A program can be very complex and still not be an artificial intelligence system, if every one of its steps was set by a person, and conversely — quite a small solution that uses a model to decide what to do next meets the definition. That means the answer to the question about duties is given neither by the project budget nor by the number of lines, but only by how the decision about the next action is taken.

In practice these deadlines most often attach to one concrete thing that many companies already have: a chatbot or an assistant on the website. If it is visible to the customer and is based on a language model, then the duty to say that they are not talking to a person is already in force, and in practice it is discharged with a clear label in the interface, not with a paragraph in the privacy policy. If it is a simple tree of rules with answers written in advance, then it is not an artificial intelligence system and this particular duty does not arise, but the difference is worth recording in writing, because a year later nobody will remember how it was built.

Why the names get mixed up in the market

The confusion also has a completely objective reason, and it is not only marketing. Tools that used to do one thing now do several: platforms that started as workflow tools now also offer an agent step, and companies that sold robotic process automation now describe those same products as ones that act on their own.

That means you can no longer tell the mechanism from the product name, and the only safe question to put to a quote is how, in this particular solution, the path of actions is determined: whether a person writes it, whether it is drawn as a graph, or whether a model chooses it on each run. The answer to this one question tells you the price, the fragility, and whether duties can arise at all.

There are also words that need care. The abbreviation RPA should never stand in a text on its own, without the full form on first mention. The form sometimes seen, robotics process automation, is an error: robotics is physical robots, and here the subject is software.

The other place where names get mixed up is the use of the word “automation” itself. In English it covers both industrial process control and the automation of office work, and those are two entirely different markets with different suppliers. If you are looking for a quote, it is worth saying which of the two you mean, because otherwise some of the quotes you receive will be from a completely different industry.

Three claims that are wrong in quotes

The first is that robotic process automation is artificial intelligence. That is not only a terminology question, because duties follow from it: a system that executes steps a person wrote does not meet the definition of an artificial intelligence system, and a quote that calls the robot artificial intelligence is either selling more dearly than it needs to, or creating concerns that are not well founded. The second is that an agent is simply a smarter chatbot. The difference is not in cleverness, but in action: a chatbot generates an answer, an agent calls tools and changes state in other systems, and that is precisely why an agent needs bounds that a chatbot does not. A company that does not separate the two tends to give the agent access that nobody has thought through.

The third is that the choice among these three is a choice among three suppliers. In fact one and the same tool can often do all three: platforms that started as workflow tools now also offer an agent step, and that means the question is not what to buy, but how, in this particular solution, the path of actions is determined.

How to choose a mechanism for a particular job

The choice in practice is short if the questions are asked in the right order. First find out whether the systems involved have an application programming interface, because if they do, a workflow will almost always be more robust and cheaper to maintain than repeating the screen, and from there the question is no longer about the mechanism, but about scale. If there is no interface and the system cannot be changed, then robotic process automation is the right tool, but with open eyes: the budget has to have room for maintenance, and the project has to have someone responsible who will repair the robot when the screen changes. If the input is unstructured, each case differs and the order of steps cannot be written in advance, only then is it worth looking towards an agent, and even then you need to know where it stops and who supervises it.

The most common practical solution is mixed: a workflow runs the chain and carries out all the expected steps, but at one particular place it calls a model to handle unstructured input, and returns the result to the chain. That combines predictability with flexibility exactly where it is needed, and it is also the cheapest of the variants that work at all.

There is one more practical consideration that tends to decide the choice more than the technique. Each of the three mechanisms needs a different maintainer: a workflow can be maintained by a person who understands the systems’ interfaces, a robot needs someone who knows the particular tool and the screens it works with, and an agent additionally needs someone who regularly looks at what it is actually doing. If the company has no such person and is not planning to buy maintenance, then the choice among mechanisms has to start with which of them can actually be maintained.

It is also worth naming the error that in this choice costs the most, and it is not the choice of mechanism, but the sequence. Companies tend first to choose a tool, then look for something to automate with it, and only then understand that the process they wanted to automate has not yet been described. The right sequence is the opposite: first describe the work with its exceptions, then find out whether the systems have interfaces, and only then choose the mechanism, because at that point the choice is usually obvious and takes five minutes. Just as common is the opposite extreme, in which the company waits until everything is in order, and starts nothing. Here it helps to remember that a workflow can also be built for one small stretch and expanded later, and that it is precisely the first finished stretch that usually shows where the bottleneck actually is, much more precisely than any prior assessment.

It is also worth saying that changing the mechanism later is not a catastrophe if the process itself has been described. Companies tend to fear a wrong choice as if it were irreversible, but in practice the greatest value in the project is precisely the process description with its exceptions, and that remains valid regardless of whether it is executed by a robot, a workflow or an agent. Changing the executor once the description is already in order is much cheaper than writing the description again from scratch.

What to ask the supplier

If a quote is already on the table, then four questions are usually enough to understand what it is actually offering, regardless of the words in the heading. The first is about who decides the next step: a written script, a drawn graph, or a model at the moment of execution. It is precisely this answer that names the mechanism more accurately than any product name in the heading.

The second is what happens when something does not match what was expected, and here it is worth asking for a concrete example, not a general claim about reliability. The third is who owns the credentials and where the solution runs, because on that depends whether the work continues if the relationship with the supplier ends. The fourth is how much maintenance costs a year and what exactly is received for it, because it is precisely maintenance that is the cost most often not stated in quotes at all.

If the answer to one of these questions is unclear, that does not yet mean the quote is a bad one, but that this part has not yet been thought about, and agreeing it is much cheaper before the contract than after the first stop.

The opposite list is also useful, namely questions that decide nothing, even though they are asked often. The size of the companies the supplier has served, how many years it has been in the market and how many processes it has automated, tell you about experience, but tell you nothing about whether the particular mechanism fits the particular task. Equally little use is the question of which platform the supplier uses, because one and the same platform can today operate in all three mechanisms, and the answer to that question tells you nothing about the solution’s fragility or the cost of maintenance.

Finally it is worth asking the supplier to show one example that is already working and to say what has broken in it since it was installed and why. The answer to this question tells you more about the quality of the supplier’s work than any list of testimonials, because everything that has been running long enough has broken, and what matters is how quickly it was noticed and repaired.

It is also honest to state our own position, because it explains why this article is written in exactly this way. We do not sell robotic process automation licences and we are not a partner of any such platform, so we have no interest in your choosing the dearest mechanism.

Our work is business process automation with workflows and interfaces between the systems you already have, including the mixed variant in which a workflow runs the chain and a model is called only at one unstructured step, and separately AI solutions where the task really does require inference. If you currently have a quote in which these words are mixed, or it is simply not clear which mechanism fits your task, send us a description: often the answer is that one connection is enough, and that is the cheapest answer you can receive.