AI agents vs RPA

What a bot actually does

Start with the architecture, because the comparison of AI agents vs RPA is settled by it. UiPath, the largest RPA vendor, describes its software robots as "mimicking human actions in interacting with screens and systems" to handle "repetitive, rule-based tasks like entering data, moving files, or processing transactions". Microsoft's desktop flows, its RPA product inside Power Automate, say the same thing in mechanical terms: you can "interact with the machine by using application UI elements, images, or coordinates", against "legacy applications, such as terminal emulators, modern web and desktop applications, Excel files, and folders". A bot can run attended, alongside a person at the desk, or unattended, on a machine of its own.

Take a concrete task: booking a goods receipt into an older stock system that has no API. The bot opens the application, moves through the menu to the receipts form, searches for the purchase order, tabs into the quantity field for each line, types the number, and presses the Save key. A person recorded those steps once; the bot replays them thousands of times, faster and without transposing digits. For a stable application with high volume and no other way in, that is a good trade, and it has paid for itself in many finance and operations teams.

The vendors say where it fits, and they are right. UiPath's own framing is "high-volume, repetitive, rule-based tasks, especially those that span multiple systems": volume, determinism, and reach into systems that offer nothing else. An honest comparison keeps those on the table.

Why it breaks, and why that is not a defect

A screen is a contract with a person. Its layout, labels, tab order and the position of the Save button are promises made to eyes and a pointer, and none of them is promised to a machine. When the vendor moves the quantity field into a new tab, adds a confirmation pop-up, or renames a menu, the person adapts in seconds without noticing. The bot fails, or worse, types the quantity into the wrong field and saves. That failure says nothing about the RPA vendor's competence; the interface the bot was given is showing through.

The same limitation follows a language model when it is made to drive screens. Anthropic's computer use gives Claude "screenshot, mouse, and keyboard control of a desktop environment", and it is genuinely useful where nothing else exists. But Anthropic's own documentation steers you away from it wherever a tighter interface is available, recommending its browser tool for work that stays inside a web page, and asks for "a human to confirm decisions that might result in meaningful real-world consequences", naming financial transactions among them. A model driving a screen inherits the screen's brittleness and adds its own variability on top. That is the least attractive combination of the two categories, and it is what many "AI-powered RPA" pitches amount to.

What an agent calls instead

An agent that operates a business system built for agents never sees a screen. It asks the system what it may do and receives a list of tools, each with a name, a description written for the model, a schema for its inputs, and optional annotations that say whether it only reads, whether it can destroy data, and whether calling it twice is safe. The Model Context Protocol standardises this exchange: the client sends a request to list tools, the model chooses one, the client calls it with typed arguments, and the server runs it and returns a result. The specification requires servers to "validate all tool inputs" and "implement proper access controls", and tells clients to "log tool usage for audit purposes". Here is the shape of one such tool, using the goods receipt from earlier.

{
  "name": "receiveStock",
  "description": "Book goods received against a purchase order into a warehouse location. Fails if the order is closed or the caller cannot receive at that location.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_ref": { "type": "string", "description": "Purchase order reference" },
      "location_id": { "type": "string", "description": "Warehouse location to receive into" },
      "lines": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "sku": { "type": "string" },
            "quantity": { "type": "integer", "minimum": 1 }
          },
          "required": ["sku", "quantity"]
        }
      }
    },
    "required": ["order_ref", "lines"]
  },
  "annotations": { "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false }
}

An MCP tool definition in the shape the specification describes, for the same goods receipt the bot was typing into a form. The field names are illustrative; the point is that a tool is a contract, and a contract can be versioned, validated and permissioned in ways a screen cannot.

Compare what happens on change. The vendor redesigns the receipts screen: the bot breaks, the tool is untouched. The vendor adds a required field to the tool: that is a versioned change to a published contract, announced in the tool list, and the agent reads the new schema on its next call. Compare identity. The bot logs in as a service account with whatever access someone gave it years ago. The agent calls the tool as the person it represents, and the permission check runs inside the tool, on every call, against that person's role.

Deterministic versus probabilistic: the trade nobody should hide

There is a cost on the agent side, and the RPA vendors state it accurately in their own agent documentation: robots "follow structured logic and fixed rules", while agents take "a probabilistic approach to make decisions based on patterns and real-time data". A bot that replays the same steps gives the same result for the same input, and can be proven to. An agent given the same intent takes a defensible path, usually the same one, not always. For a regulated step where repeatability must be demonstrated, or for a million identical transactions a month, the deterministic option is the better choice, and saying otherwise would be selling.

The agent's advantage is confined to variation. When the receipt does not match the order, when the supplier has sent two deliveries against one line, when the quantity is plausible but the unit is wrong, the bot has no branch for it and stops, or does the wrong thing confidently. The agent reads the discrepancy, checks the order, books what matches, and asks a person about the rest. That is the work that used to be a queue of exceptions on someone's desk, and it is the work an agent is for.

Reach for RPA when, reach for an agent when

Using both, and what the system underneath decides

The pattern the vendors now describe, and the one that works in practice, is that the agent decides and the bot executes on systems that have nothing else. UiPath puts it as robots playing "a complementary role in the execution stack" alongside agents. In that arrangement the bot is one of the agent's tools: a wrapped, deterministic action against a legacy screen, with the agent responsible for choosing when to call it and for handling whatever the bot returns. Over time the bots retire one by one as the systems behind them gain tools of their own, and nothing on the agent side has to change when they do.

Which brings the decision back to the business system. Sois is built so that the bot is never needed against it: a workspace is an MCP server, every action a person can take is exposed as a named tool, and the agent you already use, Claude, ChatGPT or any MCP client, connects by adding the workspace address and signing in once. Tools are filtered by the person's role before the agent sees them and checked again when they run, so access fails closed; spend is capped per integration; every call is logged with its inputs and its result. Where you still run a legacy system beside it, the bot stays on that system and the agent treats it as one more tool.

If your core system only has screens, RPA is the bridge and there is no shame in it. The decision that matters is whether the next system you buy will need one.

Questions people ask

This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.