AI agent or RPA: how to pick the right one for a process

Deciding between an AI agent and RPA is not a technology contest, it is a question about your process. Here is the exact test I run before writing any code.

A client once asked me to "add an AI agent" to a process that was really just moving a CSV from an SFTP folder into their billing system every night at 2am. No judgment needed. No language to understand. Same six columns, same destination, every single day. That is not an AI agent job. That is a cron script or, if you want a pretty dashboard and error alerts, an RPA bot. The whole ai agent vs rpa question usually comes down to one thing people skip: does the process actually need a decision made, or does it just need a fixed set of steps done reliably?

I embed with companies for short engagements and ship this stuff into production, then stay long enough to watch it break and fix it. So this is not a vendor comparison chart. This is how I actually pick, and where I have watched the wrong pick cost a team three months.

The real difference between an AI agent and RPA

RPA follows a script you wrote. It clicks the same buttons, reads the same fields, and if the form moves by 20 pixels or a new dropdown appears, it falls over. It has no idea what it is doing. It is fast, cheap to run, and completely literal. Tools here are UiPath, Automation Anywhere, or honestly a Python script with Playwright if you have engineers.

An AI agent decides. You give it a goal, some tools, and it figures out the sequence at run time. It can read a messy email, pull the order number out of a paragraph a human wrote at midnight, decide whether this is a refund or a complaint, and call the right function. That flexibility is the whole point. It is also the whole risk. An agent that can decide can decide wrong, and it will, on inputs you never tested.

Here is the line I use. If you can write down every step and every branch without saying "it depends on what the input says," you want RPA or plain code. The moment you need to interpret unstructured input or make a judgment call, an agent earns its keep.

A test I run before writing any code

Before I pick, I try to write the process as a flowchart on paper. Not the happy path. Every branch. If I finish the flowchart in ten minutes and there are no boxes that say "understand what the customer meant," the answer is RPA. Done. Do not put an LLM in the loop, you are adding latency, cost, and a failure mode for no reason.

But if the flowchart keeps sprouting branches, or one box is genuinely "read this and figure out the intent," that box is your agent. And notice I said that box, not the whole process. This is the part most teams get wrong.

Most good systems are both

The framing of ai agent vs rpa as an either/or is a trap. The best production systems I have shipped use an agent for the one hard decision and deterministic code or RPA for everything around it. The agent classifies the intent and extracts the fields. Then plain code does the refund, updates Postgres, and posts to Zendesk. You want the LLM touching as little of the pipeline as possible, because every step it owns is a step you cannot fully predict.

Think of the agent as the router and the interpreter, not the worker. Let it read the incoming support email and return structured JSON. Then hand that JSON to boring, testable functions.

# The agent does ONE job: turn a messy human message into structured intent.
# Everything after this is deterministic code, not the model.

SYSTEM = """You classify inbound support emails for a billing team.
Return ONLY valid JSON, no prose. Shape:
{
  "intent": "refund" | "cancel" | "billing_question" | "other",
  "order_id": string | null,
  "confidence": number  # 0 to 1
}
If you are not sure, set intent to "other" and confidence below 0.5.
Never invent an order_id. If it is not clearly in the text, use null."""

def route(email_text):
    result = call_llm(SYSTEM, email_text)   # returns parsed JSON
    if result["confidence"] < 0.7 or result["order_id"] is None:
        return escalate_to_human(email_text, result)
    # from here down it is plain code, fully testable
    return HANDLERS[result["intent"]](result["order_id"])

Notice the confidence gate and the human escalation path. That is not optional polish. That is the difference between a demo and something you can leave running on a Friday.

Where RPA quietly wins

RPA gets mocked by the AI crowd, but it is the right answer more often than people admit. If a process talks to a legacy system with no API, a green screen from 1998, or a vendor portal that will never give you programmatic access, RPA is sometimes the only thing that works. You are literally driving the mouse because there is no other door in.

It is also the right call when the cost of a wrong action is high and the input is fully structured. Payroll runs. Reconciliation. Moving records between two databases on a schedule. You do not want a probabilistic model anywhere near a process where the correct output is already known with certainty. Determinism is a feature. An agent trades determinism for flexibility, and if you do not need the flexibility you are paying the tax for nothing.

• Fixed inputs, fixed steps, known correct output: RPA or a script
• Legacy system with no API and a stable UI: RPA
• High cost of error and zero ambiguity: deterministic code, no LLM
• Volume is huge and latency matters: avoid the model in the hot path

Where an AI agent earns its cost

Agents are worth it when the input is unstructured and varied, and when the number of possible branches is too large to hand code. Support triage. Reading contracts and pulling out the renewal date and liability cap. Turning a rambling sales call transcript into CRM fields. Anything where a human currently reads something and then decides what happens next. That reading and deciding is exactly what an agent replaces.

They also shine when the process changes often. If a business rule shifts every few weeks, updating a brittle RPA script is painful. Adjusting a prompt or the tools an agent can call is faster. But do not oversell this to yourself. A prompt change is still a change to a system whose behavior you cannot fully enumerate, so you still need evals before it ships.

The framework question people ask next

Once you have decided you need an agent, do not reach for LangGraph or CrewAI on day one. Most of what people call an agent is a single LLM call that returns JSON, plus a loop and a couple of tool functions. Start there. I have shipped systems that ran for months as one well tested function with a retry and a fallback. Add a framework when you genuinely have multiple steps that need shared state and branching, not before. n8n or Zapier is often plenty for gluing the deterministic parts together, and pgvector on the Postgres you already run beats standing up a separate vector database for most retrieval needs.

The decision, compressed

So how do I actually choose? I ask three questions in order. Is the input structured and predictable? If yes, lean RPA or code. Does the process require interpreting something a human wrote or making a judgment? If yes, an agent owns that one step and nothing more. And what does a wrong action cost? The higher that cost, the more I push the model out of the direct path and behind a confidence gate with a human catch.

The best AI systems I have shipped use the model for the smallest possible slice of the work. The agent decides. Boring code does everything else.

If you take one thing from this: stop asking which technology is better. They answer different questions. RPA does the same thing perfectly every time. An agent does a different thing every time and needs judgment to do it. Map your process, find the boxes that need a decision, and put the agent only in those. Wrap it in code you trust. That is the whole trick, and it is less exciting than the pitch decks, which is usually how you know it works.