Skip to content
Daily Detour2026-09-18

When the Assistant Gets Stuck, Say What to Do Next

Two words, temporarily unavailable, are enough to make people think the whole system is down.

The booking assistant in the portal used to answer every recoverable failure, such as a busy upstream or a page that had changed, by saying it was unavailable. It now shows a message for each failure type, and when live prices refresh the page in the background it starts a fresh task instead of stalling midway.

A chat bubble on the left branching into three paths that lead to three signposts on the right: a green send again sign, a brass page changed sign and a dark red unavailable sign.
Failures with different causes call for different next steps; only a failure nobody recognises deserves the unavailable sign.

In the portal, an operator asks the booking assistant to find rooms while the search results refresh their prices batch by batch. A follow-up request goes in, and the screen answers with one line: the assistant is unavailable, manual search still works. Most people respond by reloading the page or switching the assistant off.

The two failures that kept producing that line were not outages at all. One comes from an upstream model that was slow for a moment, and the error itself says it can be retried. In the other, live prices updated the page’s workspace in the background and the server rejected the assistant’s outdated state. Calling both “unavailable” turns “please send that again” into “the system is broken,” and the user pays by starting over.

Timeouts and retryable errors now tell the user that the assistant is busy and the request can be sent again, and conflicts caused by a changed workspace explain that the page changed since the request. Expired sign-ins keep their existing handling, and only failures nobody recognises keep the unavailable message. Underneath, the assistant remembers the page version at the end of each turn and starts a fresh task when the page has moved on; an action that already succeeded is trusted by its receipt and re-checked on the server, which rejects only a genuine conflict.

The change does not hide failures behind silent retries. It tells the user what happened and what to do next, which is more useful than a spinner that never resolves. Follow-ups sent while prices refresh no longer die halfway through, and the failures that remain can be read, understood and acted on.