How to test interruption recovery in banking AI agents

Banking AI agent interruption recovery testing checks whether an AI agent can safely stop, resume or hand off a banking task after a disruption. It verifies that authorised workflow state is preserved and that recovery does not cause duplicate or unauthorised actions. Tests cover the agent's decisions and the banking systems it calls, using transaction records, approval state and audit events as evidence.

What interruption recovery testing covers

An interruption can occur while an agent is planning, waiting for a tool response, submitting a transaction or awaiting human approval. Typical triggers include a process restart, network timeout, unavailable banking service, expired session or transfer to a human operator.

Interruption testing introduces these disruptions at controlled points in a workflow. Recovery testing checks the behaviour afterwards: whether the agent resumes from a valid checkpoint, safely retries, reports an unresolved outcome or stops for review. A conversation continuing successfully is insufficient evidence. The underlying account, payment and approval records must also be correct.

For banking workflows, the expected recovery action depends on the transaction's actual state. If a payment request times out after submission, the agent may not know whether the payment was accepted. It should establish the status through an authorised query or route the case for review, according to the workflow's rules. Blindly submitting again can create a duplicate payment.

How to design a test

Start with a workflow whose permitted actions and recovery rules are defined. Record which steps require customer authentication, a limit check, maker-checker approval or another control. Decide what the agent may do automatically after each interruption and which conditions require a human decision.

Use a controlled test environment with synthetic customer and account data, test payment destinations and safe service simulators. Seed known balances and workflow states. Keep the agent configuration, prompts, tool permissions and test data fixed while comparing runs, so that changes in the outcome can be investigated.

Inject a fault at a meaningful boundary, such as immediately before a payment call, after the bank service accepts the request but before the agent receives its response, or while the agent waits for approval. Capture the agent's state, tool requests and responses, and relevant backend records. Verify the outcome against the expected invariants, rather than requiring identical wording from every run.

Check that recovery:

• preserves the authenticated customer, task and approval context without exposing another customer's data;
• does not bypass limits, permissions or approval gates;
• avoids repeating a side effect when its original result is uncertain;
• communicates accurately when the task is pending, failed or awaiting review; and
• leaves an auditable record of the interruption and subsequent action.

These checks should include the banking service's records, not just the agent transcript. Where available, compare payment status, account postings, approval events and audit logs. A successful recovery should leave these records consistent with the workflow's defined outcome.

Worked example: transfer status timeout

Set up a test transfer that requires a second approver. Let the agent prepare the transfer and submit it using a unique request identifier. Configure the payment service simulator to accept the request, then delay its response until the agent times out. Restart the agent or resume the workflow through its supported recovery path.

The expected result is that the agent checks the existing request's status using an authorised mechanism before taking further action. It must not create another transfer or claim completion without evidence. If the status cannot be confirmed, it should preserve the case for review and explain that the outcome remains unresolved. The payment record should appear no more than once, and the required approval should remain in force.

Run a separate case where the service confirms rejection. Check that any retry follows the defined policy and retains the required approval. This distinguishes a safe retry after a known failure from a risky repeat after an unknown outcome.

Interpreting failures and trade-offs

Common failures include lost task context, stale account or approval data, repeated tool calls, premature success messages and recovery that skips a control. A retry policy can improve completion after transient faults, while increasing duplicate-action risk if the system cannot establish whether the first request succeeded. Tests should therefore cover both confirmed failures and ambiguous outcomes.

AI agents can make different plans or produce different wording across runs. Assert stable safety properties, such as no unauthorised payment and no duplicate posting, while checking that each allowed path ends in a valid workflow state. Treat unexpected tool calls or unsupported completion claims as failures even when the final screen appears correct.