When a connected system fails, a virtual agent should establish what happened before repeating an action. Test rejected requests, timeouts, and unknown outcomes separately. A retry that sounds helpful can create a second request when the first one already succeeded.
Level AI documents configurable workflow controls. Google Cloud documents webhook-error event handlers with evaluation-order constraints. These product descriptions do not prove that a buyer's particular action is safe to retry.
Which failure states need separate decisions?
A rejected request has a different recovery path from a request whose final state is unknown. A timeout tells you that a response did not arrive in time; it does not by itself establish that the remote system made no change. Design the conversation around this distinction.
| Observed state | Proposed recovery question |
|---|---|
| Request rejected before processing | Can the customer correct the missing input? |
| Read-only lookup times out | Is a bounded retry appropriate for this task? |
| Action result is unknown | Can the record be reconciled before another attempt? |
| Action completed but response was lost | Can the actual result be reported without repeating it? |
| Dependency remains unavailable | Which supported human or deferred route takes ownership? |
These are acceptance questions, not claims that every platform exposes all required states. Ask the integration owner what identifiers and records can distinguish attempts. A transaction-specific replay control should be verified in that system rather than inferred from the bot's conversational behavior.
How should a failure be injected during a test?
- Use a non-production scenario with a known starting record.
- Fail the response before processing, during processing, and after commitment.
- Observe the spoken explanation and the next requested action.
- Inspect the final record for duplicate or partial changes.
- Restore the dependency and test whether the conversation recovers or hands over correctly.
Include a customer who repeats the same instruction during a slow response and one who reconnects after a dropped call. Keep the test's record identifiers stable enough to reconcile attempts, without placing unnecessary customer data in general-purpose test reports.
What should the customer hear?
Specify honest status wording for each state. “I cannot confirm the update yet” means something different from “the update failed.” The response should avoid making a promise that conflicts with the system evidence. If the customer must wait or speak to a person, explain the supported next step and preserve the unresolved action's context.
When is the recovery plan complete?
Complete the plan when a named operator can trace an attempt, establish the final state, and resolve an exception without guessing. Maintain a short runbook for disabling an affected task while leaving unrelated tasks available where the implementation supports that separation.
Use the handoff contract for ownership and the task outcome contract for classifying unresolved cases.
What should happen after a timed-out address update?
Use this proposed state table for an illustrative address-change task. A timeout describes missing acknowledgment, not the final stored address. Keep a correlation identifier across the conversation, attempted action and reconciliation query.
| Observed state | Next step | Customer statement |
|---|---|---|
| System confirms rejection before a change | Correct the permitted input or route to an owner | The requested change was not completed |
| Timeout; readback shows the intended address | Record the confirmed result; avoid another write | The change is confirmed, using the authoritative record |
| Timeout; readback still unavailable | Mark unknown, stop automatic repetition and assign reconciliation | Completion cannot yet be confirmed |
| Conflicting records | Escalate with both records and their timestamps | Explain the unresolved state without choosing a convenient result |
Idempotency means a repeated action with the same identity does not create another business effect; confirm whether the connected system actually supplies that guarantee. A conversation retry alone cannot create it. Test lost acknowledgments after a successful write, not only easy failures before a write. The acceptance evidence is the final authoritative state and the absence of duplicate effects, with an owner for every unknown case.
Limits
No resilience benchmark or duplicate-prevention guarantee is established here. Recovery depends on application semantics, available logs, integration design, and configured routes. Run failure injection in an isolated test environment with representative records and a known rollback path before considering a production rollout.