Act, Confirm, or Stop? Smarter behavior for AI assistants, wearables & robots — Amit Desai, Roku

Amit Desai, credited with Roku for this recording, starts from a tension familiar to anyone building voice interfaces. Talking is natural, but speech systems remain error-prone. That becomes more consequential as assistants move from answering questions to taking digital or physical actions. Playing the wrong song is irritating; a robot throwing away your watch is materially worse.

This creates two independent controls over the experience. The familiar control is accuracy: improve wake-word detection, speech recognition, language understanding, intent classification, entity extraction, or another part of the interpretation stack. The second is the system decision under uncertainty: given a hypothesis that might be wrong, should the assistant act, confirm it, or stop? Better decisions can reduce user pain even when the underlying interpretation remains unchanged.

The worked example is a simple music speaker. Collect 1,000 spoken requests, compare each requested song with what the system selected, and label the results. In the illustrative dataset, 790 hypotheses are correct and 210 are wrong: 79 percent accuracy. Conventional model work would try to shrink those 210 errors one percentage point at a time.

Instead, keep all 1,000 interpretations exactly as they are. The baseline assistant always acts, so every hypothesis immediately becomes playback. Desai adds one alternative: reject the hypothesis and ask the user to repeat. That sounds obviously safer, but it creates a harder quantitative question—exactly when should the system stop?

For the simplified exercise, every labeled hypothesis receives one reasonably calibrated confidence score between zero and one. A threshold T implements the policy: stop when confidence C < T; otherwise play. A cascaded production system may expose several confidence signals rather than one clean score, so this is a teaching model rather than the proposed final architecture.

A threshold such as 65 percent feels plausible: perhaps the system should act only when it is “confident enough.” But confidence alone does not identify the best decision. Moving the threshold prevents some wrong plays while also rejecting some requests the system understood correctly. The right boundary depends on what those outcomes cost the user.

The concrete failure is a request for “Kiss” by Prince that instead starts a Chris Brown song. The observable problem is not merely an incorrect label. Music begins playing; the user listens long enough to detect the error, talks over the speaker to stop it, and makes the request again. A refusal—“Sorry, I didn’t understand”—still delays success, but it avoids the work of undoing an incorrect action.

Desai turns that difference into a recovery-cost heuristic: estimate the additional time required to reach the intended result. He assigns 10 seconds to wrong playback and four seconds to stopping and repeating. These values are illustrative rather than measured universal costs; changing them, or changing the confidence distribution, changes the optimum.

For any candidate threshold, the cost is therefore 10 × wrong acts + 4 × stops. Correct immediate playback contributes no recovery cost. Raising the threshold generally reduces wrong actions but creates more refusals, including refusals of correct hypotheses. The weighted sum makes that tradeoff explicit instead of hiding it inside an intuitive confidence cutoff.

Desai names the objective the Outcome User Cost Heuristic, or OUCH—a language nerd’s cost function for pain. With the original always-act policy, 210 wrong plays cost 2,100 points across 1,000 requests, or 2.1 per turn. A guessed 65 percent stop threshold lowers that to 1,904, or about 1.9 per turn. Searching the demonstrated curve finds a much better threshold at 43 percent, reducing the average to approximately 1.27 OUCH points per turn.

Nothing about the 790 correct and 210 incorrect interpretations has changed. The improvement comes entirely from routing uncertainty into a less costly behavior. Accuracy describes whether the hypothesis is right; the decision policy determines how much damage a possibly wrong hypothesis can cause.

The next behavior is confirmation. Instead of immediately playing or refusing, the speaker can state its interpretation—such as “Play ‘Kiss’ by Prince?”—and let the user affirm or correct it. This splits confidence into three regions governed by two thresholds: stop at low confidence, confirm in the middle, and act at high confidence.

What does that three-way policy make visible? Low-confidence hypotheses are rejected before they cause damage, middling hypotheses pay the smaller cost of a question, and high-confidence hypotheses preserve the fast path. The two boundaries jointly determine how many correct and incorrect requests land in each behavior.

Confirmation is not free. Even a correct read-back delays playback, while an incorrect proposal forces the user to reject it and restate the request. The example assigns two seconds to affirmation and six seconds to correction, producing the extended objective 10 × wrong acts + 4 × stops + 2 × affirmations + 6 × corrections. Because two thresholds must now be selected together, the cost landscape becomes a two-dimensional heat map.

For the demonstrated data and costs, the optimized boundaries are 41 and 49 percent. The recorded display distinguishes a current 30/60 configuration costing 1,464 in total from the optimized 41/49 configuration costing 1,260. The recap expresses the progression as 2.100 OUCH points per turn for always acting, 1.904 for the guessed stop threshold, 1.274 for optimized act-or-stop behavior, and 1.260 after optimized confirmation. Confirmation improves the result again, although much less dramatically than introducing and optimizing the stop behavior.

The thresholds are not reusable constants. If a wrong action costs 20 instead of 10, the optimum moves because preventing incorrect execution becomes more valuable. It also moves when the confidence distributions change. OUCH is therefore a way to derive a policy from a system’s observed outcomes and product-specific costs, not a recommendation that every assistant act above 49 percent confidence.

A production assistant would not necessarily use one or two offline scalar thresholds. Desai expects a learned real-time decision model that can consider richer signals. The simplified exercise supplies the objective: choose behavior under uncertainty according to expected user cost while keeping the interpretation model and the behavioral policy conceptually separate.

A television shows why the interface changes the equation. For “open a channel,” confirmation can present several visual choices instead of speaking one candidate. Selecting the right option with a remote may be cheaper than a spoken correction, so confirmation’s cost falls. But launching the wrong channel may eject the viewer from their current state, making an incorrect act more expensive.

The ending returns to higher-stakes actions: making a phone call, sending an email, or moving an object. As consequences rise, accuracy improvements alone become an increasingly narrow response to uncertainty. The assistant also needs a policy for when to proceed, seek permission, or decline. If that interface remains painful, it becomes the choke point even while the models behind it improve. Desai’s memorable instruction is the pun that carries the whole mechanism: minimize the OUCH of the experience.