October 17, 2026

What Is RPA? How Robotic Process Automation Works, and Where AI Agents Take Over (2026)

Written by Christos Papadimitriou October 17, 2026

What is robotic process automation (RPA)? RPA is software that copies the clicks and keystrokes a person makes on a computer, so a “bot” can do the same rule-based task again and again without getting tired or making typing mistakes. It logs into your ERP, reads a field, copies it into a spreadsheet, sends the email and moves to the next record. It needs no changes to the systems it works in, which is why companies with old software like it so much. What it cannot do is think: if the screen changes or the input is messy, a classic RPA bot stops.

That last point is where most of the confusion with AI agents begins. Many CEOs now hear “RPA”, “automation” and “AI agents” in the same sales pitch. Our sister research team at House of 47 asked four AI models how many large-company CEOs could explain how an agent differs from a chatbot or RPA. Their estimates ranged from 25% to 45%. In other words, most could not.

This guide explains, without technical jargon:

what RPA is and how it works, part by part;
where it pays off, with real use cases in finance, HR, customer service and insurance;
where it breaks, and why maintenance is the hidden cost;
how RPA differs from AI agents, and why the best setups use both;
how to choose and how to start.

What RPA actually is: a robot that uses your screen

Forget the image of a metal robot. The “robot” in robotic process automation is a piece of software running on a computer or a server. (If you are curious about the physical kind, our research on humanoid robots in everyday life covers when they may reach ordinary homes. That is a very different story.)

The easiest way to think about an RPA bot is as a very fast, very literal temp worker who follows a written procedure to the letter:

It follows a script. Step 1: open the invoice folder. Step 2: read the supplier number. Step 3: type it into the ERP. No step is skipped, and no step is added.
It uses the same screens your people use. It clicks buttons, fills in fields and reads values, usually through the user interface.
It never improvises. If a rule says “if the amount is over €10,000, send it to the finance manager”, it does exactly that. If something happens that the rule does not cover, it raises an exception and waits for a person.
It is consistent. The thousandth record is handled exactly like the first.

That literalness is RPA’s biggest strength and its biggest weakness. It is reliable when the work is predictable, and it is helpless when it isn’t.

How RPA works: the main parts

Every major RPA platform, whether UiPath, Automation Anywhere, Microsoft Power Automate or SS&C Blue Prism, is built from the same building blocks. The names differ; the ideas are the same.

1. The recorder and the designer (where bots are built)

A recorder watches a person do the task once and turns the clicks into draft steps. A designer (sometimes called a studio) is the visual editor where a developer cleans up those steps, adds rules (“if the field is empty, skip”), loops (“for every row in the file”) and error handling. Recording gets you a first draft. Almost every production bot is then rebuilt by hand in the designer, because a raw recording is fragile.

2. Workflows (what the bot does)

A workflow is the written procedure the bot follows: a sequence of steps, decisions and loops. A good workflow is short, well named and broken into reusable pieces, such as “log in to the ERP” or “download the bank statement”, so that a change in one place does not break ten bots.

3. Bots: attended vs unattended (how the bot runs)

This is the most important design choice in RPA:

Attended bots run on an employee’s own computer, while they are logged in, and are usually started by that person. Think of a customer-service agent who presses a button and the bot fills in five screens of a claim while the customer is still on the phone. Microsoft describes attended automation as suited to work that “might require human interaction or decisions between steps” (Microsoft Learn).
Unattended bots run on their own on a dedicated machine or virtual server, often overnight, started by a schedule or another system. UiPath describes them as robots that “don’t require human supervision to execute jobs”, intended for repetitive tasks “usually needing to be performed in batches” (UiPath documentation).

Most companies use both: attended bots to help people at their desks, unattended bots for the back-office batch work nobody wants to do.

4. The orchestrator (the control room)

The orchestrator is the central web console that deploys bots, schedules them, spreads the work across machines, stores credentials, and keeps logs of every run. In UiPath’s own words, it is “the central hub for unattended automation” (UiPath documentation). Without an orchestrator you have a few scripts on a few laptops. With one, you have something IT can audit.

5. Triggers (when the bot starts)

A trigger is what starts a bot. Common triggers are:

a schedule (every weekday at 6:00);
an event (a new file lands in a folder, a new email arrives in a mailbox);
a queue (a new item is added to a work list);
a person (an employee presses “run” in an attended bot).

6. Selectors: UI automation vs API automation (how the bot “sees”)

When a bot clicks a button, it has to find that button on the screen. It does this with a selector: a description of the element, such as “the button labelled Save inside the window Supplier invoice”. This is UI automation: the bot works the screen like a person would.

The alternative is API automation: instead of clicking through screens, the bot talks directly to the system through its programming interface (API). API automation is faster and far more stable, because an API does not move when someone redesigns a screen. The rule of thumb is simple: use an API when the system has one, and use UI automation only when it doesn’t, which is often the case with old ERP screens, terminal applications or government portals.

If all your systems are modern cloud tools with good APIs, you may not need RPA at all. Connecting them is the job of API-based workflow automation tools such as n8n (our preference), Make or Zapier, which are a separate category.

7. Integrations: ERP, CRM, email and Excel

In practice, RPA bots spend their day in four places:

ERP (SAP, Oracle, Microsoft Dynamics, or a local accounting system): posting invoices, creating orders, updating master data.
CRM: creating and updating customer records, copying data between the CRM and other systems.
Email: reading a mailbox, saving attachments, sending standard replies and notifications.
Excel and files: reading and writing spreadsheets, CSV exports and PDFs with a fixed layout.

Key RPA concepts: a short glossary

Term	What it means in plain words
Bot (robot)	The software worker that runs a workflow.
Workflow / process	The step-by-step procedure the bot follows.
Recorder	A tool that records a person’s clicks to create a first draft of a workflow.
Designer / studio	The visual editor where workflows are built and tested.
Attended bot	Runs on an employee’s computer, started by them, works alongside them.
Unattended bot	Runs on its own on a server or virtual machine, started by a schedule or event.
Orchestrator / control room	The central console that deploys, schedules, monitors and logs bots.
Trigger	The event that starts a bot: a schedule, a new file, a new email, a queue item.
Queue	A list of work items (for example, 500 invoices) that bots pick up one by one.
Selector	The “address” a bot uses to find a button or field on a screen.
UI automation	The bot works through the screen, like a person.
API automation	The bot talks to a system directly through its interface for software.
Exception	A case the rules don’t cover. The bot stops and hands it to a person.
IDP (intelligent document processing)	AI that reads documents such as invoices and turns them into structured data a bot can use.
Process mining / task mining	Tools that analyse system logs or desktop activity to find which processes are worth automating.
Hyperautomation	Gartner’s term for combining RPA with other tools (low-code, process mining, AI) to automate more end to end.

The benefits of RPA

When it fits, RPA delivers four things a CEO can see:

Time back. Your people stop copying data between screens.
Fewer errors. A bot does not mistype an IBAN at 5 p.m. on a Friday.
Speed and hours. Unattended bots work overnight and at weekends, so the work is done when the team arrives.
No system replacement. RPA works on top of the systems you already have. You don’t have to replace a twenty-year-old ERP to stop re-keying data into it.

RPA is still a large and growing market. According to Gartner, quoted in UiPath’s announcement of the 2025 Magic Quadrant for RPA, the RPA market generated $3.8 billion in revenue in 2024, an 18% increase on the year before. In the same passage, Gartner notes that “AI innovations have introduced alternatives to traditional deterministic RPA technologies”. Keep that sentence in mind for the section on AI agents below.

Gartner’s earlier description of why companies buy RPA is still the best one-line summary: organisations use it for “linking their legacy nightmares to their digital dreams” (Gartner, August 2022).

RPA use cases: where it works in real companies

Typical places where RPA earns its keep (illustrations of common patterns, not case studies):

Finance: accounts payable (AP). A bot downloads supplier invoices from a mailbox or portal, passes them through document recognition, matches each one to the purchase order and goods receipt in the ERP, and posts the ones that match. Mismatches go to a person.
Finance: accounts receivable (AR). A bot reads the daily bank statement, matches incoming payments to open invoices, marks them as paid and sends standard payment reminders for overdue ones.
Reconciliation. Comparing two lists that should agree, such as bank vs ledger, intercompany balances or stock in the warehouse system vs the ERP, and producing a report of the differences. This is classic, rule-based RPA work.
HR onboarding. When a new hire is approved, a bot creates the employee record in the HR system, requests accounts and equipment from IT, enrols the person in payroll and sends the welcome pack. The same bot can run the process in reverse when someone leaves.
Customer-service back office. The customer talks to a person or a chatbot; behind the scenes, a bot changes the address in three systems, issues the refund, cancels the order or updates the contract, so the agent on the phone does not have to switch between screens.
Insurance claims. A bot registers a new claim from a form, checks the policy is active, pulls the customer’s history, and routes simple claims for fast payment and complex ones to a claims handler. If you run a brokerage, see also AI agents for insurance brokers.

The limits of RPA: where it breaks

RPA is honest technology: it does exactly what it was told. That creates three problems that every RPA team learns about, usually in the first year.

Brittleness when screens change. Because most bots work through the user interface, a renamed button, a new pop-up, a software update or a slower network can break a bot overnight. Good selectors and API connections reduce this risk; they do not remove it.
Unstructured data. Bots are excellent with fixed fields and fixed layouts. They struggle with free-text emails, invoices in a hundred different formats, scanned handwriting, or a customer who writes “same as last month but double the second item”. Document-recognition (IDP) add-ons help, but anything that needs interpretation is outside classic RPA.
Maintenance. Each bot is a small piece of software that needs an owner, monitoring, test cases and updates whenever the underlying systems change. Companies that budget for building bots, but not for keeping them alive, end up with a “bot graveyard”. Count maintenance as a running cost from day one.

There is a fourth, quieter limit: RPA automates the process you have, not the process you should have. If the procedure itself is wasteful, a bot just makes the waste faster. Fix the process first, then automate it.

RPA vs AI agents: what is actually different

Here is the short version. An RPA bot follows rules on a screen. An AI agent reasons about a goal and uses tools. If you want the longer explanation of the second, see our guide on what an AI agent is.

An AI agent is software built on a large language model that can read messy inputs (an email, a contract, a phone call), decide what to do within limits you set, and then act through tools: an API, a database query, a document, or another system. Instead of “click here, then type there”, you give it a job description, rules and access, and it works out the steps. (For the broader picture of agentic AI and how it relates to automation in general, see our separate guide. This section stays specific to RPA.)

Four differences matter in practice:

Rules vs judgement. An RPA bot needs every case written down in advance. An agent can handle the case nobody wrote down: it reads the email, understands that “the usual” means last month’s order, and prepares the order, then asks a person to approve it.
Structured vs messy inputs. RPA wants fixed fields and fixed layouts. Agents are built for the messy middle: free-text emails, PDFs in every format, notes, chat messages.
Deterministic vs probabilistic. Given the same input, an RPA bot does exactly the same thing every time. An agent’s output is probabilistic: usually right, sometimes wrong in new ways. That is why agents need guardrails, test cases and a person approving anything with consequences, and why RPA remains the better choice where you need a guaranteed, auditable, identical result.
Screen-level clicking vs tool reasoning. RPA works mostly at the level of the screen: selectors, buttons, fields. An agent works at the level of tools and intent: it calls an API, searches a knowledge base, or writes a record, and chooses which one to use. When a screen changes, a UI bot breaks; an agent using an API usually does not notice.

	RPA bot	AI agent
Works from	A fixed script of steps	A goal, rules and a set of tools
Best input	Structured: fixed fields, fixed layouts	Unstructured: emails, documents, conversations
Decisions	Only the ones written into the rules	Judgement within limits you set
Behaviour	Deterministic: same input, same output	Probabilistic: needs guardrails and testing
How it touches systems	Mostly through the screen (UI), sometimes APIs	Mostly through APIs and tools
When something new happens	Stops and raises an exception	Tries to handle it, or escalates to a person
Typical failure	Breaks when a screen changes	Gets a judgement call wrong
Maintenance	Fixing selectors and scripts after system changes	Updating knowledge, rules and test cases
Ideal job	High-volume, stable, rule-based work on legacy systems	Variable work that needs reading, deciding and writing

When to combine them: the agent decides, RPA executes

The best answer is often both. The vendors agree: the large RPA platforms now sell “agentic automation”, which layers AI agents on top of existing bots instead of replacing them. UiPath, for example, now calls itself “a global leader in agentic automation” (UiPath, July 2025).

The pattern looks like this:

The agent reads and decides. A supplier sends an email with a changed delivery date and a new price, in a format you have never seen. The agent reads it, checks it against the contract in your company knowledge base, and decides what should change.
The agent acts with approval on anything with consequences. That is one of the three written autonomy levels every agent of ours has: a person approves each change before it goes through, and every action is logged.
The RPA bot executes on the legacy system. Your ERP is twenty years old and has no API, so the agent hands the bot a clean, structured instruction (“update order 4711: date, price”), and the bot types it into the old screens, exactly and with a full log.

This plays to each side’s strength: the agent handles the messiness, the bot handles the precision and the systems nobody wants to touch. Gartner’s advice says much the same thing: use “AI agents when decisions are needed, automation for routine workflows and assistants for simple retrieval” (Gartner, June 2025).

A word of caution in the other direction. In the same release, Gartner warns about “agent washing”, the rebranding of existing products, explicitly including RPA, as agents without real agentic capability. It also predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. A bot with a chat window is not an agent. Our research on who sells AI agents that stick separates the real vendors from the relabelled ones, and our post on why AI agent projects fail covers how to avoid the same fate. That post looks at something different from Gartner’s forecast: not how many projects, most of them still experiments or proofs of concept, will be canceled, but the four preventable patterns behind deployed agents that fail to show a measurable return.

How to choose: RPA, an AI agent, or both?

Ask four questions about the process you want to automate:

Are the inputs structured? Fixed fields, fixed layouts, the same every time → RPA. Free text, many formats, conversations → an agent, or AI document processing in front of a bot.
Are the rules complete? If you can write down every case on two pages → RPA. If the honest answer is “it depends” → an agent, with a person approving.
Do the systems have APIs? Yes → use the API directly, through workflow automation or an agent. No, only screens → RPA is often the only practical way in.
What happens if it is wrong? If a mistake is costly and the work must be identical every time, use deterministic RPA, or put an agent’s decision behind human approval before a bot executes it.

When choosing an RPA vendor, compare them neutrally on the same points: how well they handle your specific systems (especially old ones), API and document-recognition options, attended and unattended licensing, the orchestrator’s logging and access controls, the cost of maintenance, and whether your IT team or partner already knows the platform. UiPath, Automation Anywhere, Microsoft Power Automate and SS&C Blue Prism all cover the basics. If you already use Microsoft 365, Power Automate is often the easiest place to test; larger, regulated companies often look first at the enterprise platforms. Run a proof of concept on one of your processes before you sign anything.

It also helps to place the work on our 3 organisational levels (the three-tier AI workforce model). RPA overlaps with the Task level (high volume, every result right or wrong), where Task agents handle the data that breaks bots, such as free-text emails and invoices in a hundred formats. Operational agents make the judgement calls, like the supplier email above, where work touches several systems and changes from case to case. The Executive level rarely touches RPA. Across the three levels we build a fleet of AI employees, not a single agent, and your existing bots become tools that fleet hands precise work to. How RPA, digital transformation and AI agents fit together at company level is covered in AI transformation vs digital transformation.

First steps: a practical way to start

List the candidates. Ask each team: “What do you copy from one screen to another every week?” Write down the process, volume, systems involved and how often the rules change.
Pick one boring, high-volume, stable process. Not the most impressive one, the most annoying one. Invoice entry, bank reconciliation and onboarding paperwork are common first choices.
Fix and document the process before you automate it. Write the procedure down, remove the steps nobody needs, and define what counts as an exception.
Measure the baseline. Hours per week, error rate, turnaround time. Without a “before”, you can’t prove an “after”.
Prefer APIs, use the screen only where you must. Every UI step you replace with an API call is one less thing to break.
Decide who owns the bot. Name one person responsible for monitoring, exceptions and changes. Budget for maintenance from day one. For AI agents, see who decides: the CEO or the CIO.
Add an agent only where the process needs judgement. If the bot keeps stopping on messy emails or unusual documents, that is the point where an AI agent in front of the bot pays off.
Run it for a few weeks, compare and decide. Keep, adjust or stop, and only then choose the next process.

When an agent is part of the answer, we build it with our 5-phase method (Discover, Design, Build, Deploy, Optimize): a signed one-page spec before any building starts, and an eval suite the agent must pass before it goes live.

Not sure whether your company is ready for bots, agents or both? Try our free AI Readiness Scorecard (two minutes, ten questions) or put your own numbers into the ROI calculator. If you want to start with one Task agent, such as one that pulls invoice data out of emailed PDFs, our Spark package builds it with one standard connection (Gmail, Slack, Google Workspace or HubSpot). Hand-offs to legacy systems or existing RPA bots are a custom integration, which we scope and quote separately. Workforce Starter builds three agents, one per level, and Workforce Pro builds five agents for one department. Agents need clean company knowledge to decide well, which is why our research on the agent-readable second brain is worth reading before you start.

If you run a company in one of our core markets, our country guides show what this looks like locally: Greece, Italy, France and Germany.

FAQ

What is robotic process automation (RPA) in simple terms?

RPA is software that copies the clicks and keystrokes a person makes on a computer, so a bot can repeat a rule-based task, such as copying invoice data into an ERP, quickly and without typing errors.

Is RPA the same as AI?

No. Classic RPA follows fixed rules and does not learn or interpret. Modern RPA platforms add AI features, such as document recognition and AI agents, but the bot itself is deterministic: the same input always produces the same action.

What is the difference between attended and unattended bots?

An attended bot runs on an employee's computer, is started by that person and works alongside them. An unattended bot runs on its own on a server or virtual machine, started by a schedule or an event, usually for batch work in the back office.

Will AI agents replace RPA?

Not entirely. Agents are better at messy inputs and judgement; RPA is better at precise, repeatable work on systems with no API. The most practical setups combine them: the agent reads and decides, a person approves, and the bot executes on the legacy system.

Do I need RPA if my systems have APIs?

Often not. If your tools are modern and have APIs, API-based workflow automation or an AI agent can connect them directly, which is faster and less fragile than clicking through screens.

What are the biggest risks of RPA?

Bots breaking when screens change, bots struggling with unstructured data, and maintenance costs that nobody budgeted for. Choosing stable processes, using APIs where possible and naming an owner for every bot reduces all three.

Which RPA vendor should I choose?

There is no single best one. UiPath, Automation Anywhere, Microsoft Power Automate and SS&C Blue Prism all cover the core features. Compare them on your own systems, licensing, logging, maintenance and the skills you already have, and test on one real process before committing.

From the House of 47 group

theagency47 is part of House of 47, alongside search47, which helps companies get found in Google and in AI answers such as ChatGPT, and pixel47, a web design and development studio that builds the fast, conversion-focused sites your agents and customers meet first. More analysis on AI, agents and automation is on House of 47 Research, including Are CEOs ready for AI agents? and the collapsing cost of intelligence.

Written by Christos Papadimitriou, founder of theagency47.