Before choosing between an AI agent and RPA, look at each step of the process and ask: does this need interpretation, or just repetition? Repetition over structured data is a job for an RPA bot or an integration. Interpreting free text, exceptions and ambiguity is where a language model pays for itself. Most real processes have both, and the expensive mistake is picking one tool for the whole process.
Why this confusion costs money now
In June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027 due to rising costs, unclear business value or inadequate risk controls. In the same release it described "agent washing": vendors rebranding assistants, chatbots and RPA as agents without real agentic capabilities. By Gartner's estimate, only about 130 of the thousands of vendors claiming agentic AI are real.
Both mistakes show up in projects. Some companies buy an "agent" and get an RPA bot with a chat layer on top. Others put an autonomous agent on a task that a three-line rule would handle better, cheaper and with no surprises.
What each one is, without the marketing
RPA (robotic process automation) runs a fixed script over user interfaces: open the system, read the field, copy, paste, click. It is deterministic. The same input always produces the same output, which is a virtue when the process is stable.
An AI agent, in the definition Anthropic uses in Building effective agents, is a system in which the language model directs its own process and decides which tools to use and in what order. The same piece separates agents from workflows: systems in which the LLM is called at defined points in a flow written in code. And it makes a recommendation many people skip: start with the simplest solution, because agents trade latency and cost for performance on open-ended tasks, and autonomy brings higher costs and the risk of compounding errors.
That third category, a workflow with an LLM step, is the right answer more often than the market admits.
Where RPA wins, and where it breaks
RPA wins when the process has clear rules, structured data, high volume and systems without APIs. Reconciliations between two legacy systems, repetitive data entry into government portals, daily report downloads. Low cost per run, predictable behavior, simple auditing.
RPA breaks when the screen changes, when a document arrives in a different format, or when the "almost the same" case shows up. Every exception becomes a new rule, every new rule becomes maintenance, and the bot that was supposed to free people up now needs a person looking after it. If there is an API, a direct integration is usually more stable than RPA over the interface.
Where agents win, and where they break
Agents win when the input is free text or varied documents, when the number of steps is not predictable, and when the decision depends on context. Reading a supplier email and understanding that it disputes a penalty rather than asking for a duplicate invoice. Building an answer to a ticket by querying three different systems depending on the case.
Agents break in different ways from RPA. They can be confidently wrong, and the error does not appear as an exception in the log. They cost money per model call, with variable latency. And they bring a new attack surface: the OWASP Top 10 for LLM applications lists "excessive agency" as a risk, when an agent gets more tools, permissions or autonomy than the task needs, and prompt injection sits at the top of the list. An agent that reads external email and has permission to pay invoices is exactly that scenario.
The design that usually works: both, each in its place
RPA vendors themselves now frame the market this way. UiPath describes its orchestration with the line agents think, robots do, people lead. Leaving the product aside, the split is useful: the model interprets, the deterministic flow executes, and a person decides where the cost of error is high.
An example: accounts payable
An accounts payable process at a mid-sized company in Brazil typically has these steps:
- Receive the electronic invoice (NF-e). The XML is structured and standardized. There is nothing to interpret here: an integration or RPA loads the data into the ERP.
- Receive bank slips and service invoices as PDFs, each supplier with its own layout. An LLM step extracts amount, due date, tax ID and payment code, and a deterministic validator checks the check digit and tax ID. A workflow, not an agent.
- Match against the purchase order. If amount and quantity match within tolerance, a fixed rule approves. No model.
- Handle discrepancies: a different amount, an item not received, a supplier email explaining a price adjustment. This is where an agent makes sense. It reads the history, checks the order and the receipt, and proposes an action with a rationale.
- Approve payment. Below an amount the company sets, and with a high-confidence proposal, the flow continues. Above it, a person approves after reading the agent's rationale. The agent never has permission to pay on its own.
In this design the agent works only on exceptions, which is where the expensive manual work is, and it stays away from the money.
What the Klarna case teaches
In February 2024, Klarna announced that its AI assistant handled 2.3 million conversations in its first month, two thirds of its chat customer service, equivalent to the work of 700 full-time agents. In May 2025, CEO Sebastian Siemiatkowski told Bloomberg that cost had weighed too heavily in the decision and the result was lower quality. The company started recruiting people again so customers can always reach a human.
The assistant was not switched off. What changed was the boundary: automation for routine volume, people for cases where mistakes are expensive. Same logic as the accounts payable example.
Six questions to decide each step
- Does the input have a fixed format (XML, a table, a system field), or is it text and varied documents?
- Is the number of steps predictable, or does it depend on the case?
- Is there an API? If so, integration comes before RPA and before an agent.
- What does an error at this step cost, and will anyone catch it before it reaches the customer or the bank account?
- What is the minimum permission the automation needs? Read, suggest or execute?
- How will you measure whether it works: exception rate, rework, cycle time, complaints?
If the answers point to fixed formats, predictable steps and expensive errors, stay with rules and RPA. If they point to free text, variable steps and errors a person can review, an agent is worth testing.
The costs that never make it into the spreadsheet
With RPA, the hidden cost is maintenance: every UI update in the source system can stop the bot. With agents, it is evaluation and monitoring: a test set for every prompt or model change, sampled review of decisions and a trail of what the agent did. Comparing only RPA licenses against token costs compares the smaller half of both bills.
Next step
Take a process that eats hours of your team's time today, map its steps and answer the six questions for each. If you are left with an interpretation step with meaningful volume, test an agent on that step only, with real data and metrics defined upfront. That is what we do in the PoC Factory: validate in 3 to 6 weeks whether the agent solves the right step before you invest in production. When the case holds up, our AI agents work takes it to production with permissions, logs and human review defined from day one.