The question comes up in almost every discovery call with a company that already has automation. They have bots doing something, the bots break more often than anyone admits, and now every vendor is selling agents. The honest answer is that these are different tools for different failure conditions, and choosing correctly is mostly about deciding which kind of wrong you can tolerate.
§ 01What each one actually is
RPA is a program that repeats a path a developer defined. Open this system, read this field, copy it there, click submit. It does exactly that, every time, at machine speed. Its strength is that it is deterministic: given the same input, you get the same output, and you can prove it to an auditor.
An AI agent is given an objective and chooses its own steps. It reads an input that may be a paragraph of prose, decides which tools apply, uses them, checks the result, and adapts if something did not work. Its strength is that it handles cases nobody enumerated in advance. If you want the longer version of what agency means in this context, we covered it in agentic AI vs AI agents.
The single sentence that matters: RPA does one thing perfectly and breaks when the world changes, agents do many things approximately and degrade quietly when they are wrong. Everything below follows from that.
§ 02Where RPA is still the right answer
There is a real bias in the market right now toward putting a language model into processes that never needed one. Deterministic automation remains correct when:
- The input is structured and consistent. Fixed format files, database records, forms with defined fields. If there is nothing to interpret, interpretation is a liability.
- The process is stable. If the steps have not changed in two years, a script that encodes them is cheaper and more reliable than a system that reasons about them every run.
- Volume is high and margins per transaction are thin. Thousands of identical operations per day favour a component that costs nothing per run and never varies.
- Every run must be identical and provable. Financial reconciliation, regulated reporting, and anything an auditor will examine line by line. Probabilistic is the wrong property here, no matter how accurate.
§ 03Where RPA fails and agents earn their place
Most RPA disappointment traces to the same root: someone deployed a deterministic tool against a non-deterministic input. The classic symptoms:
- Unstructured input. Customer emails, supplier messages, scanned documents, and free text notes. A rule can parse a template. It cannot parse a person writing in a hurry, and agents can.
- Exception load. Bots that handle the eighty percent standard cases while a team quietly processes the twenty percent that fail. That twenty percent is where the labour actually is, and it is the part agents are built for.
- Brittleness against change. A vendor redesigns a portal and the bot stops working until a developer rebuilds it. Agents work from intent rather than coordinates and survive small changes.
- Anything requiring judgment. Is this complaint urgent. Does this invoice look wrong. Should this be escalated. Rules can approximate these with long condition lists that nobody maintains. Agents evaluate them natively, and escalate when uncertain.
§ 04The architecture that usually wins
In practice the question is rarely either or. The strongest design puts the agent in front and deterministic code behind it. The agent reads the unstructured input, extracts what matters, applies judgment, and decides what should happen. The deterministic layer executes that decision the same way every time, with validation and logging.
This split matters because it separates the two kinds of risk. A wrong interpretation is caught by an approval step or a confidence threshold. A wrong execution is prevented by code that only does one thing. Putting judgment and execution in the same probabilistic component is how you get a system that occasionally does something surprising to your database, which is the failure mode our builds are structured to make impossible. The reasoning is in our engineering notes.
§ 05Cost, honestly compared
For a simple process, initial build costs are in the same range. The difference is what happens afterward. RPA maintenance is event driven and developer shaped: something changes, the bot breaks, someone rebuilds it. Many RPA programmes have spent more on maintenance than on the original build, which is rarely in the business case.
Agent maintenance is continuous and different in kind: monitoring output quality, updating rules as the business changes, and handling model deprecations. Neither is free. Compare total cost over two years rather than the quote, and include the human effort currently spent on exceptions, since that is usually the largest number on the page and the one nobody counts. Our own pricing across engagement types is in the cost guide.
§ 06A decision rule you can use on a call
- Can you write down every step and every branch, and will that document still be accurate in a year? Use deterministic automation.
- Does the process start with something a person wrote, or end with a judgment call? Use an agent, with approval on anything that writes.
- Is it both, meaning messy input followed by a rigid procedure? Use an agent for the reading and decision, deterministic code for the execution. This is the most common answer.
- Is the process low volume and changing constantly? Use neither yet. Fix the process first.
──
If you already have RPA and want to know which of your broken bots should become agents and which should stay as they are, that is a useful 30 minute discovery call. We will tell you when the answer is to repair the script rather than replace it, and you can see comparable systems in our production cases.