Agent-to-agent vs RPA: driving the screen or asking the agent

RPA (robotic process automation) is for automating repetitive work in applications that offer no suitable API, by having a software robot operate the user interface the way a person would. Agent-to-agent communication, as defined by the A2A (Agent2Agent) protocol, is for letting one agent hand a task directly to another organization’s agent and track it to an outcome, with no screen in between.

RPA automates the person at the keyboard. A2A lets the system on the other side speak for itself. When the other side is a business that publishes an agent, the second route replaces a fragile screen-driving script with a request the business designed to accept.

Status as of September 26, 2026. RPA is a product category, not a protocol. Each vendor defines its own tools, such as Microsoft Power Automate desktop flows or UiPath robots with selectors. RPA vendors are also adding agent protocols: UiPath Orchestrator documents A2A agents, currently in preview. A2A is a Linux Foundation project at protocol version 1.0; its latest release, v1.0.1, shipped on May 28, 2026.

What RPA is for

RPA tools record or script the steps a person takes in an application, then replay them. Microsoft describes Power Automate desktop flows as automating repetitive desktop processes, built with a drag-and-drop designer or by recording actions. They can drive legacy and modern desktop and web applications by interacting with UI elements, images or screen coordinates. Flows can run attended, on a machine where a user is signed in, or unattended, where Power Automate signs into the machine, runs the flow and signs out.

To find the right field or button, the robot needs a way to identify it. UiPath uses selectors: XML fragments that store attributes of a UI element and its parent elements. UiPath’s documentation notes that when an attribute’s value changes each time an application starts, a selector may fail to find the element. That is the core trade-off of RPA. It works without anyone changing the target application, and it depends on that application’s screens staying the same.

RPA fits work inside an organization: moving data between an old ERP screen and a spreadsheet, keying invoices into a system with no import, or reconciling records across tools that were never integrated.

What agent-to-agent is for

A2A assumes the other side is an agent that wants to be called. It publishes an Agent Card, usually at /.well-known/agent-card.json, with its skills, endpoints and required authentication. A client agent sends a message with text and data parts. The remote agent creates a task that can complete, fail, be refused, or pause for more input or for authorization, and it returns results as artifacts.

The remote agent is opaque. The client never sees its screens, APIs or internal steps, so the business can redesign its systems without breaking callers. Authentication is declared up front rather than scripted as a login sequence.

The same job both ways

Illustrative: a procurement team checks the status of a supplier’s invoice every morning.

With RPA, a robot runs this sequence against the supplier’s web portal:

1. Open https://portal.supplier.example/login
2. Type the stored username and password; handle the one-time code
3. Click "Invoices", then filter by invoice number INV-20931
4. Read the "Status" cell in the first row of the results table
5. Copy the value into the ERP's invoice record

If the supplier renames the “Status” column, adds a CAPTCHA, or moves the filter, the robot fails until someone fixes it.

With A2A, the buyer’s agent sends the supplier’s agent a message such as “What is the payment status of invoice INV-20931?” with the invoice number in a data part. The supplier’s agent authenticates the buyer through the scheme in its Agent Card, checks what that buyer may see, and returns an artifact with the status. The supplier can rebuild its portal without breaking the buyer.

Side by side

	RPA	Agent-to-agent (A2A)
Purpose	Automate work in applications by operating their user interface	Let one agent delegate a task to another and track it
Layer	Automation on top of an application’s screens	Open application protocol between agents
Who talks to whom	A robot and an application’s UI, acting as a user	A client agent and a remote agent at another organization
Transport	Whatever the UI uses: desktop windows, web pages	JSON-RPC 2.0, gRPC or HTTP+JSON; streaming and webhook push
Discovery	Scripted: URLs, window names and selectors set by the builder	Agent Card at /.well-known/agent-card.json, registries or direct configuration
Auth	The robot signs in with a user account, often a dedicated one	Security schemes declared in the Agent Card
State	The robot’s run; the application’s own session	Tasks with a lifecycle; contextId groups related work
Governance and status	Vendor products; no common standard	Linux Foundation project; version 1.0 (v1.0.1, May 28, 2026)

When to use each

Use RPA when the application is yours or a vendor’s, offers no API or agent, and changes rarely. It is often the fastest way to automate internal systems nobody will modify, and it needs no cooperation from the application’s owner.

Use agent-to-agent when the counterparty is another organization that publishes an agent. You get a supported contract, declared authentication, task states for follow-up questions, and a result you can store. You also stop impersonating a human user on a site that was built for people, where terms of use and bot defenses may be aimed at exactly that kind of traffic.

Using both

The two combine in both directions. An agent can call an RPA robot as one of its tools, to reach an internal system that has no API. And an RPA platform can orchestrate agents: UiPath’s Orchestrator documentation describes inbound A2A, where agents deployed on UiPath already speak A2A and have an Agent Card, and outbound A2A, where the platform calls external agents registered in its Agent Gateway with their card and credentials. That feature is marked as preview.

A practical migration path: list the portals your robots log into, check which counterparties now publish an Agent Card, and move those steps to A2A first. Keep RPA for the systems with no other way in.

Common misconceptions

“AI agents that use a browser are a new kind of RPA, so no protocol is needed.” A browsing agent can adapt to screen changes better than a fixed script. It still acts as a human user on a site built for humans, with the same identity and authorization gaps.

“A2A replaces RPA.” A2A needs an agent on the other side. Most internal and legacy systems do not have one, and RPA remains a practical way to automate them.

“RPA is safe because it only does what a user could do.” It does it with stored credentials, often at volume and without a person watching. Treat robot accounts like any other privileged service account.

“With A2A, the business decides everything and the caller loses control.” The caller chooses what to ask and can cancel a task. The business decides how to fulfil the request and what the caller may see, which is the same boundary a supported API or a customer service desk already draws.