These three are usually presented as competing answers to the same question, which is why so many automation budgets get spent on the wrong one. They are not competitors. They solve different problems, and the two that are not agents are cheaper to build, cheaper to run and easier to verify. Choosing between them is not a technology preference — it is a description of the process you are trying to automate.

Here is the difference in one line each, the question that decides it, and where each one genuinely wins.

The difference in one line each

Workflow automation
Runs a defined sequence of steps with defined branches. You specify the route; it follows the route. Deterministic, inspectable, and the same input always produces the same output.
RPA
Drives an existing user interface the way a person would — clicking buttons, filling fields, reading screens. It exists to solve one specific problem: a system with no usable way in.
AI agents
Given an objective rather than a route, with tools to pursue it and the ability to decide when it is finished. Handles variation a flowchart cannot express, at the cost of being non-deterministic.

The question that decides it

Can you draw the whole process as a flowchart, and is the flowchart correct every time?

That is the entire test, and it is worth taking literally — draw it. Most of the value in this exercise comes from discovering that you cannot, and specifically from discovering where you cannot.

  1. Yes, and every system involved has an API — you want workflow automation. Do not add a model to this. You would be paying for latency and variability to solve a problem that had neither.
  2. Yes, but one system can only be reached through its interface — you want workflow automation with RPA doing the one step that has no other route in.
  3. No, because the correct handling depends on reading and interpreting the input — you want an agent, and specifically an agent for the interpreting step, with the deterministic parts staying deterministic.
  4. No, because nobody agrees what the correct handling is — you do not have an automation problem yet. You have a policy question wearing an automation costume.

Where workflow automation wins

Anywhere the rules are settled. Invoice routing where the supplier determines the approver. Onboarding sequences. Data moving between systems on a schedule or a trigger. Notifications with conditions.

The advantages are not small. It is testable in the ordinary way, because the same input always produces the same output. It fails loudly rather than plausibly. Its running cost is close to nothing. And a year later, somebody can read it and know what it does — which is not reliably true of the alternative.

Where RPA wins

One case, narrowly: a system you must use and cannot reach any other way. Legacy line-of-business software, a supplier portal with no API, an internal tool nobody maintains any more. RPA is the workaround for an access problem, and as a workaround it is genuinely valuable.

It should be treated as a liability with a purpose, though. RPA depends on the interface staying where it is, so a vendor redesign breaks it — and it breaks by clicking the wrong thing rather than by stopping, which is the worse of the two failure modes. Keep the RPA step as small as possible and everything around it on a real integration.

Where agents win

Where the input varies in ways a flowchart cannot enumerate, and the judgement required is real but shallow. Reading an email and working out what it is actually asking for. Extracting fields from documents that arrive in forty formats. Summarising a case file. Deciding which of nine queues a request belongs in when the request does not say.

The pattern that works in practice is an agent doing the interpreting and nothing else. Once the email has been classified and the fields extracted, everything downstream is deterministic and should be built deterministically. A great many production systems described as agents are correctly described as a workflow with an agent handling one step, and that is a compliment.

How they differ once they are running

The build is the part buyers compare. The differences that matter more show up afterwards.

Testing
Workflow automation and RPA can be tested exhaustively: enumerate the branches, assert the outputs. An agent cannot, because the same input may legitimately produce two different routes. It needs a set of real cases with known correct handling instead — a different discipline, and one that has to be maintained.
How it fails
A workflow step throws an error. RPA clicks the wrong thing. An agent produces something plausible, specific and wrong, in the same tone as the correct answers. The third is the most expensive failure mode there is, because a visibly broken system gets reported and a confidently wrong one gets believed.
Running cost
Workflow automation is close to free per execution. RPA costs a licence and a machine. An agent costs model usage per task, which makes volume a design consideration rather than an afterthought.
Maintenance
All three drift when the process changes. Only the agent can drift while appearing to work — handling a slightly wrong version of the job, a little more wrongly each month, with nothing in a log to show it.

That last row is the one to weigh at the buying stage, because it is a permanent commitment rather than a project cost. An agent that is actively reviewed improves. An agent that is shipped and left alone decays quietly, and the decay is not visible in any metric you are likely to be watching. Who owns that review is also the question that settles whether to build the thing or buy it.

They combine far more often than they compete

The realistic answer for most processes is more than one of the three. A document arrives; an agent reads it and extracts the fields; a deterministic workflow validates them, routes for approval and files the result; one step in the middle uses RPA because the system of record has no API. Each tool is doing the job it is best at, and the expensive, unpredictable component is confined to the step that actually needed judgement.

Working out which step is which requires looking at the real process rather than the described one, which is why this decision is usually made properly only after somebody has watched the work happen. If you are still deciding what to automate at all, the earlier question is which workflow to start with — and it is worth answering first.

Use the least clever tool that solves the problem. The clever one is harder to test, and it will be asked to explain itself eventually.