# Decisions and GPT-Live separate dialogue from action selection

Decisions GA joined bounded inference with GPT-Live; preserve request identity so a delayed choice cannot silently act on an outdated spoken intention.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-22
Original announcement: https://openai.com/index/decisions-api/
Canonical URL: https://retrivium.ai/retrospectives/decisions-ga-voice-action-separation/

A voice interface can keep talking while a bounded decision is being computed. That makes conversation feel smoother, but it creates a state question: does the returned decision still describe the user's current request? Decisions GA brought this issue into a native voice integration.

## Two product paths met at general availability

[GPT-Live entered the API](https://openai.com/index/introducing-gpt-live-1-in-the-api/) on September 10, 2026, before [Sol and Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/) on September 22, 2026. The [changelog](https://developers.openai.com/api/docs/changelog) records Decisions beta on October 6, 2026. The [October 22, 2026 GA announcement](https://openai.com/index/decisions-api/) includes native GPT-Live integration. This chronology joins conversational audio with bounded decisions rather than making spoken output itself an executed action.

## Intent can change during computation

Imagine a user asking for a meeting room and then correcting the required location while the system continues the conversation. A decision based on the earlier request may return after the correction.

Its format can be valid and its answer appropriate for the old input. The problem is applying it to the new task state. The application needs a way to relate the decision to the request it evaluated, instead of treating every arriving result as current authority.

## A selected value is still separate from action

A room category or routing choice can guide the next operation without committing a booking. Keep the decision, proposed operation and confirmed external outcome distinguishable.

This separation is especially useful while the voice channel remains active. A reassuring spoken acknowledgment can mean that work was understood, queued or completed. The application should not let conversational fluency erase which state was actually reached. The exact controls depend on the chosen integration and should not be inferred from the launch alone.

## A correction-sensitive fixture

Prepare an illustrative conversation with an initial request, a location correction and a delayed decision response. Preserve the input associated with each decision and the final intended task.

Check whether an obsolete result is discarded, rechecked or clearly held pending the appropriate policy. Then inspect what the voice interface tells the user. The test should distinguish responsive dialogue from a stale action, without inventing automatic cancellation guarantees or measured response times.

## The release's architectural value

The integration gave developers another way to connect natural conversation with focused inference. Its value depends on preserving the boundary between what the user currently means and what an earlier computation answered.

The retrospective lesson is that fast decisions and continuous speech need an explicit synchronization policy. Useful state records connect request identity, returned choice and authorized operation, so the application can remain conversational without acting on an outdated intention.

## Related reading

- [Keeping request identity through asynchronous work](/journal/provider-request-id-trace-context/)
- [Separating a decision from execution](/journal/openrouter-tool-calling/)