A local runtime for email- and query-driven RPA — where Python owns the logic and RPA tools own the screen.
Robot Runtime is a local Python runtime for small-scale RPA deployments. The term “runtime” refers to everything except the UI automation: job intake, orchestration, decision logic, logging, and result verification. UI automation is delegated to an external RPA tool such as UiPath or Power Automate. Together, the runtime and the RPA tool form the robot.
This project is designed as a simple way to get started with RPA in a business unit. It runs on a single machine as a single Python file. The principle is: UI interaction → handled by the RPA tool. The rest (logic and orchestration) → this Python runtime
Unlike traditional RPA setups — where users manually trigger predefined automations — this runtime is event-driven. It continuously listens for incoming work (emails or queries), interprets the request, decides what action to take, and executes via an RPA tool.
The runtime supports two types of job sources: emails and queries.
A user sends an email → Python validates and prepares the job → writes to handover.json → RPA executes UI actions → Python verifies and responds.
Python polls a data source → detects a valid case → prepares a payload → signals RPA → RPA executes → Python verifies the outcome.
This project separates responsibilities between the runtime and the RPA tool:
-
The runtime (this project) handles:
- job intake (email / queries)
- access control and validation
- decision logic
- preparing payloads and handover
- verification and failure handling
-
The RPA tool handles:
- UI automation (clicks, keyboard input, ERP interaction)
They communicate through a file-based IPC mechanism (handover.json).
The diagram shows:
- How the Runtime and the RPA tool run independently
- How your RPA tool should be implemented
- Email-driven job processing (personal inbox)
- Shared inbox support (partially implemented)
- Query-driven jobs (ERP/data polling)
- SQLite audit-style logging (
job_audit.db) - Crash-safe mode (
safestop) - Built-in screen recording (ffmpeg)
- Final user replies after verification (DONE / FAIL)
- Screen-recording link included in final reply
- Runs without administrator rights
- Single-file runtime (
main.py) for easy sharing and inspection - Windows or Linux, with environment-specific setup
- Python 3.14
openpyxlffmpeg(optional, for screen recording)
python main.pyUse included dev tools:
fake_jobs_generator.pyrpa_tool_simulator.py
- Small internal automation (5–10 users)
- No dedicated RPA infrastructure
- No admin rights required
- Cheap “extra laptop” deployment
- Pilot / proof-of-concept automation
You can — but it tends to lead to:
- Business logic spread across visual workflows
- Difficult testing and debugging
- Fragile automations that break on small UI changes
In this project the RPA tool is used for what it does best: UI interactions (clicks, keyboard input, screen automation). These tools include Microsoft Power Automate, UiPath Studio, Blue Prism, Robot Framework, TagUI, RPA for Python
Python is great for logic and data processing, but:
- It cannot reliably interact with arbitrary GUIs
- Many business systems (ERP, legacy apps) require UI automation
This project leverages the simplicity and rich ecosystem of Python for logic, while relying on RPA tools for reliable UI automation.
Enterprise orchestrators (e.g. UiPath Orchestrator, Control Room, orchestrator_rpa, openorchestrator
- Require infrastructure, setup, and licensing
- Are designed for large-scale, multi-bot environments
This project intentionally avoids that scope and runs on a single machine with simple file- and DB-based state. If you need distributed execution, queues, or centralized control — this project is the wrong tool.
- a dedicated machine or “extra laptop”
- a mailbox such as rpa@yourcompany.com
- an external RPA tool
- environment-specific setup for mail backend, ERP/query backend, job handlers, recording path, operating hours, and network health check
MIT (recommended)
Early-stage / experimental, but functional.