Recommended approaches for adopting ScreenPlay in new or existing UI Automation workflows, and practices for keeping them fast and economical at scale.

Recommended approaches for adopting ScreenPlay, whether you are integrating it into existing UI Automation workflows or building new agent-driven automations, and for keeping those automations fast and economical once they run at scale.

ScreenPlay is designed to excel at specific, high-friction points, also known as Controlled agency scenarios, representing small, critical areas of automation where traditional tools are most fragile. Rather than replacing entire workflows, ScreenPlay brings agentic execution to the parts that need it most:

The corollary matters just as much. In unattended automation, you have to trust a run you are not watching, and the deterministic parts of a workflow are the only parts that behave identically every single time. They are also the fastest and cheapest to execute, which is what makes them viable across thousands of runs.

The goal is a maximally deterministic, minimally agentic workflow: classic UI Automation wherever the interface is stable and the steps are known, and ScreenPlay where agentic execution is the only way to reliably meet the business need.

The following paths are available, depending on your context.

You can use ScreenPlay activities to fix the problematic steps of your current UI Automation, such as:

You can define the actions you use through natural language prompts instead of brittle selectors, or long, custom logic. This helps simplify development, and also make your automation more resilient over time.

If you start a UI Automation from scratch, you can build it entirely using ScreenPlay with granularity.

Each ScreenPlay activity should correspond to a small, well-scoped step in your process, ideally two or three steps that naturally belong together.

This granular approach has the following benefits:

Depending on the complexity of each step, you can choose the appropriate AI model, balancing cost-efficiency and capability.

You can also build the automation with an AI coding agent using the UiPath Agent Skills, which teach the agent how to author, run, test, and deploy UiPath automations from your development environment. For the catalog and installation instructions, see the UiPath Agent Skills repository.

The authoring skills focus on generating RPA, so what the coding agent produces is deterministic by default, which is the baseline you want. The recommended approach is to review the generated workflow and add ScreenPlay activities at the points where the agentic approach is required.

Those additions should stay deliberate and few. Each one is a place where behavior stops being guaranteed, and where execution time and token consumption increase.

An automation that runs a handful of times a day and one that runs thousands of times have very different economics. The following practices reduce latency and token consumption without giving up reliability.

This is the highest-impact decision, and it is made at design time rather than tuned afterwards. Every step that can be expressed deterministically is a step that costs no model call, adds no latency, and cannot vary between runs.

The deterministic baseline comes first, with agentic steps added only where they earn their place.

The models available in the Model drop-down keep getting faster and more capable at the same time, so speed and quality are much less of a trade-off than they used to be.

Because each ScreenPlay activity carries its own model selection, you can match the model to the difficulty of the step: a fast Basic tier model for routine interactions, a Standard tier model for the steps that genuinely need more reasoning. For the full list of available models, see ScreenPlay.

If your automation was built against an older model, revisiting the selection is one of the cheapest speed improvements available.

The ScreenPlay agentic harness can execute several actions on the same screen in a single batch, rather than one action per model call. Fewer model round-trips means lower end-to-end latency, and the difference is most visible on action-dense screens such as long forms.

This is not the default behavior. By default, the harness performs one action at a time, and batching happens only when the task prompt asks for it explicitly. The harness honors these indications when the actions target the same screen.

For example, instead of:

use:

Batching applies only to actions that can be performed on the currently visible screen. Steps that require navigation, a page transition, or a change of application are still executed sequentially, because the model needs to observe the new screen before deciding what to do next.

Optimizing purely for execution time and token consumption can push you toward deterministic implementations that are brittle and expensive to keep alive. A selector-heavy workflow that breaks with every minor UI change can cost more over its lifetime than the tokens it saved.

Healing Agent narrows that gap, but it does not close it. Its recovery strategies are a defined and limited set, and they all work at the level of re-identifying a target element for an activity that already exists:

Healing Agent also applies AI-based strategies for:

That covers a large share of everyday UI drift, but it cannot absorb changes in the interaction itself, such as a new confirmation dialog, a reordered set of screens, a field that moves to another step, or a flow that now requires a different sequence of actions.

Enabling Healing Agent is not a substitute for designing the workflow well, and it does not keep a fragile deterministic implementation alive indefinitely.

For the parts of an application where you expect that kind of change, ScreenPlay is the better answer. Describing the outcome in natural language and letting the agent work out the interaction at runtime removes the maintenance burden for those steps, at the cost of the model call. Deciding which steps deserve that treatment is worth revisiting as the target applications evolve.