The pitch is familiar by now. Your RPA estate is brittle. Bots break when a screen changes. Maintenance costs are eating the savings. AI agents can reason their way around the changes, handle exceptions, and do the work the bots couldn't. Therefore: replatform.
Some of that is true. The part that isn't true is the "therefore." Replacing a bot with an agent makes sense for a specific kind of work. For most of the rest, you are introducing non-determinism into a process whose entire value was that it ran the same way every time.
Here's how we think about it when a client asks.
What RPA was actually good at
Strip away the marketing and RPA was a way to move structured data between systems that didn't have APIs — or whose APIs were locked behind a vendor contract nobody wanted to renegotiate. The work was deterministic: read this field, paste it into that field, click submit, log the confirmation number. When the inputs were clean and the screens were stable, the bot ran for years.
The two failure modes are well known. First, when the source system changes — a field moves, a popup appears, a session times out differently — the bot breaks and someone has to fix it. Second, when the inputs aren't clean, the bot can't tell. It happily processes the bad record and the error shows up three steps later, by which time the audit trail is a mess.
These are real costs. But neither of them is solved by replacing the bot with an agent that reasons. They're solved by treating the source system, the inputs, and the maintenance discipline as the actual problem.
Where AI agents earn their keep
The work that genuinely belongs to an agent has three properties: inputs are unstructured, the decision requires judgment, and the cost of being wrong occasionally is acceptable. That last one matters more than people admit.
Reading a free-form customer email and routing it to the right queue — that's agent work. The input is unstructured language. The decision involves judgment. Getting it wrong 2% of the time is fine because a human reviews the edge cases anyway.
Triaging a vendor invoice that arrived as a PDF with no consistent format — agent work. Same three properties.
Drafting a response to a contract clause that an underwriter will review — agent work. The agent isn't approving anything; it's compressing the underwriter's time-to-first-draft.
The pattern is: agents do well where bots did poorly because the inputs weren't structured enough for a bot in the first place. They are not a better bot. They are a different tool.
Where AI agents will burn you
The reverse pattern is the one we see clients walking into in 2026. The bot is working. The process is clean. Someone proposes replacing it with an agent because the agent vendor has a quarterly target.
Now the process has a 3% rate of doing something subtly wrong. The 3% lands in finance close, or a customer's account, or a regulated workflow — and the audit team can no longer answer "why did the system do that?" with a deterministic trace. The bot had a log. The agent has a reasoning chain that changes between runs.
For a process where the value was determinism, you have traded a known maintenance cost for an unknown correctness cost. The maintenance cost was on a line item. The correctness cost is going to surface as an incident.
The cases where this trade looks worst:
- Financial close and reconciliation — where the same input must produce the same output, every time, and "the agent decided" is not an acceptable answer to an auditor.
- Regulated submissions — where the format is rigid and the cost of a fielded error is a re-filing or a fine.
- High-volume, low-margin transactions — where a 1% error rate at scale wipes out the productivity gain.
For these, the bot is the right answer. If the bot is brittle, the fix is to make the bot less brittle — usually by getting the source system to expose an API, which is a one-time investment instead of an ongoing fight.
A simple decision framework
When a client hands us their automation inventory, we sort each process against four questions:
- Are the inputs structured or unstructured? Structured → bot or API. Unstructured → agent candidate.
- Does the decision require judgment, or just rule application? Rules → bot. Judgment → agent candidate.
- What is the cost of an occasional wrong answer? Low and reviewable → agent fine. High or unreviewable → keep deterministic.
- Does the bot already work? If yes, and the maintenance cost is bounded, leave it alone. Migrating working automation is a tax with no return.
Most enterprise automation estates have three buckets after this exercise: a small set of processes where agents are a clear win, a small set where the bot was wrong from the start and the real fix is an API, and a large middle where the bot is fine and the right answer is to leave it running and spend the budget somewhere with actual leverage.
The hybrid that usually wins
The most resilient pattern we deploy isn't agent or bot — it's an agent that decides, calling a bot or API that executes. The agent reads the unstructured input, classifies it, and hands off a clean, structured payload to a deterministic system that does the actual work. Audit gets a trace at both layers. The reasoning step is logged. The execution step is reproducible.
This split also gives you a clean way to evolve. The bot side becomes an API as the underlying systems modernize. The agent side gets better as the models do. Neither change forces the other.
The honest takeaway
If a vendor is telling you to rip out RPA wholesale and replace it with agents, ask them which of your processes they've actually looked at. The answer is usually "none of them in detail." The right migration is selective, evidence-based, and smaller than the slide deck suggests.
Agents are a genuinely new capability. They belong in the parts of the estate where the old tools couldn't go. They do not belong in the parts that were working — and the discipline to tell the difference is what separates an automation strategy from a re-platforming bill.