A booking flow works perfectly until the booking API times out. The AI agent retries because it cannot tell whether the first request succeeded. It then tells the customer, “Your reservation is confirmed.” When the external system responds, a second booking has been created. The happy path was tested, but the failure path was not.
Reliable AI agent testing needs to cover more than successful conversations. Dependencies become unavailable, data grows stale, requests reach the wrong route, and external actions return ambiguous results. Context can disappear between sessions, retries can repeat completed actions, and human handoffs can fail. These situations matter because the agent may continue speaking confidently even when the underlying system has not completed the task.
Production failures cannot all be prevented. The purpose of failure-path testing is to establish what the agent should do when something goes wrong, what it may tell the customer, and when it must stop, clarify, retry, or transfer the conversation.
Build a failure map before testing
Start with one customer-facing flow and identify its dependencies. A booking flow, for example, may rely on customer identity, availability data, booking policies, a scheduling system, action permissions, routing decisions, conversation state, and human handoff. Any one of those dependencies can fail even when the others are working.
For each dependency, document six things:
- Possible failure: What could be unavailable, incorrect, delayed, or ambiguous?
- Expected behavior: What should the agent or flow do next?
- Customer-facing response: What can the agent accurately communicate?
- Resulting state: Is the request pending, blocked, completed, or awaiting clarification?
- Retry rule: Is another attempt safe, and under what conditions?
- Handoff rule: When should the conversation transfer to a human?
This is the failure map. Creating it before launch makes expected recovery behavior explicit rather than leaving the response to the agent's improvisation after an incident.
Break one dependency at a time
One of the clearest ways to test a failure path is to deliberately remove or disrupt a single dependency and observe the result. This isolates the cause and makes it easier to decide whether the flow behaved safely.
Booking API unavailable
If the booking system cannot be reached, the agent must not invent a reservation or announce a confirmation. The expected outcome is a safe retry when appropriate, or a clear explanation and handoff when the system cannot verify the booking.
Document source unavailable
If a document containing a policy is inaccessible, the agent should not reconstruct the policy from a guess. It may use another approved source when permitted. Otherwise, it should explain that the policy cannot currently be verified or hand off the request.
Data Search returns no match
If an exact product, booking, or account lookup returns no result, the agent should request a clearer identifier. A similar-looking record is not a substitute for a verified match.
Permission denied
When an external system rejects an action because of permissions, the agent should not retry indefinitely or claim the action was completed. The flow needs an appropriate stop or escalation path.
The objective is not to simulate every possible outage at once. Test one broken dependency, examine the customer response and resulting state, and confirm that the flow degrades safely.
Test stale and conflicting data
Some of the most difficult failures happen while systems are still returning data. An outdated cancellation policy, stale inventory count, duplicate customer record, incorrect price, or previous booking state may look like a valid result to an agent.
Create a test in which two sources disagree. One document might contain an older cancellation window while another contains updated terms. Does the flow follow an established source-of-truth rule, request clarification, or stop until the conflict can be resolved? It should not simply select whichever result looks most semantically relevant.
This is an important distinction: a successful retrieval is not necessarily a correct answer. The test should establish whether the agent can handle uncertainty about the authority and freshness of the information it receives.
Test routing mistakes and topic changes
A routing error can send a customer to the wrong flow even when every component within that flow works correctly. Test both ambiguous opening messages and changes of topic during an active conversation.
Ambiguous opening message: A customer says, “I need help with my booking.” They may want to modify a reservation, cancel it, discuss payment, arrange a shuttle, or request a different room. The flow should ask for the missing detail or use available context rather than assuming a specific intention.
Topic change: A customer first asks, “What time is check-in?” and then says, “Can you move my airport pickup?” The second message requires different handling. The conversation should not remain trapped in the original path simply because the first message was about hotel information.
In AskHandle, the Router supports initial routing, while Dispatcher can support routing as the conversation evolves. Test the behavior appropriate to the selected routing mode, including what happens when the customer changes their intention midway through a conversation.
Test missing and ambiguous context
Conversational requests often refer to information that is not repeated in the latest message. This works well when the relevant state is available, but it creates a risk when the reference cannot be resolved reliably.
Consider three short requests:
- “Change it to Friday.” Which booking or appointment should change?
- “Same one as last time.” Which record or previous selection is intended?
- “Send it there.” Which destination is being referenced?
A safe flow can use reliable conversation state, retrieve the relevant record, or ask one focused clarification. What it should not do is guess the booking, account, item, or destination. The test passes when the agent recognizes what is missing and obtains the information it needs before taking an action.
Test tool failures and external actions
Actions need more rigorous testing than informational responses because their consequences may persist outside the conversation. A failed information lookup can produce a poor answer. A failed or repeated booking, refund, or account update can change an actual record.
Inject scenarios such as an API timeout, HTTP 500 error, malformed response, invalid argument, permission denial, partial success, or complete external-system outage. For each one, inspect whether the flow detected the issue, preserved relevant state, avoided a false confirmation, and either retried safely or escalated correctly.
The decisive rule is that the outcome of an external action must come from the system's response, not from the model's expectation of what should have happened. If the response does not confirm success, the agent cannot treat success as established.
Test duplicate actions after a timeout
Retries become dangerous when the outcome of the first request is unknown. Imagine this sequence:
- The agent submits a booking request.
- The connection times out before a response is received.
- The agent cannot determine whether the booking succeeded.
- The agent submits the same booking again.
- The first request had actually succeeded, creating a duplicate booking.
The same pattern can affect refunds, support tickets, emails, account changes, and reservations. A failure test should therefore ask: If the first call may have succeeded, what does the flow do before attempting the action again?
The technical answer depends on the integration, but the customer-facing requirement remains the same. The agent must not trigger a potentially duplicate action without an appropriate verification or recovery path, and it must not claim the task is complete while its outcome remains uncertain.
Test loops and repeated questions
An AI agent can get stuck without producing an obvious error. Document retrieval may repeatedly fail, the agent may ask the same clarification again and again, a tool retry may never resolve, or routing decisions may bounce between paths.
Test these situations deliberately. Define a maximum retry count, a way to detect repeated questions, sensible state transition limits, conditions for handoff, and a safe stopping point. Then verify that the conversation actually reaches that stop or escalation condition.
The fact that an agent can continue generating messages does not mean the flow should continue indefinitely. A reliable flow recognizes when further turns are unlikely to resolve the issue.
Test human handoff failures
Human Handoff is another dependency that needs its own failure tests. A destination may be unavailable, a connector may return an error, a request may arrive after hours, or the handoff may start without completing. The relevant conversation context could also fail to transfer.
For each scenario, verify that the customer receives an accurate status, the conversation is preserved where possible, and an alternative path exists when appropriate. In particular, test whether the AI agent continues saying that a human is joining when no transfer has actually occurred.
The customer should not be left believing an escalation succeeded when the handoff failed.
Test state loss, reconnects, and resumed conversations
Customer conversations do not always take place in one uninterrupted session. A customer may leave and return, a process may restart, a channel may reconnect, or an external callback may arrive after the original conversation has paused.
The key test is whether the flow can resume without repeating an action that has already been completed. If a booking was submitted before the interruption, reconnecting must not automatically create another reservation. The flow needs to recover enough reliable state to determine what happened and what remains to be done.
State recovery is part of reliability, not merely a convenience for keeping a conversation natural.
Test language that falsely implies success
A failure can occur in the agent's response even when the external system returns an accurate status. For example:
| External system result | Unsafe AI agent response |
|---|---|
pending | “Done.” |
failed | “Your refund has been processed.” |
| No response | “Your appointment is confirmed.” |
Test customer-facing language after pending results, timeouts, errors, partial successes, and ambiguous responses. In every case, the agent should distinguish what is verified from what is still unknown.
A reassuring tone is useful only when the substance is accurate. When success cannot be verified, the agent must not claim success.
Test when the flow must stop
Some requests cannot proceed safely. The source may be unavailable, customer identity may not be verified, permission may be missing, an external action may fail, the customer may decline required information, or no approved policy may cover the request.
Design test cases around these boundaries. The expected response might be to stop the action, explain the limitation, wait for the required information, or hand off the conversation. A successful test shows that the flow respects the boundary rather than improvising an unsupported path forward.
Grade recovery, not just task completion
A failure test does not need to complete the original customer request to pass. If the booking API is down, the flow cannot create a reservation. It can still recover correctly if it detects the outage, preserves the request, avoids duplicate actions, refrains from claiming success, and provides the customer with an appropriate next step or handoff.
This distinction matters when evaluating an agent. Resolution measures whether the requested task was completed. Recovery measures whether the system handled an obstacle safely and predictably. Both deserve a place in the test results.
Turn production incidents into regression tests
Real incidents reveal failure cases that were missed during initial design. Each one should become a repeatable regression test rather than an isolated fix.
- Capture the exact scenario, including the customer's message and relevant system responses.
- Reproduce the failure in a controlled test.
- Define the expected response and resulting state.
- Add the scenario to the ongoing failure-test suite.
- Correct the relevant flow or integration behavior.
- Rerun the test suite to check for the same failure and related regressions.
A duplicate appointment, incorrect routing after a topic change, lost conversation state, stale source, unsafe retry, or failed handoff can all become useful test cases. The aim is to prevent the same incident from recurring simply because the original conditions were forgotten.
Use a practical failure-test matrix
A shared matrix helps the team connect each simulated problem to an observable outcome. It also exposes missing decisions about what the agent should say or when the flow should hand off.
| Dependency | Injected failure | Expected behavior | Customer message | Resulting state | Handoff? |
|---|---|---|---|---|---|
| Booking API | Timeout | Do not confirm; verify before retry | “I can't confirm the change yet.” | Pending / recovery | Maybe |
| Policy source | Unavailable | Make no unverified policy claim | “I can't verify that policy right now.” | Blocked | If needed |
| Data Search | No result | Ask for an accurate identifier | Focused clarification | Waiting for customer | No |
| Human Handoff | Transfer fails | Preserve context and explain the failure | Clear fallback response | Waiting / alternative path | Not completed |
Use this as a starting point and extend it with the dependencies and failure states specific to each flow. A test is more meaningful when the expected behavior has been written down before anyone runs it.
How to test these scenarios in AskHandle
AskHandle lets teams assemble flows using components such as Router, Dispatcher, Question Flow, Document Search, Data Search, AI Answer, AI Answer with enabled skills, and Human Handoff. The Test Page can be used to examine conversation behavior before a flow is published.
Start with realistic test conversations: a missing identifier, an ambiguous opening message, a change of topic, unavailable information, or a request that should lead to handoff. Where external actions are involved, also test how the agent responds to failed or uncertain results.
Not every infrastructure failure can necessarily be injected directly through the Test Page. Some scenarios require a controlled external-system test or an intentionally simulated response. The important objective is to verify the agent's behavior and the flow's recovery decisions rather than assume a successful demo conversation proves production reliability.
Reliability means failing predictably
Every production AI agent will eventually encounter incomplete information, unexpected conversation turns, unavailable systems, or broken dependencies. Reliability does not require pretending these situations can be eliminated. It requires clear decisions about when to retry, when to ask for clarification, when to stop, when to hand off, what the agent may claim, and which state must be preserved.
A reliable AI agent flow is not one that never encounters failure. It is one whose failures have been anticipated, tested, and given a safe recovery path.
