A transit-authority rider agent must branch into separate pages for "check schedule," "dispute fare," and "file complaint," each returning to a main menu once the sub-task finishes. What drives this page-to-page navigation in the state-based low-code workflow?
Select an answer to reveal the explanation.
Short Explanation
Picture the main menu as a lobby with three hallway doors — schedule, fare dispute, complaint — and transition routes are the doors themselves, opening based on what the rider says they want. Once a rider's chosen path wraps up, another transition route is what walks them back out to the lobby again.
Full Explanation
Transition routes are the mechanism that connects one page to another in a state-based low-code workflow: each route evaluates a condition, typically a matched intent, and when satisfied it moves the session to the target page — from the main menu into check-schedule, dispute-fare, or file-complaint, and back again once that page's task completes. Few-shot examples can help the agent classify ambiguous rider phrasing into the right intent, but classification alone doesn't move the conversation anywhere; the route consuming that intent is what performs the navigation. A no-match handler only engages when nothing matches, which is the opposite of the normal three-way branching this scenario describes, and listing all options there addresses failure recovery, not routine navigation. System instructions shape tone and boundaries across the agent broadly, not the page-to-page path a specific rider takes. Scope caveat: a route back to the main menu should be explicit on each sub-task page, since without one the session can dead-end after the sub-task's fulfillment runs. Operational check: walk each of the three sub-tasks to completion and confirm the conversation lands back on the main menu page every time.