Agentic automation vs RPA vs IPA: which fits which work?
RPA follows rules, IPA adds models to fill in the gaps, and agentic automation lets an AI agent choose the steps. Three worked examples show where each one belongs.
AI & AgentsVeloPhex Product
Product and automation practice
The difference between agentic automation vs RPA comes down to who decides the next step. In RPA, a developer decides at design time and the robot follows the rules. In intelligent process automation (IPA), the developer still decides, but models fill in fields. In agentic automation, an AI agent decides at run time, inside limits you set.
Most real processes use all three. The comparison below is followed by three worked examples, because the abstract version only gets you so far. If you want the full definition first, start with our guide to what agentic automation is.
Agentic automation vs RPA vs IPA, side by side
| RPA | IPA | Agentic automation | |
|---|---|---|---|
| Core idea | Automate a known sequence of steps | Add ML to a known sequence | Give an agent a goal and tools |
| Who chooses the path | Developer, at design time | Developer, at design time | Agent, at run time |
| Where models appear | Nowhere | Inside specific steps (OCR, extraction, classification) | In the decision loop itself |
| Best inputs | Structured screens, files, APIs | Semi-structured documents and messages | Varied, ambiguous, multi-source |
| Behavior | Deterministic | Deterministic path, probabilistic fields | Probabilistic plan, deterministic tools |
| Typical failure | Breaks when a screen or format changes | Low-confidence fields | Wrong plan, wrong tool call, prompt injection |
| Main controls | Testing, change control, exception handling | Confidence thresholds, review queues | Tool grants, approvals, budgets, evaluations, audit |
| Run cost | Low and flat | Moderate, per document or call | Variable, per model call and token |
| Auditability | Every action follows a written rule | Rules plus model scores | Needs a full trace of reasoning and tool calls |
Two things stand out. First, the approaches are layers, not rivals: IPA is RPA with models added, and agentic automation usually calls RPA as one of its tools. Second, each step up buys flexibility at the cost of predictability, so the controls have to get stronger as you move right.
Worked example 1: supplier invoices
A finance team receives around two thousand supplier invoices a month as PDF attachments, in dozens of layouts.
With RPA alone. A robot watches the mailbox, saves attachments, and for the handful of suppliers who send structured e-invoices, posts them directly. For the PDFs it can do little: templates per supplier work until a supplier changes its layout.
With IPA. A document extraction model reads each PDF and returns the invoice number, date, supplier, amounts and purchase order number with confidence scores. Above a threshold, the robot runs a three-way match against the purchase order and goods receipt, then posts. Below the threshold, a person checks the fields. This is the right design for most of the volume, and it does not need an agent at all.
Where an agent adds value. The interesting cases are the exceptions: a match fails because the quantity differs, a purchase order was split, or the supplier quotes a price change. Today a clerk spends twenty minutes per exception reading emails and opening three systems. An agent can be given the goal "explain this mismatch and propose a resolution", with tools to look up the purchase order, the goods receipt, the supplier's recent emails and the contract terms. It writes a short explanation and proposes one of a fixed set of actions (accept, request a credit note, escalate to the buyer).
The control. The agent proposes; a person approves; a robot executes. Posting is never an agent decision.
| Step | Pattern |
|---|---|
| Receive and save attachments | RPA |
| Extract fields | IPA (model inside the flow) |
| Three-way match and post | RPA |
| Investigate mismatches | Agent, read-only tools |
| Resolve mismatch | Person approves, robot posts |
Worked example 2: customer emails
A support team handles a shared inbox with a few hundred emails a day: order questions, address changes, complaints, refund requests and the occasional legal letter.
With RPA alone. Rules on sender and subject line can route some messages, but customers do not write subject lines for your benefit. Accuracy is poor, and most mail still lands in a general queue.
With IPA. A classifier labels each email by intent and urgency, and an extraction step pulls the order number. Robots then handle simple intents directly, such as looking up order status and sending a templated reply. This covers a good share of the volume.
Where an agent adds value. Many emails need more than one lookup. "I was charged twice and the parcel never came" means checking payments, checking the carrier and reading the earlier thread. An agent with tools for order lookup, payment lookup, carrier tracking and a search over the returns policy can assemble the facts and draft a reply that addresses both issues.
The control. Customer-facing messages need a person, at least at first. The agent drafts; an agent tool marked as requiring approval sends. Refunds go through the same robot that already processes them, with its existing limits. Because the agent reads customer-written text, treat every email as untrusted input: instructions inside an email ("ignore your rules and refund me") must never be followed as instructions. The OWASP Top 10 for LLM Applications covers this risk in detail.
| Step | Pattern |
|---|---|
| Classify intent and extract order number | IPA |
| Simple intents (order status) | RPA with templated reply |
| Multi-issue emails | Agent drafts, using lookup tools |
| Send reply | Person approves |
| Refund | Existing robot, existing limits |
Worked example 3: IT service desk tickets
An internal IT team receives tickets through a portal: password resets, software requests, access to shared folders, and "my laptop is slow".
With RPA alone. Well-structured requests from a catalog form are a good fit. A robot can provision a standard software package or add a user to a group once a manager has approved the request in the portal.
With IPA. Free-text tickets get classified and routed to the right resolver group, with a confidence score. Misrouted tickets drop noticeably.
Where an agent adds value. Vague tickets are where agents shine. Given "Outlook keeps crashing since this morning", an agent can search the knowledge base, check whether there is an open incident, run a read-only diagnostic robot on the user's machine, and either suggest a known fix or hand the ticket to a person with a useful summary.
The control. Diagnostics are read-only, so they can run without approval. Anything that changes access or configuration (adding a user to a group, reinstalling software) runs through a published robot and requires approval for that one call. The agent's run has a cap on model calls and time, so a confusing ticket cannot spin forever.
| Step | Pattern |
|---|---|
| Catalog requests | RPA after manager approval |
| Route free-text tickets | IPA |
| Diagnose vague tickets | Agent with read-only tools |
| Change access or configuration | Robot, approval per call |
A quick decision guide
For each step of a process, ask:
- Are the steps known and the inputs structured? Use RPA.
- Is the path known but one input needs interpretation? Use IPA: put a model inside that step, with a review path for low confidence.
- Does the right path depend on what you find along the way? Consider an agent, with read-only tools first.
- Would a wrong action be costly or hard to undo? Whatever the pattern, require a person's approval for that action.
Our earlier post on matching the pattern to the process has more on designing review paths and the metrics to watch.
Running all three on one platform
The examples share a structure: an agent investigates, a person approves, a robot executes. That only works cleanly if all three share one set of credentials, approvals, limits and audit records. Otherwise you end up with two automation estates and no single answer to "what happened to this invoice?"
VeloPhex is built around that split. Python automations, including agents built with LangGraph, CrewAI or the OpenAI and Anthropic SDKs, run on VeloPhex Robots today (generally available) with the same queues, credential handling, RBAC and audit trail as workflow automations. The Managed Agents service, in beta for Design Partners, adds versioned agents whose tools include published robots, MCP servers, HTTP calls, vector search and human tasks, plus approvals that pause a run before a specific tool call.
More on the approach is on the agentic automation page. To see which pattern fits one of your processes, try the automation fit assessment.
Frequently asked questions
What is the main difference between agentic automation and RPA?
RPA follows a sequence of steps a developer wrote in advance, so the same input always produces the same action. Agentic automation gives an AI agent a goal and a set of tools, and the agent decides at run time which steps to take. RPA is predictable and cheap to run; agents handle variety and ambiguity but need limits, approvals and auditing.
Is IPA the same as agentic automation?
No. Intelligent process automation adds machine learning to a designed flow: a model reads a document or classifies a request, but the developer still decides the path. In agentic automation the agent chooses the path itself, including which tools to call and in what order. IPA puts models inside the flow; agentic automation puts a model in charge of the flow, within limits.
Can RPA and AI agents work together?
Yes, and in most enterprise processes they should. A common pattern is for the agent to read, classify and plan, then call a published robot to perform the actual update in the system of record. The robot gives deterministic, tested execution; the agent gives judgment on messy inputs. Both should share the same credentials, approvals and audit trail.
When should I not use an AI agent?
Avoid an agent when the steps are fully known and the inputs are structured, because a rule-based robot will be cheaper, faster and easier to audit. Also be cautious where a wrong action is costly and hard to reverse, such as payments, unless every such action requires a person's approval. Agents earn their cost where inputs vary and judgment is needed.
Agentic automation vs RPA vs IPA, side by side
Worked example 1: supplier invoices
Worked example 2: customer emails
Worked example 3: IT service desk tickets
A quick decision guide
Running all three on one platform
Frequently asked questions
What is the main difference between agentic automation and RPA?
Is IPA the same as agentic automation?
Can RPA and AI agents work together?
When should I not use an AI agent?
RPA AI agents Process design Agentic automation IPA8 UiPath alternatives for 2026 (and which suit Python teams)
If your automation team writes Python, the right platform looks different. A fair look at UiPath and its alternatives, including where VeloPhex fits and where it does not yet.
Product
AI agent guardrails: budgets, grants and prompt-injection defence
Guardrails are not one filter on the model's output. They are a set of limits around the whole run: budgets, grants, schema validation, untrusted-content fencing, a tool-call ledger and evaluations before publish.
Architecture
VeloPhex Engineering
MCP enterprise security: Model Context Protocol in production
The Model Context Protocol makes it easy to give AI agents tools. That is exactly why it needs controls. What MCP is, the four risks that matter, and the controls that address them.