How Agentic Systems Improve Error Recovery Over RPA

I’d use RPA for fixed recovery steps and agentic systems when choosing the next safe step needs context. If a £1,250 invoice submission times out, check whether it reached the ledger before retrying. No response does not mean nothing happened.

I compare both approaches across five areas: diagnosis, recovery choices, state, validation and escalation. Agents can assess unfamiliar failures and revise a plan, but <u>they must not bypass controls</u>. Both approaches need duplicate checks, retry limits, logs and approval for high-risk actions.

Quick Comparison

Recovery area	RPA	Agentic systems
Diagnosis	Matches failures to preset rules	Assesses logs, records and context
Recovery choices	Follows configured branches	Selects or revises an approved plan
State	Resumes from checked checkpoints	Uses stored business state, not memory alone
Validation	Applies defined checks	Can request extra checks within policy
Escalation	Routes failures to set queues	Summarises uncertainty and proposes a next step

My starting point: keep repeatable actions rule-based, use agents where judgement helps, and test both against the same failures. Measure successful recoveries, time, duplicate actions, human review and total cost - not just whether a retry ran.

1. RPA

Failure diagnosis

RPA detects failures through predefined signals: failed selectors, timeouts, invalid input formats or validation checks returning false. It then classifies each event using predefined rules. Record the case ID, activity, timestamp, application, exception, retry count, input reference and last successful step.

Recovery decisions

After classifying the failure, the workflow can choose only from approved recovery branches: retry, delay, reopen the application, run a recovery step, skip the record or stop.

Use specific handlers for known failures, rather than a broad rule to ignore errors and continue. Skip a record only if the action is non-critical and later checks confirm that the process remains valid.

State and validation

After recovery, RPA must re-check the business state before moving on. Save checkpoints at confirmed business milestones, including the source item ID, status, external reference and completion time.

On restart, compare the checkpoint with the application’s current state. Then check the recovered result against explicit criteria:

A matching record count, a balanced monetary amount or an approved amount.

A finished command does not prove success.

Escalation and auditability

If recovery cannot confirm a valid outcome, the workflow must escalate. Send rule failures, exhausted retries and uncertain outcomes to the support team when predefined recovery rules offer no further action.

Keep incident reporting separate from execution control: logging an error does not stop the workflow. Record the workflow version, error category, recovery action, result and escalation path. Test each branch before deployment.

sbb-itb-1051aa0

2. Agentic Systems

Failure diagnosis

RPA matches failures to known exceptions. An agent can instead weigh several signals - the failed step, error text, input data, current state and recent history - to infer the likely cause. Limit diagnosis to approved data sources and logged evidence, because external content can carry prompt-injection risk.

Recovery decisions

An agent can change its plan as new evidence arrives. But every recovery path needs success criteria, retry caps, time limits, cost caps and stop conditions. Independently check each proposed action’s tool, arguments, target resource and permissions. Pause high-impact actions for approval when risk exceeds the threshold.

State and validation

Keep business state separate from the agent’s working context. Memory is not proof of completion. Before execution, validate identity, tool, arguments, target resource, rules and expected side effects.

After execution, check the response schema, changed fields, transaction status and whether the intended state was reached. A valid response can still be wrong, so rely on business invariants and idempotency controls - not just the agent’s interpretation.

Escalation and auditability

Pause when evidence conflicts, retries run out, permissions are missing or the next action is irreversible. Escalate with the unresolved question, supporting evidence and fixes already attempted, especially when the failure is ambiguous and the next safe step is unclear.

Don’t just record the failed step. Link plan revisions, permission decisions, tool calls and approvals with one correlation ID. Store tamper-resistant logs outside the agent’s control, without credentials or sensitive values.

Comparing Recovery in Practice

The difference is easier to see when the same invoice fails in several ways.

Hypothetical UK scenario: a supplier submits a £1,250 invoice. Compare three failure conditions: an ambiguous submission response, invalid VAT data or total mismatches, and a temporarily unavailable accounting service.

Diagnosing Failures

A timeout leaves you unsure whether the submission went through. Even a successful API response can post the invoice to the wrong supplier. Deterministic supplier-reference checks can catch that second error. Check any agent diagnosis against supplier master data and the ledger.

Recovery dimension	RPA	Agentic system	Practical implication
Root-cause assessment	Uses predefined exception mappings	Suggests the likely failure type from submission history	Check diagnoses against supplier references, VAT data, totals and ledger entries
Unexpected conditions	Stops or routes to an exception queue	Can suggest an authorised recovery path or ask for clarification	Require escalation when evidence is incomplete or the consequences are material

When the outcome is unclear, the next choice is whether to retry, wait or save a draft.

Retries, Fallbacks and Revised Plans

When the service is unavailable, retrying and saving a validated draft are different recovery choices. RPA follows configured branches. An agent can choose from authorised options based on service status and invoice priority. Both use bounded retries - not unlimited attempts.

Recovery dimension	RPA	Agentic system	Practical implication
Retry strategy	Uses configured attempt counts and delays	Selects an authorised retry policy based on invoice context	Keep maximum attempts and time limits non-negotiable
Circuit breaker	Stops calls until the service recovers	Stops calls until the service recovers	Leave the invoice pending during the outage
Fallback and degradation	Saves a draft or queues the invoice if configured	Chooses an approved fallback based on invoice context	Continue VAT and total validation while submission remains blocked
Failure reporting	Produces standard error codes and queue records	Produces an evidence summary and proposed next action	Make reports reviewable without exposing private model reasoning

A timed-out submission needs confirmation before any repeat action.

Saving State and Preventing Duplicates

If the £1,250 submission times out, check whether the record exists before resubmitting. Use the supplier reference, invoice number, date and total, plus the original idempotency key where supported. Reconcile an existing record; escalate if the result remains uncertain. A draft correction is reversible, but a posted change or possible duplicate payment needs human review.

Recovery dimension	RPA	Agentic system	Practical implication
State and resumption	Stores checkpoints and resumes from validated state	Stores checkpoints and resumes from validated state	Confirm the invoice’s ledger status before resuming; agent memory is not a transactional record
Intermediate validation	Checks fields at configured stages	Can request extra checks within policy	Revalidate changed VAT data and totals before proceeding
Duplicate prevention	Uses reference checks or idempotency logic when implemented	Combines those controls with contextual reconciliation	Check whether the record exists before retrying a timed-out submission
Partial completion	Uses approved compensation steps for partial completion	Uses approved compensation steps for partial completion	Separate draft corrections from posted changes or possible duplicate payments

If an action could post, pay or alter records, recovery also becomes an approval issue.

Escalation, Approvals and Audit Logs

For this invoice, the exception package should retain completed steps, identifiers, evidence, unresolved questions and proposed actions. Require human approval for high-impact or irreversible actions. Use least-privilege tools and enforce time, cost and retry limits. Protect logs with access controls, redaction and retention rules.

Recovery dimension	RPA	Agentic system	Practical implication
Escalation triggers	Routes configured invoice exceptions to named queues	Can identify combinations of uncertainty, risk and policy limits	Escalate uncertain ledger status or possible duplicate payment
Approval handover	Sends a standard task with predefined fields	Builds an exception package with evidence, unresolved questions and a proposed action	Include supplier reference, invoice number, VAT data, total and ledger status
Audit trail	Records submission steps, statuses and accounting responses	Also records tool selection and decision summaries	Link the invoice’s submission attempts to the approval outcome
Safe replay	Re-runs a controlled process or test case	Replays the invoice payload and identifiers in a sandbox without side effects	Prevent replay from posting or paying a real invoice

Recovery Strengths and Limits

Handling change does not guarantee reliability. RPA is easier to verify when recovery paths are fixed. Agents can handle unfamiliar failures, but both their diagnosis and actions need testing.

Each approach has costs across diagnosis, recovery choices, state, validation and escalation as processes change.

Approach	Recovery strengths	Recovery limitations	Operational trade-offs
RPA	Predictable handling of known exceptions, with testable, auditable branches.	Changes to screens, data formats and business rules can break recovery paths.	Less variation in behaviour, but more maintenance as applications change and branches multiply.
Agentic systems	Context-aware diagnosis across records and tools; flexible recovery when predefined branches fail.	Misinterpretations, unsuitable tool choices and inconsistent behaviour can cause new failures.	Variable latency, model and tool costs, plus broader testing and monitoring needs.

Measure cost and latency per completed recovery, not per model call. Count retries, tool use and human review. Track p50 and p95 latency alongside recovery success and human-correction rates.

Run each agent test case five to ten times. Record consistency rather than picking the best result. Test missing context, conflicting records, misleading instructions and unavailable tools. Assess the tool actions, not just the final response.

Turn incidents into regression tests. Record the trigger, contributing conditions, recovery decision and business impact. Update the relevant branch, prompt, policy or tool configuration in a versioned release, then re-test related cases. For agents, assess diagnosis and execution separately. For RPA, check that the revised branch has not introduced duplicate processing.

Conclusion: Choosing a Recovery Approach

Choose based on risk, process stability and how much exceptions vary - not novelty. Agentic systems help when similar failures call for different responses, but they must stay within fixed authority and policy limits.

Compare the options across five areas: process stability, exception variability, action risk, approval requirements and audit needs.

Workflow characteristic	Deterministic RPA	Agentic recovery	Hybrid design
Process stability	Best for stable, rule-based workflows with predictable screens, fields and outcomes	Better suited to changing workflows or inputs where diagnosis requires interpretation	RPA runs the stable path; an agent handles exception branches
Exception variability	Works well when failure categories and responses can be listed in advance	Better suited to causes that vary by context and require evidence-based replanning	An agent classifies exceptions; RPA runs approved, repeatable remedies
Risk level	Suits low-risk, reversible actions with strict validation	Suitable only within explicit authority, tool and policy limits	Keeps high-risk execution deterministic and uses agent reasoning selectively
Approval requirements	Uses predefined approvals and exception queues	Uses risk-tiered approval based on evidence and the proposed action	Requires human approval when an agent proposes a non-standard action or one with serious consequences
Audit needs	Records rules, inputs, retries and outcomes	Records evidence, tool calls, decisions, approvals and outcomes - not opaque summaries	Keeps workflow logs and agent decision records linked through shared transaction IDs

Use RPA for fixed recovery paths and agentic recovery for exceptions that need context-aware decisions.

Both approaches need duplicate checks, idempotency, transaction-state tracking, least-privilege access and safe escalation. Financial or legal actions still require approval.

Pilot representative failures against the RPA baseline, including timeouts, expired sessions, malformed data, partial writes and duplicate events. Measure recovery success, recovery time, human intervention, duplicate actions and cost per recovered case. Include staff and monitoring costs.

FAQs

How can I add agentic recovery to existing RPA workflows?

Keep your existing automation, and add agentic error detection and stateful recovery around each step. Use structured logging, health checks and real-time tracing to find root causes. Handle failures with retries, exponential backoff and circuit breakers. Add checkpoints with rollback or compensating actions so the process can resume from the last valid point.

Apply data correction and validation before and after each step’s inputs and outputs. Route high-stakes failures to people for approval, using runbooks to guide the response.

Which recovery tasks should I automate first?

Focus on routine, easily reversible workflows where automation can deliver the biggest efficiency gains. Data pipeline validation, resource rebalancing and service retries are good places to start.

Choose one critical workflow this week, and add behaviour tracing and automated regression tests. As you scale, automate fixes for common issues. Keep people in control of high-stakes decisions involving financial transactions, compliance or customer trust, where nuanced judgement matters.

How do I know agentic recovery is worth the cost?

Track recoverability: use structured logging and telemetry to spot issues early. Automate local recovery to minimise downtime and manual work, and pass high-stakes errors to people.

Set Recovery Time Objectives (RTOs) based on how critical each service is. Monitor incident impact to assess the value of recovery efforts: downtime can cost small businesses up to £6,400 an hour. Use feedback loops to make future incidents less frequent and shorten recovery times.