Handle events without creating loops

Learning objective

Handle no-match, no-input, tool failures, and other events without creating loops. This lesson focuses on bounded recovery in state-based low-code agents.

Core idea

An event handler needs a recovery ladder, not an unlimited retry:

detect -> clarify or retry -> offer an alternative -> escalate or stop

Count attempts in state, change the strategy after each failure, and end in a defined state. Repeating the same prompt or tool call with the same inputs is activity without progress.

How it works

Dialogflow CX provides built-in events for conditions such as no match, no input, invalid parameters, and webhook errors. Numbered events such as sys.no-match-1 through sys.no-match-6 can produce different responses on successive occurrences; a default handler can process later occurrences. The current event list and scope rules appear in State handlers.

Design handlers by failure class:

• No match: The system received input but could not map it to a valid intent or parameter. Rephrase the request, give relevant options, or move to a broader help path.
• No input: The system received no usable input. Reprompt briefly, account for channel timeouts, then offer another channel or end the interaction.
• Invalid parameter: The value was understood but rejected. State the valid constraint and ask only for that value again.
• Tool or webhook failure: Inspect the error category. Retry a transient failure within a cap, repair invalid arguments when possible, and route permission or business failures to an appropriate terminal or assistance path.
• Policy or safety event: Do not retry the blocked action. Explain the safe boundary and offer permitted alternatives.

Use a bounded state variable for recovery even when the platform offers numbered events. Record the operation, attempt count, last error category, and whether a side effect might already have happened. Reset the count only after genuine progress, such as a valid parameter or successful transition.

Avoid automatic cycles in the graph. An event handler that targets the same page can immediately re-enter page logic. A condition that remains true can trigger again on every lifecycle pass. Google Cloud’s documented page lifecycle can involve handlers from the previous loop iteration, so every re-entry path must change a condition, wait for new input, or terminate.

Webhook error handling also depends on route design. Google Cloud notes that a transition target on the handler that invokes a webhook can cause a webhook error to fail silently rather than invoke an in-scope error handler. Follow the documented handler evaluation rules and test the exact transition shape.

For writes, account for an unknown outcome. A timeout does not prove the action failed before its side effect. Query status or reuse an idempotency key before submitting again.

Key distinctions and trade-offs

No match versus invalid value: No match means interpretation failed. An invalid value may be understood perfectly but violate a constraint. The best reprompts differ.

Retry versus reprompt: A retry repeats a system operation, often without user input. A reprompt asks the user for new information. Neither should be unlimited.

Recoverable error versus terminal failure: A transient timeout may recover. A denied permission, expired workflow, or forbidden request needs escalation or termination rather than repetition.

More recovery attempts can improve completion for noisy voice channels, but they also frustrate users and increase latency. Set limits from channel behavior and measured success, and provide an escape path before the interaction becomes a loop.

Architecture / decision scenario

A voice agent collects a booking reference. On the first no match, it asks the caller to say the six-character code one character at a time. On the second, it offers keypad entry. On the third, it transfers to an operator with the captured context.

After a valid code, a booking lookup times out. The controller retries once with backoff. If it fails again, the agent reports temporary unavailability and offers a callback. The handler changes the state to Assistance requested; it does not return to an unconditional lookup route.

Each attempt changes either the input method or the terminal path, so repeated failure cannot circulate indefinitely.

Common exam traps

• Using one default reprompt forever for every no-match or no-input event.
• Resetting the attempt counter when no meaningful progress occurred.
• Retrying permission, policy, or permanent business failures.
• Assuming a tool timeout means a write had no side effect.
• Transitioning back to a page whose unchanged condition immediately invokes the same failing tool.
• Adding a webhook transition target without testing how it affects webhook error handlers.

What to remember

• Classify the event before choosing reprompt, retry, fallback, or termination.
• Change the recovery strategy as attempts accumulate.
• Cap attempts and define a safe terminal state.
• Require state change, new input, or a wait before re-entering automatic logic.
• Reconcile uncertain write outcomes before retrying.

Knowledge check

References

• Google Cloud, State handlers and built-in events
• Google Cloud, Pages and the page lifecycle
• Google Cloud, General agent design best practices
• Google Cloud, Webhooks