GPT-Live decisions need a separate commit point

On 15 October 2026, OpenAI added native Decisions integration to GPT-Live. A voice application can receive typed decisions while the user is still speaking. That creates a useful opportunity to prepare work early, and a specific design problem: the user's sentence may still change its meaning.

“Move the appointment to Friday” can continue with “unless that is the bank holiday”, “actually, leave it where it is” or a different time. A decision made from the first part needs a lifecycle of its own.

Separate preparation from commitment

Use early signals for work that can be discarded: load the appointment form, retrieve permitted available slots or show the likely subject on screen. Keep changes to the actual booking behind a separate commit point.

The commit point should bind a settled request to exact arguments and the current record state. For a booking, that means the appointment ID, selected time, relevant timezone and any confirmation the workflow requires. A generic “yes” should not approve whichever candidate happens to be newest in memory.

This is a proposed application pattern. The new integration supplies decisions; it does not define your business's booking contract.

Correlate decisions with the conversation state

The voice-to-Decisions guide describes native delegation and transcript triggers. It also documents correlating delegation events and decision results, and waiting for the matching session.updated when changing questions during an active session.

Maintain a local request revision or equivalent state marker. When the user corrects a time, supersede earlier candidates. When a delayed decision arrives, check that it still belongs to the current request before using it.

Record which transcript segment or application state produced the candidate. You do not need to expose protocol IDs to the customer, but you do need them when diagnosing why a screen showed an old slot after the user had changed their mind.

Avoid treating independent choice answers as a transaction. Two choices can each be valid while their combination violates a business rule. Validate the complete proposed action after the answers are assembled.

Speech detection is only one signal

An application may use silence or utterance detection to decide when to process speech. OpenAI's separate Realtime VAD guide distinguishes silence-based and semantic turn detection for supported sessions. Those settings are product-specific; do not assume the same fields apply to every GPT-Live connection.

More fundamentally, detecting that a person has paused does not establish that they authorised an external change. The workflow needs to interpret the settled request, resolve missing information and apply its normal authorisation rules.

For low-impact interface behaviour, a provisional decision may be enough. For customer records, bookings or messages, the cost of waiting for a clear action usually deserves its own decision. Do not remove that distinction merely to make the demo feel faster.

Make corrections cheap and visible

If the user says “Tuesday, sorry, Thursday”, clear the Tuesday candidate and show Thursday as provisional. If the new date is incomplete, ask for the missing detail. Avoid announcing success until the external system has returned a result that the application checked.

Use wording that reflects the state: “I found a Thursday slot” before submission, “I am changing the booking” during submission, and “The booking is now Thursday at 10:00” only after confirmation. If the outcome is uncertain, say that it is being checked.

The approval versus permission note explains why an available tool is not enough. Voice adds a timing requirement: the approval must refer to the current candidate, not an earlier interpretation.

Test the conversation edges

Build a harmless test pack with mid-sentence corrections, long pauses, interruptions, background speech, similar-sounding names and two requests in one utterance. Include a customer who withdraws the request after a candidate appears but before submission.

Inject delayed and duplicate decision events in the application test harness. Check that obsolete candidates cannot commit, that one confirmed request produces one intended action and that reconnecting the session does not replay an already completed action.

Measure time to a useful provisional display separately from time to a confirmed result. Otherwise early interface activity can disguise an unchanged end-to-end delay.

Start the rollout with read-only lookups and draft candidates. Keep the established booking form available so staff can complete a request if the voice path loses state. Once the application handles corrections and asynchronous events consistently, enable one narrowly defined write operation. The measure of a successful voice workflow is a correct, recoverable outcome that matches the user's final request.

References

• OpenAI, API changelog, native GPT-Live Decisions integration, 15 October 2026. Accessed 17 October 2026.
• OpenAI, Connect voice to Decisions. Accessed 17 October 2026.
• OpenAI, Voice activity detection, for supported Realtime sessions. Accessed 17 October 2026.