RPA and Agents Do Not Compete with the Control Plane: They Run Beneath It
By Equipo Quantum Developers
Summarize:
Operating thesis
RPA and a control plane solve different problems. A robot can open an application, move data, and execute repeatable work. A control plane should answer which automations exist, who owns them, which object they affected, whether they are healthy, and what evidence they left. The conservative thesis is to retain RPA engines that execute well and add an independent layer that inventories, governs, and links their activity to business outcomes.
RPA orchestrators already provide meaningful control. UiPath Orchestrator’s job documentation describes a surface for launching and observing jobs, viewing states and logs, and stopping, resuming, or restarting work. An upper plane should not rebuild those functions. It should consume them and address the problem that emerges when several engines, scripts, agents, and teams coexist.
The architectural boundary
A clear architecture separates five layers:
- Systems of record. ERP, WMS, CRM, files, and services that own business state.
- Execution engines. Attended or unattended RPA, workflows, scripts, integrations, and agents.
- Adapters. Translate states and commands without hiding the engine’s identity.
- Control plane. Catalog, owner, policy, permissions, health, exceptions, cost, and evidence.
- Operating experience. Dashboards, review queues, approvals, and object timelines.
The boundary rule is simple: the engine decides how to execute; the plane decides whether execution is authorized, visible, and associated with an owner. The system of record keeps transactional truth. If the plane becomes a second ERP or tries to micromanage every robot click, the architecture becomes more fragile.
A comparison without a false replacement war
| Question | RPA orchestrator | Cross-engine control plane |
|---|---|---|
| How does a package run? | schedule, robot, machine, and queue | delegates to the engine |
| What happened to a job? | native state and logs | normalizes health and links the object |
| Who may execute? | product-level roles | policy across engines and domains |
| What automations exist? | engine inventory | complete portfolio inventory |
| Who owns the work? | account or folder, depending on product | outcome owner and on-call path |
| What evidence remains? | technical job log | decision, approval, action, and result |
| What value was produced? | engine use and capacity | outcome and cost across engines |
| How is it retired? | disable package or robot | close dependencies and portfolio cases |
Microsoft exposes a related problem through its Power Platform CoE Starter Kit: tenant-level inventory can show apps, flows, makers, and environments, identify orphaned resources, and support governance planning. This does not prove every enterprise needs the same product. It does show that inventory and ownership become a distinct function as adoption expands.
The adapter contract
Each engine can retain its vocabulary, while the adapter publishes a common envelope:
- automation_id, engine_id, and deployed version;
- run_id, business object, and requested operation;
- normalized state: pending, running, waiting, completed, failed, or canceled;
- engine timestamp and receipt timestamp;
- requesting identity and executing principal;
- applicable policy and approval;
- exception reason and native-log reference;
- attributable cost where available;
- later operating outcome.
OpenTelemetry maintains semantic conventions so traces, metrics, and logs can use common names across technologies. A control plane can apply the same discipline to business concepts without pretending every engine has identical states. Preserve both the original state and its translation.
Portfolio health, not availability alone
The cross-engine view combines four dimensions:
Execution: latency, error, queue, and availability reported by the engine.
Object: cases in uncertain, duplicate, or unresolved states.
Ownership: automations without an owner, on-call path, or review date.
Evidence: runs missing policy, approval, artifact, or outcome linkage.
A robot may report “completed” while the ERP rejects the record afterward. The plane should therefore not declare success from job state alone. Reconciliation with object state and outcome belongs in the contract.
Decisions that should remain local
The control plane does not need every screenshot or robot credential. Detailed logs remain in the engine and are reached by reference. Secrets remain in the approved store. Engine-specific retry timing can stay with the executor, provided attempts and state are published.
Availability should also be separated. If the plane is unavailable, a low-risk automation may continue under cached policy and buffer events for later delivery. A sensitive action may stop. Risk determines the mode; a universal synchronous dependency does not.
Artifact: the control-and-execution map
For every automation, draw six columns: object, policy, plane, adapter, engine, and system of record. Mark:
- where the request begins;
- who authorizes;
- which identity executes;
- where state is observed;
- which event confirms the result;
- who receives the exception;
- how execution is paused and retired.
The map exposes duplication. If two layers believe they own retry or final state, repeated action is possible. If neither knows the result, the enterprise has technical telemetry only.
In Quantum Automation Center, catalog, states, timelines, artifacts, logs, analytics, agents, permissions, and approvals can form the cross-engine view. The RPA engine retains its robots, queues, and packages. The accurate value proposition is not “replace RPA.” It is make a heterogeneous portfolio visible and governable.
Migrate without switching off useful robots
Start read-only: inventory engines, jobs, owners, and objects without changing execution. Next, normalize state and measure coverage. Then connect approvals or pause commands only for workflows with a clear boundary. Finally, retire orphaned or redundant automation with the process owner.
Avoid a big bang. A control plane that requires every robot to migrate before visibility appears defeats its own purpose. It should produce value while systems coexist.
The strongest counterargument
Another layer can duplicate orchestrator capabilities, increase integration work, and become a bottleneck. Normalization may erase important detail, while a common dashboard can create a false impression that incomparable engines behave alike.
That objection is strong. Answer it with an explicit boundary and incremental adoption. If one orchestrator already covers the whole portfolio, do not create an abstraction for fashion. When a cross-engine layer is needed, preserve native evidence links, allow local operation, and measure how much inventory is actually covered.
When not to use this approach
Do not add a separate plane when one engine serves a small portfolio and its orchestrator already covers inventory, ownership, permissions, health, and business evidence. Do not centralize secrets or turn every run into a synchronous dependency on the plane.
Use the pattern when the enterprise cannot answer, with one query, what runs, who owns it, and what result it produced across RPA, agents, and workflows. At that point, complementing engines is safer than replacing them and more honest than pretending they are one system.
Sources
Article topics
