Robotic Process Automation (RPA) automates repetitive, rule-based work across the systems people use every day. With a coding agent, you describe the work in plain language and it produces a runnable workflow. Your part is to describe it well and review what comes back.

RPA suits well-defined, deterministic work, especially where systems have no usable API:

When the work needs judgment rather than fixed rules, an agent, or a mix of both, may fit better. See Agents. When a workflow is one step in a longer process that spans approvals, systems, and time, a Maestro Flow can orchestrate it alongside people and other automations.

For worked, end-to-end examples, see the RPA recipes.

Building a new workflow is only the starting point. The same coding agent works across the whole life of an automation, so common requests include:

You drive all of this in conversation, and the agent picks the right UiPath capability for each request behind the scenes.

The agent builds what you describe, so the brief matters as much as it would for a colleague:

The general guidance in Working effectively applies here too; the points above are what matter most for RPA. An existing process document is a strong starting point, as long as real customer data is removed first.

A UiPath RPA workflow can be built as a low-code workflow or as a coded one, and you guide which:

Both can also be mixed in one project. Choosing the shape up front, rather than mid-build, avoids a restructure later; without direction, the agent defaults to low-code.

The hardest and most valuable RPA work is driving an application's interface the way a person would, by clicking, typing, reading values, and moving through screens, for systems that offer no API. UiPath's UI Automation is what makes this reliable, and a coding agent uses it directly.

Rather than guessing how to find each element, the agent explores the application at design time: it captures the screen, identifies the elements to act on, and builds the steps to navigate and fill them. This is multi-modal by design, because for desktop applications the underlying page structure is not enough on its own. Elements can be off-screen, scrolled out of view, or hidden behind a popup.

Captured elements are stored as stable targets in an Object Repository, so the same button or field can be reused across workflows and maintained in one place. This is what separates dependable UI automation from brittle, coordinate-based screen scraping.

Interfaces change, and UI Automation is built to absorb that:

If the target application is not available to capture against, the agent still produces the real workflow, leaving each interaction marked for a developer to finish the capture in Studio. Generated selectors are best treated as drafts either way, and confirmed against the real application.

UI automation is also the most expensive kind of RPA to build. It takes more time and effort than file, data, or API work, so an API is the better path wherever one exists, and time and effort are worth budgeting for.

RPA projects have house rules worth stating once in a context file, rather than repeating them every session. Common examples:

Coding agents are strong at greenfield, well-structured RPA and at the first version of a workflow. They are weaker, and need closer review, on:

For what to check before accepting a workflow, see Reviewing and validating output.

For the full picture of building automations with Studio and activities, see the Studio documentation and the Activities documentation.