Every Ops and BA team eventually has the same conversation: “we should automate this.” The word “automate” quietly papers over two very different tools that get reached for — RPA (robotic process automation) and, more recently, AI agents like Claude Code. They both promise to take a task off someone’s plate. They do it in almost opposite ways, and picking the wrong one is a common reason “automation” projects stall or need constant babysitting.
The one question that actually separates them: does the task follow the exact same steps every time, or does it require reading the situation and deciding what to do?
What RPA actually does
RPA tools (think of the category broadly — desktop and enterprise RPA platforms) work by recording and replaying. Someone performs a task once — click here, type this value, copy that cell, paste it there, click submit — and the tool records the exact sequence of clicks, keystrokes, and field positions. From then on, the bot replays that sequence, fast and tirelessly, whenever it’s triggered.
This is a genuinely powerful fit for the right job: high-volume, rule-based, structured tasks where the screen and the steps never change — copying data between two systems with a stable layout, running the same nightly reconciliation, extracting fields from a form that always looks identical. Done well, it’s fast, cheap per transaction, and produces a clean audit trail of exactly what ran.
The trade-off is baked into how it works: an RPA bot doesn’t understand what it’s doing — it replays what it was shown. It has no model of the task’s purpose, only the recorded motions. Move a button, redesign a login screen, add a new required field, or hand it an invoice in a slightly different layout than the one it was trained on, and the bot doesn’t adapt — it breaks. Someone has to notice, diagnose, and re-record it. That fragility, not vendor quality, is the well-known reputation RPA has for needing constant maintenance.
What an AI agent like Claude Code does differently
An AI agent doesn’t replay a recording — it reads the situation and decides what to do, step by step, based on what it’s actually looking at. Give Claude Code a goal — “reconcile this month’s expense report against the receipts in this folder and flag anything that doesn’t match” — and it opens the files, reads their actual contents, works out what “doesn’t match” means for this data, and produces a result. Change the file format, the column order, or the shape of the exceptions next month, and it can still work through it, because it’s reasoning about the content, not replaying fixed coordinates.
That’s the core trade against RPA: an agent survives change that would break a recorded bot, because there’s no recording to go stale. What it needs instead is oversight — the same way a capable new hire needs their early work checked. On Claude Code Desktop, that oversight is built in: it proposes a change, you see a visual before/after, and you approve or reject it — nothing consequential happens unreviewed by default.
The other practical difference Ops and BA teams notice fast: who can build it. Standing up an RPA workflow usually means a developer or a dedicated RPA specialist working in purpose-built automation software. Claude Code is driven by typing a plain-English instruction inside a folder of your real files — a business analyst or Ops lead can start directly on real work without a separate automation platform or a specialist build queue.
A quick comparison
| RPA | AI agent (e.g. Claude Code) | |
|---|---|---|
| How it works | Records and replays a fixed sequence of clicks/fields | Reads the actual content and decides the next step |
| Best for | High-volume, unchanging, rule-based, structured tasks | Tasks needing judgment, reading, or unstructured input |
| When the screen/data changes | Breaks — needs re-recording | Usually adapts, because it isn’t replaying fixed coordinates |
| Who builds it | Developer or RPA specialist, dedicated platform | Whoever has the task — plain-English instructions |
| Oversight model | Runs unattended once validated; audit log of clicks run | Proposes a change, you review a visual diff, then approve |
| Handles unstructured input (emails, PDFs, free text) | Poorly — needs structure to key off | Well — reading and judgment is the point |
| Cost shape | License + specialist build/maintenance time | Usage-based; a business user’s own time to direct it |
Both categories keep evolving — many RPA platforms are adding AI features, and agent tools keep getting better at high-volume structured work too — so treat this as the current shape of the trade-off, not a permanent line. The underlying question (fixed replay vs. reasoning about content) is what to keep asking as both categories move.
How to actually choose
Sort the task by what it actually requires:
- The exact same steps, on the exact same screen layout, thousands of times, and nothing about it changes → RPA is usually still the better fit, especially if it’s already built and stable.
- The task involves reading something (an email, a document, a messy spreadsheet), making a judgment call, or producing a draft a person will review → an AI agent is the better fit — this is exactly the territory RPA struggles with.
- The inputs or the screen change often, or you don’t have the specialist time to keep re-recording a bot → lean toward an agent; the maintenance burden moves from “fix the recording” to “review the output,” which is usually the cheaper failure mode.
Many Ops and BA teams end up running both, aimed at different halves of their process list — RPA for the stable high-volume plumbing, an agent for the judgment-heavy or unstructured work around the edges of it. They’re not rivals for the same job; they’re tools for two different shapes of task that both got called “automation.”
The bigger picture
The RPA-vs-agent question is really a proxy for an older idea: automate the predictable parts with rules, and hand the variable parts to something that can think. RPA was the best available answer for the second half of that for years, applied to any task rigid enough to fake it — hence the brittleness. Agentic tools are a more honest fit for the variable half, because reading and deciding is what they’re actually built to do.
If you’re an Ops or BA lead scoping an automation initiative, the practical move is to sort your task list by that one question — fixed sequence or judgment call — before picking a tool. The Business Analyst operating guide walks through how one such team draws that line and keeps the human sign-off in place either way.