Rethinking RPA: Execution Choices and Operational Handoffs in the AI Era

Wang et al. propose a theoretical framework that treats people and modern large language models as finite processors with different constraints and makes the joint system—not either actor alone—the unit of design. [1] The paper analyzes no new enterprise data and does not measure RPA, process redesign, reviewer queues, or operational handoffs. This article uses it as a design lens for re-examining handoffs, not as evidence that RPA works.

When reviewers and AI are both congested, the cause is not singular. Unnecessary steps, duplicate controls, defective inputs, ambiguous rules, full review of every AI output, concentrated exceptions, and understaffing can look like the same queue. Separate what each case is waiting for, how many minutes each actor spends on it, and why it returns before changing the recipient from AI to a person or from a person to RPA.

Duplicate review is not automatically waste. It may implement segregation of duties, fraud prevention, or a legally required approval. Preserve its purpose and evidence. A pure re-entry step, by contrast, may be removed or confirmed once in the system of record. The first outcome is not a higher automation rate; it is excluding steps that lack a defensible reason to remain.

Milani, Kubrak, and Nava reviewed 40 published cases and classified several ways to redesign work through digital capabilities rather than merely substituting one technology for another. [2] They did not intervene in 40 companies or show that completing BPR before RPA produces better results. The review nevertheless supports questioning a step’s purpose before automating its current clicks.

This article begins after the end-to-end bottleneck analysis and the decisions to remove, combine, or simplify work. For each remaining sub-step, write the system of record, start condition, completed state, prohibited actions, exceptions, change frequency, and failure impact in one line. If these cannot be written, return the step to the process owner before choosing a technology.

A time-limited RPA can be reasonable when a major system change cannot arrive in time. Do not turn “fast to build” into a permanent-operations argument. Attach an end date, next review, replacement path, and continuity method to the interim solution. Repeated extensions require renewed approval of the reason and accumulated maintenance burden.

• Reason to remain: Which customer, legal, control, or downstream need requires the step?
• System of record: Which state in which system counts as completion?
• Change condition: Who communicates changes to screens, permissions, inputs, and rules?
• Exit condition: Which replacement, deadline, cost, or exception signal retires the automation?

Syed et al.’s scoping review of 125 sources found repeated descriptions of RPA candidates as rule-based, repetitive, standardized, well documented, low in exceptions, and supplied by structured digital inputs. [3] Much of the early literature included industry material, and sources disagreed about whether high volume or process stability was essential. Use these features as screening questions, not as a validated universal score.

RPA repeats computer-interface actions along an explicit procedure. Its program follows stated rules, but the business result still depends on screens, permissions, surrounding systems, data, and runtime state. The candidate is therefore not a task that “always produces the same answer,” but one whose correct completed state can be checked independently.

Generative AI may help classify prose, extract information, draft, or propose candidates when inputs vary. A confidence signal is not an independent verification of correctness, so this article does not use it to authorize downstream action. An output with no machine-checkable condition, low-impact boundary, or human approval should be held rather than connected directly to RPA or an API.

• The meaning and format of inputs can be normalized
• Allowed and prohibited execution conditions can be stated
• Completion can be reconciled against the system of record
• Expected exceptions and their destinations can be defined
• The change rate of screens, permissions, and rules is known
• Incorrect action can be contained and, where necessary, reversed or compensated

Herm et al. built an RPA implementation framework from 35 project reports, eight expert interviews, and workshops in five companies. They argue that interface-based RPA can be less robust than deeper integration and may act as a bridge to a future solution. [4] They also report cases that automated current work largely as-is for rapid deployment and treat the sequence between process redesign and RPA as contextual. This was not a comparative test of success rates or technical superiority.

These are not five alternatives at one level. A core system holds authoritative state and business rules; an API connects systems without imitating screen actions; RPA performs mostly predetermined interface operations; AI interprets or generates candidates; and people carry value judgments, exceptions, accountability, and approval. Workflow functions may coordinate waiting, resumption, and human tasks. One case usually combines several layers.

Catalysphere’s proposed comparison is not a universal ranking. First ask whether configuration or existing capability in the system of record can close the step, then consider a screen-independent connection such as an API. When that path conflicts with schedule, cost, or migration risk, RPA becomes a candidate for the remaining interface work with explicit rules and completion. AI may interpret a document, RPA may register it, and a person may approve only irreversible exceptions.

• Record: Hold the state that the organization treats as final
• Connection: Transfer inputs and results between systems
• Action: Execute predetermined registration, reconciliation, or updates
• Judgment: Resolve ambiguity, exceptions, and conflicting values
• Coordination: Connect waiting, resumption, human work, and sequence

Exclude RPA early when any of these conditions is materially present: rules or screens change frequently, input meaning cannot be normalized, exceptions dominate, completion cannot be reconciled, or maintenance exceeds the value of a small volume. If an API or core-system change is near, waiting may be better than building. If that change is years away, compare the total risk of a dated RPA bridge with waiting for permanent integration.

Do not prohibit every irreversible or high-impact action, but require independent approval, before-and-after reconciliation, duplicate-execution prevention, segregation of duties, and a reversal or compensation process. A transfer, notice, or registration in an external system is not undone by restoring an earlier bot version. Technical recovery and recovery of the business outcome are separate designs. If those controls cannot be added, exclude the step.

Human processing can be cheaper for low-volume, high-variation work. Do not treat building the RPA as an outcome in itself. Compare development, monitoring, credentials, change testing, incident response, and retirement with the cost of continued human work. When no measurements exist yet, at least list the roles and frequencies that create cost rather than pricing invisible maintenance at zero.

Syed et al. synthesize challenges in which changes to screen resolution or layout, surrounding systems, and business rules can stop RPA or send it down an incorrect path, while recording only a normal path can miss exceptions and rare events. [3] This does not estimate failure rates or imply that every current product lacks monitoring. It supplies known failure factors to turn into test cases.

Kokina and Blanchette’s exploratory cases in accounting and finance include identifying failure paths, splitting work into smaller modules, and returning to manual work when bot recovery is prolonged. [5] The sample was small and recruitment included referrals from a major RPA provider, and the study did not compare whether these practices reduce recovery time or loss.

This article therefore proposes a builder-absent failure exercise as one form of acceptance evidence. The operations team distinguishes the last confirmed authoritative state from work in progress, pending work, and completed work, while preventing duplicate execution. It stops new runs, continues pending work manually within available capacity, redeploys an approved bot version, reconciles completed cases, and requests workflow-specific reversal or compensation such as a refund, reversing entry, or correction notice.

A route back to people does not exist merely because a person is named. The required permissions, screens, procedure, skill, and processing capacity must remain, and a third party must be able to begin within the intended recovery time. If exceptions overwhelm normal human operations, narrow the automated scope or define which cases receive priority in degraded operation.

• Detect: Distinguish a stop, business exception, dependency failure, and unknown cause
• Contain: Stop new execution and isolate affected cases
• Continue: Confirm that people have the capacity, permission, and data for pending work
• Recover technology: Redeploy an approved version and retest representative changed cases
• Recover the outcome: Reconcile completed cases and complete reversal, correction, or compensation

Noppen et al. derived 11 guidelines from 26 sources, four Dutch organizations, and a two-round Delphi process for a model in which business units have some autonomy while an RPA center of expertise supports them. [6] The guidance covers capability assessment, on-the-job mentoring, development standards, documentation, testing, reusable modules, interim quality checks, technical review, and dependency-change communication. It did not show superiority over central governance, lower maintenance effort, or post-handoff outcomes.

This article records four responsibilities: the person approving the business outcome, the person running daily operations, the person providing technical support, and the person independently checking material changes and restarts. This is a Catalysphere responsibility example, not a research result requiring four separate jobs everywhere. Low-impact operations may combine roles, but self-approval of material changes needs a separate reviewer or an alternative control.

Use three handoff stages: builder present; builder observing without answering; and builder absent while the team demonstrates monitoring, exception handling, change testing, stopping, manual continuity, technical escalation, and restart judgment.

Builder-absent does not mean specialist-support-absent. Operations detects, stops, assesses impact, continues manually, requests support, and handles business reversal, correction, or compensation; specialists recover the bot, credentials, shared components, and deployment. An independent approver confirms material change and restart. A missed item leads to remediation, continued joint operation, reduced scope, or delayed handoff according to impact.

The goal is not to eliminate the specialist team. Operations owns the meaning of daily state and exceptions; specialists support architecture standards, shared components, credentials, difficult failures, and change review. A route where nobody knows whom to contact—and a route where every question returns to the original builder—both fail acceptance.

The take-away artifact is an “execution and handoff acceptance record,” not a technology comparison chart. Create one record for one automated sub-step and one execution design. It records the reason to remain, system of record, connection, action, judgment, coordination, success condition, invariant state, stop condition, exception capacity, reversal or compensation, accountable people, and handoff-exercise result; link detailed test and incident logs as evidence. Begin with business state and responsibility rather than a product or actor label.

Before the exercise, the process owner records a maximum detection time, allowable exception age or pending volume, minimum manual-continuity capacity, maximum time from specialist contact to the start of work, and a deadline for business recovery for that step. Do not invent one enterprise-wide value: set each boundary from failure impact and normal capacity, then have an independent approver authorize both the result and the branch for joint operation, reduced scope, delay, or stop when a boundary is missed.

The approval sequence is explicit. A step with no reason to remain returns to removal or consolidation. A step without explainable rules and completion does not advance to RPA. An execution without an authoritative state, duplicate prevention, stopping, and recovery for completed work does not advance to automation. A team that misses the predeclared builder-absent acceptance conditions does not advance to full handoff. A dated RPA bridge is reapproved when its end date or replacement path disappears.

This is not an argument for restoring RPA to prominence. It separates probabilistic interpretation, explicit rules, interface action, authoritative state, and human responsibility after work has been redesigned, then compares candidate combinations for maintainability. Begin by measuring exception age, review time, detection latency, manual continuity capacity, and time to start recovery without the builder—not the RPA success rate alone. Only the step that breaches its boundary returns to joint operation, narrowed scope, another method, or a stop.

• Purpose and record: Why does the step remain, and what is its confirmed state?
• Execution design: Who or what performs connection, action, judgment, waiting, and approval?
• Stop and recovery: Which failure stops work, and how are pending and completed cases handled?
• Operational responsibility: Who checks daily state and approves change, severe exceptions, and restart?
• Handoff evidence: When was the builder-absent exercise, what failed, and when is remediation due?
• Retirement: When are replacement, end date, accumulated maintenance, and exception growth reviewed?