FISTA Solutions does not load Google Analytics until you accept. Rejecting keeps optional analytics off. Read the Cookie Policy.

All field notes

Playbook · 5 minute read

How to Migrate From RPA to AI Agents: A Playbook

Migrating from RPA to AI agents means scoring every bot on stability, exceptions, maintenance, coverage, and value, keeping the stable ones, and for each candidate writing a specification of the process rather than the script, replacing screen scraping with APIs or a tool layer, building evaluation from bot history, running shadow mode, and cutting over with gates.

By FISTA Solutions· AI-Native Engineering Team·
How to Migrate From RPA to AI Agents: A Playbook article cover

Every mature RPA estate has the same shape: a majority of bots that run quietly and a minority that break every time a vendor moves a button, generate exceptions faster than people can clear them, and consume most of the maintenance budget. The minority is the migration candidate. This playbook takes those bots to governed AI agents one process at a time, keeping what works and carrying forward the governance the RPA program built. It operationalizes the strategy in the from RPA to AI agents whitepaper and the comparison in Digital FTE vs RPA bot.

Step 1: How should the estate be scored?

Use the RPA platform's run logs. For each bot record failure rate and causes, exception rate and handling time, engineering hours per quarter, the share of the end-to-end process it covers, and volume and value.

ProfileAction
Stable, low exception, low maintenanceKeep; consider converting screen steps to API calls
Stable but partial coverageWrap with an agent for the variable part; keep the bot for the deterministic step
Unstable on interface changeReplace; integrate through APIs or a tool layer
High exception rateReplace with an agent specified for the variation
High maintenance, low valueRetire

Also list the processes the RPA program assessed and declined; they are often the highest-value agent candidates and carry no migration cost.

Step 2: Which process goes first?

Choose a migration candidate with a willing process owner, measurable volume, systems reachable through APIs, and moderate consequence. The first migration builds the pattern; it should not be the most political process, and it should be one where the owner will sit in the shadow-mode reviews rather than delegate them.

Step 3: What does the specification contain?

Interview the process owner and the exception handlers; then write intent, scope and non-scope, inputs, decision rules with thresholds, exception taxonomy with routing, prohibited actions, tools and permissions classified by consequence, quality bar, escalation, autonomy level, and owner. Use the script only to check for missed rules. The template is in AI agent specification template; the reasoning behind specifying intent is in spec-driven development explained.

Step 4: How is the integration fixed?

Replace screen scraping with API access or a server on a governed tool layer for every system that offers one, following the Model Context Protocol for the enterprise whitepaper. Where a system has no API, decide deliberately between building one, wrapping it, or using interface control as a last resort, per when to use computer-use agents. Keep any bot steps that remain deterministic and stable as tools the agent can invoke.

Step 5: Redesign identity and permissions

Retire the bot's service account for this process. Provision the agent's own identity, scoped principals per tool (read-only for reads, narrowly scoped for reversible writes, consequential writes withheld or gated), and delegated user context where the agent acts for a person. Register the agent in the registry with its owner and classifications. The model is in the agent identity and access control whitepaper.

Step 6: Build evaluation from bot history

The bot's successful runs, its exceptions, and the human resolutions of those exceptions are a golden dataset: inputs with verified correct outcomes across the standard path and the exception categories. Add adversarial cases (malformed inputs, injected content in documents) and cases where the correct behavior is to escalate. Build the scoring harness against the quality bar. The method is in how to build a golden dataset.

Step 7: Run shadow mode against the bot and the people

Run the agent on live cases without acting, alongside the bot and the human exception path. Compare outcomes on the standard path with the bot and on exceptions with the people. Analyze every disagreement; most reveal undocumented rules. Revise the specification and dataset; iterate until agreement is stable. Guidance is in how to run shadow-mode deployments.

Step 8: Cut over with gates

Go live at the suggest level or act-with-approval, with consequential actions gated, the exception queue staffed, sampling running, and the bot still available for rollback. Advance autonomy on evidence. Retire the bot only when touchless rate, exception rate, and quality hold across a review period; record the retirement in the inventory.

Step 9: What is measured?

MeasureBefore and after
Touchless completion rateThe real automation rate
Exception rate and handling timeWhere interpretation pays
Maintenance hours for the processThe fragility cost removed
Cost per completed taskFully loaded, including oversight
Error and incident ratesQuality must hold

Bots retired is not a metric; a retired bot that moved work back to people is a regression.

Step 10: Carry the governance forward

The RPA center of excellence keeps the inventory, change control, credential management, and business relationships, and adds specification writing, evaluation design, and permission modeling. It should lead the migration rather than be bypassed by a data-science team that lacks its process knowledge.

What are the common mistakes?

  1. Migrating stable bots for novelty.
  2. Translating scripts instead of specifying processes.
  3. Reusing the bot's service account.
  4. Skipping shadow mode because the process looked simple.
  5. Screen control by default where APIs exist.
  6. Big-bang migration of the estate.
  7. Bypassing the center of excellence.
  8. Measuring bots retired, which rewards removing automation rather than improving the process, and hides the cases where work quietly moved back to people.

How does FISTA Solutions help?

FISTA Solutions runs RPA-to-agent migrations with the existing center of excellence, through forward deployed engineers who write specifications with process owners, fix integrations, build evaluation from bot history, and run shadow-mode cutovers, on the platform its AI enablement practice establishes for every subsequent AI agent. FISTA has delivered 150+ projects for 50+ companies across 12+ countries with 99.9% uptime.

To score your estate and pick the first migration, message FISTA on WhatsApp, or read computer-use agents vs RPA for the screen-control question.

Share-ready article cover

Download the generated social format.

Download cover

Clear answers

Questions raised by this field note.

Straightforward guidance for evaluating scope, fit, and the next step.

01Which RPA bots should be migrated first?

Bots that break on interface changes, bots wrapped in heavy manual exception handling, and bots that cover only part of a process while people do the rest. Stable, low-exception bots against unchanging systems should stay or be replaced by direct API integrations, which beat both bots and agents for deterministic work.

02How do you turn a bot's script into an agent's specification?

Do not translate the steps. Interview the process owner and the people handling the bot's exceptions, write the intent, inputs, decision rules, exception taxonomy with routing, prohibited actions, and acceptance criteria, and use the script only to check that no rule was missed. Agents implement intent; scripts encode one path.

03What about the bot's credentials?

They are usually broad service accounts and must not be reused. The agent gets its own identity with per-tool permissions classified by consequence, delegated user context where actions are on behalf of a person, and approval gates on consequential writes. Migration is the opportunity to fix credential debt the RPA program accumulated.

04How long does a migration take per process?

It depends on whether the systems have APIs, how well the process is documented, and how much shadow-mode evidence the owner wants. A process over documented APIs with a clean exception taxonomy is a short project; one over legacy screens with undocumented rules takes longer. Fix the sequence, not the calendar.

Start with the hard problem

Need the outcome owned, not merely analyzed?

Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.

Start a project