AI Agents or RPA? Sort Your Process Step by Step Before You Pay for Either

Automation reaches a company of a few hundred people in two forms now. One is the software robot of RPA, robotic process automation, which repeats the clicks and keystrokes your team makes in your systems. The other is the AI agent, which reads what arrives and decides what to do next.

Both get pitched for the same work: the intake inbox, the supplier invoices, the requests nobody has time to sort. The quotes are hard to compare: the robot is cheap to run and breaks when a screen changes, while the agent copes with messy input, costs something on every run and is harder to check.

The choice gets much easier when you make it for each step instead of for the whole process.

Many steps are fixed: the same fields, moved the same way, under a rule someone could write on an index card. Those want rules, through a direct connection between your systems where one exists and a robot where only a screen does.

A few steps read something messy, an email or a scanned form, into fields. Those want a model doing that one job inside the fixed flow.

An agent earns its running cost only on the steps whose path depends on what they find, and there it should read and propose, not act. Anything that sends, pays or signs stays with a person.

That sort is also where we'd start if we built the automation with you at Qvery: the steps first, the tools after.

The worked example is a law firm's new-client intake, priced on our assumptions rather than anyone's books. The method carries to a freight bill or a tenant's repair request; only the systems change.

RPA Repeats Steps You Wrote Down; an AI Agent Picks Its Next Step

A robot, in RPA terms, is a script. Someone records the sequence once (open the email, copy the invoice number, paste it into the fourth field, click save) and the robot repeats it, finding each field on the screen by fixed rules.

It does the same thing every time, so auditors can follow it and each run is cheap. It also stops the moment the screen or the file changes.

UiPath, which sells RPA, says so on its own engineering blog: “Traditional selectors, while fast, are fragile.”¹ A selector is the rule a robot uses to find a field.

Where two of your systems can talk to each other directly, through what developers call an API, that connection does the same job without the screen, and it should come before any robot.

An AI agent is a language model given a goal, a set of tools (the mailbox, your case or transport system, a search) and limits. It reads what arrives, picks the next step, checks the result and keeps going until the job is done or a rule says a person decides.

Anthropic, which makes the Claude models, draws the line in the same place: a workflow runs models and tools “through predefined code paths”, while an agent directs “its own processes and tool usage.”²

Between the two sits a third design that sales pitches blur into both: a model doing one reading job inside a fixed flow.

An email comes in, the model turns it into a client name, the other side, a matter type and a date, and the flow carries on by rules. Nothing about the path is left to the model.

What decides where each one goes is how it fails. A robot fails loudly: a field is missing, the button moved, the run stops and someone sees an error. A model tends to fail plausibly.

When UiPath tested agents that work through the screen on long, repetitive office tasks, they lost track of which items they had processed, repeating some and skipping others. In forms they invented believable values for fields meant to stay empty.³ Where a robot would have stopped, the agent handed back a finished form.

Sort Every Step by Four Questions Before Anyone Picks a Tool

Write the process down as it ran last month, one line per step, one verb per line. If you haven't mapped the job from last month's real cases yet, do that first: the written procedure describes the job on its best day.

Then ask four questions of every step:

1. Check the input's shape

   Does it arrive the same way every time? A form with fixed fields does. An email from a new client doesn't.

2. Try writing the logic down

   Can you write it as if/then, with no “it depends”?

3. Ask whether the path moves

   Does the next move depend on what the step finds? Checking a total against a purchase order doesn't. Working out why a payment matches no invoice does.

4. Ask whether it can be taken back

   If the step gets it wrong, can you undo it before anyone outside the company sees it?

The answers sort the steps into four kinds, and each kind gets its own tool:

A step that is two kinds is two steps. “Read the email and file it” is a reading step followed by a rule step, and splitting it is what lets each half get the right tool.

The third and fourth questions do most of the work.

Sorting by how repetitive or complex a step feels misses both: a complex step with a fixed path is still a rule, and a simple step you can't take back is still a decision.

The companies that build the models draw the same line. OpenAI's guide to building agents lists three conditions where an agent fits: judgment calls full of exceptions, rules too tangled to maintain, and work that runs on unstructured text. Where a use case doesn't clearly meet them, it says, a deterministic setup may be enough.⁴

Gartner's advice is agents where decisions are needed and automation for routine workflows, and it notes that “many use cases positioned as agentic today don't require agentic implementations.”⁵

In a Law Firm's Intake, Rules Save Most of the Hours and the Agent Only Reads

A new-client intake is a good test because it has all four kinds of step and a rule with teeth behind one of them.

Under the ABA's model rules, a lawyer should keep “reasonable procedures” for finding conflicts of interest, and “ignorance caused by a failure to institute such procedures will not excuse” a violation. A conflict found after the work starts ordinarily means withdrawing, unless the client consents.⁶

The check itself is often clerical. Someone runs the names through the matter, document and billing records, hands any hit to a lawyer to clear, and runs a wider check when the file opens.

Here is the whole intake sorted and priced for a firm that opens 80 new matters a month, with 1 in 4 returning a hit. The minutes are our assumptions; put yours in.

Today that is 5,480 minutes a month, about 91 hours. After the sort it is 1,560 minutes, 26 hours. The 65 hours that come off are worth about $2,940 a month at an assumed $45 an hour of staff time.

The four rule steps give back 3,280 of the 3,920 minutes, 83.7%. The one step a vendor would sell as the agent gives back 400, about a tenth.

The order comes from the shape of the work, not from our minutes: rule steps run on every one of the 80 matters, and the investigation runs only on the 20 with a hit.

Change the minutes and the order holds, unless a hit takes hours to run down. The decisions don't shrink at all: the lawyer's 12 hours stay, by design.

The investigation has three possible designs. A paralegal can run it down. A fixed flow can pull the same records for every hit (the old matter's parties, the lawyer who handled it, when it closed) and have a model summarize them in a memo.

For a hit on a closed matter for the same client, that memo is the whole job. Or an agent can follow a trail that can't be written in advance: a parent company under another name, a client's former name, a person who has since moved firms.

Start with the fixed pull and the summary, and give the agent only the hits the summary can't settle. It reads, writes a memo with its sources, and changes nothing. It can only follow links your records hold, so if the old files aren't connected to the billing records, fix that first.

Hand the whole intake to an agent and it re-decides every rule step on every matter: you pay for that on every run, someone checks its work on all 80 matters instead of the 20 with a hit, and its plausible mistakes land in the name search, where a missed hit is the expensive kind.

Hand the inquiry to a robot and it stops on every email that doesn't fit its template, and the six minutes go back on someone's desk.

If your intake, or any process with the same mix of fixed steps and messy ones, still runs by hand, this split is the first thing to draw.

Keep Sending, Paying, and Signing With a Person or a Rule They Signed Off

The first reason is the plausible failure: a wrong memo costs a lawyer ten minutes, while a wrong engagement letter that already went out has to be explained to the client.

The second is that model steps compound. Suppose each step in a model's chain is right 95% of the time and every step depends on the one before. Ten steps in a row come out clean in about three runs in five; at 99% a step, about nine in ten.

That's arithmetic on a simplified chain, not a measurement, but the shape holds. Anthropic's guidance says an agent's autonomy “means higher costs, and the potential for compounding errors.”² A rule step doesn't drift like that: it runs, or it stops.

Approving every step fails the other way: the person approving becomes the process, and the checking eats the saving.

Approve only what can't be taken back. In the intake that's two places: clearing the conflict and sending the letter. Everything else runs and reports, and someone samples the reports.

When checking a step still takes longer than doing it, narrow the step rather than adding reviewers.

Before You Buy an Agent, Ask Which Steps the Model Decides

RPA vendors now sell “agentic automation”, and the label covers a lot. UiPath's own description of it says robots carry out “a great majority of tasks throughout an end-to-end agentic workflow.”⁷

Gartner has a name for the loose end of the label, “agent washing”, and estimates only about 130 of the thousands of agentic AI vendors are real.⁵

It also predicts over 40% of agentic AI projects will be canceled by the end of 2027, over cost, unclear value or weak risk controls.

A fixed flow of robots with a model reading one messy step is the design I'd pick for almost any reading step. The path is fixed and can be audited, the model does the one thing rules can't, and when it's wrong, it's wrong in one field you can check.

The risk is paying agent prices without knowing which steps the model decides.

So make every vendor show you on your own work. Give each one the same set of last month's cases, with the answers your team reached, and ask for:

• Which steps the model decides, and which run on fixed rules.
• What it did with the cases no rule anticipated: stopped, asked, or guessed.
• Every system it wrote to, and whether a person approved each write.
• One run's log: what it read, what it decided, and why.
• What a run costs at your volume, and at twice your volume.
• What happens when a screen or a form changes, and who fixes it.

Sort One Process This Week, Then Count the Minutes Spent Checking

Pick the process that eats the most hours, write last month's steps one per line, and let an assistant draft the sort.

Chat assistants such as Claude or ChatGPT can run every step through the four questions, and they're good at catching steps described too loosely to sort. This prompt makes them answer per step and ask instead of guess:

Below is one process from my company, one step per line, as it ran last month.

For each step, answer four questions with yes, no, or unclear:
1. Does the input arrive in the same shape every time?
2. Can the logic be written as if/then rules, with no "it depends"?
3. Does the next action depend on what the step finds?
4. If the step gets it wrong, can we undo it before anyone outside the company sees it?

Then give each step one kind:
- RULE: same input, if/then logic, the same next action every time.
- READING: messy input (an email, a scan, a free-text form) that has to become fixed fields.
- OPEN-ENDED: the next action depends on what the step finds.
- DECISION: it sends, pays, signs, deletes or changes access, or someone carries a professional duty for it.

If a step fits two kinds, split it into two steps and label both. If my description is too vague to answer, write "unclear" and the question you would ask the person who does the step.

Return a table: step, the four answers, the kind, and one line on what a person should check. Do not recommend software.

The process:
[paste your steps here, one per line]

What comes back is a table like the intake's, with the vague steps turned into questions. We ran it once on Claude and once on an OpenAI model with the eight intake steps.

Both put the inquiry, the name search and the lawyer's decision in the same kinds we did. Both split approving the letter from sending it, and marked the send as the one step that can't be taken back. Both asked whether the engagement letter is a template or written per matter.

Claude also asked whether the name variants the team searches are written down, because if they aren't, the search isn't a rule yet.

Take the DECISION and OPEN-ENDED rows to the person who does the work and check them line by line. Take the RULE rows to whoever runs your systems and ask, step by step, whether a direct connection exists before anyone records a robot.

A month after anything goes live, count three things per step:

• Minutes a person spent checking the automation, against the minutes the step used to take.
• Errors in a re-checked sample: someone redoes a handful of finished cases by hand and compares, because the errors nobody caught are the ones that matter.
• What it cost to undo the mistakes that got through.

Name one person who owns the failed runs and the approval queue, and agree the stop rule before the first run: a step whose checking minutes don't fall below its old minutes goes back to rules or to a person. A two-week pilot is the place to learn those numbers before you sign anything longer.

Circle the steps marked DECISION before you meet either vendor. Every quote you get should say where those steps sit.