Bot runner

What is a bot runner?

A bot runner is the runtime that executes a configured automation. In RPA it is usually software on a machine or virtual desktop that starts a flow under a specific identity and session.

The runner is not the process definition. The flow describes the steps, the orchestrator and queues decide when and where those steps run, and the runner provides the environment they run in.

Vendors use the word differently. Automation Anywhere calls the run-time device a Bot Runner and separates it from the Bot Creator used to build bots, both managed from a central Control Room. Power Automate talks about machines and machine groups that run desktop flows. UiPath calls the execution agent a Robot. Write down what runner means for your platform: a licence, a machine agent, a session, or a running process.

Machine, runtime, and session

The machine supplies the operating system, the applications, the network, and the resources. A runtime agent connects that machine to the automation platform and reports whether it is online and available.

UI automation runs inside a user session with its own screen resolution, language, profile, and permissions. That context changes how selectors resolve, where files land, and how applications behave, so a flow that works in one session can fail in another.

A single machine supports one or more concurrent runs depending on the platform and licence. Adding CPU does not automatically create extra interactive sessions.

Attended and unattended runners

An attended runner works inside the active session of an employee and is started or supervised by that person. The automation can take over the mouse and keyboard, so the desk is occupied while it runs. This suits short tasks that sit next to human work.

An unattended runner starts without anyone present, in a managed session on a dedicated or virtual machine. It needs a service identity, a machine that is available at the scheduled time, and a licence and security model that allow lights-out running.

Do not treat unattended running as a place to park personal credentials forever. Give the runner its own identity, make ownership explicit, and rotate its secrets on a schedule.

From queue to execution

An orchestrator picks a suitable runner based on availability, machine group, priority, and any requirements the flow declares. When no runner is free the run waits in a queue rather than failing.

The chosen runner pulls its configuration, opens the applications it needs, and processes one or more items from a work queue. Heartbeats and run events show whether it stays connected and active. When it finishes, status and logs travel back, and local temporary files and session data should be cleaned up on purpose.

Design flows to be idempotent and recoverable, because a runner can crash after the target system has already booked a transaction but before the success status was saved. On the next attempt the flow should check what already happened instead of blindly repeating it.

Capacity and scaling

Capacity comes from the concurrency you allow, the average run time, the window each runner is available, and how often runs fail and retry. A runner that is available for eight hours a day cannot absorb an unlimited peak, and short flows can spend a lot of that time just starting sessions.

Work out throughput per hour and leave room for retries and maintenance before you add runners. Scaling only helps once you know where the real limit is. A slow source system or a single shared login can make extra runners useless.

Bot runner versus digital worker

A bot runner is a technical unit of runtime. A digital worker is a broader, organisational idea: a bundle of automations that carries out a defined package of work, often described as if it were a colleague.

One digital worker can use several flows, API integrations, and runners at once. One runner can host different processes at different times. Keep the two apart when you plan capacity and assign responsibility, so a marketing label never hides the real technical dependencies.

What to watch out for with a bot runner

An online machine is not the same as a ready one. Monitor connection, agent version, disk space, session state, and application versions rather than only whether the box is powered on. Use health checks and a maintenance mode so a runner stops claiming new work while it is being patched or investigated.

Give runtime identities only the rights the process needs, keep secrets in supported storage rather than in flow variables, and restrict local admin rights and network access. Logs, screenshots, and working files can hold personal data, so encrypt storage, set retention, and remove local leftovers.