A voice agent stays useful during a slow tool call by saying what it knows, accepting new information and keeping its spoken updates aligned with the task that is still active. It should not fill every pause with narration, and it should not announce success merely because a backend request has started.
GPT-Live’s separate voice and backend layers make this interaction possible, but the application still decides how corrections, cancellations and late results affect the work. This guide proposes an application pattern for that boundary. The examples are design examples, not results from a deployed voice system.
- 01Progress needs a real state.Acknowledge the request, explain a meaningful delay and wait for evidence before confirming.
- 02Corrections change the task.Track a task revision so an older result cannot silently answer the new request.
- 03Speech and execution differ.Stopping audio does not cancel backend work or reverse an external action.
- 04Playback is its own evidence.Append acknowledgments do not show the caller heard the result; track delivery separately when the confirmation matters.
01 — Practical guideLet the conversation continue without inventing progress
Useful progress tells the caller something that changes their understanding: the request was accepted, the system needs a detail, the lookup remains pending, or an action has completed. Repeating “still working” on a timer can make a slow interaction more intrusive without making it more informative.
A hypothetical travel assistant can explain a baggage rule while a separate lookup checks availability. It should say that availability is pending and avoid presenting the general rule as a confirmed offer. The two subjects can coexist in conversation if their evidence remains separate.
The GPT-Live guide describes delegation as work sent to a backend while conversation continues. That ability changes the user experience, but it does not decide which updates deserve speech. Make the speaking policy part of the product requirements.
02 — MethodUse a small set of truthful task states
Keep the application’s task state explicit. Pending means work has been requested. Running means execution has begun. Completed means the chosen acceptance condition is met. Failed and uncertain need different handling: a confirmed rejection can be explained, while a missing acknowledgment may require reconciliation.
When multiple tools contribute to a result, report the task status rather than narrating each internal call. If one tool found availability and another has not created the booking, the task remains incomplete. The caller needs that distinction more than the name of the function being executed.
| Known state | Useful spoken update | What must remain unclaimed |
|---|---|---|
| Request accepted | I am checking the available options. | That a particular option is available. |
| Need more information | Which departure airport should I use? | That the lookup can finish without the missing input. |
| Lookup succeeded | There is an option matching those details. | That a purchase or reservation exists. |
| Action verified | The reservation is confirmed for the selected option. | That the caller heard the full confirmation. |
| Outcome uncertain | I am checking whether the request went through. | That retrying is safe or cancellation succeeded. |
03 — The evidenceSend facts to the right voice channel
The delegation documentation distinguishes instructions, quiet context and spoken commentary. Instructions steer the live model. Quiet context can inform later speech without being spoken on append. Commentary supplies material the model should speak, with paraphrasing.
Use quiet context for background facts the caller may ask about; use commentary for a useful result or necessary status update. Quiet context is not a secret storage channel: it can influence what the model says later. Keep sensitive execution details and full tool payloads in the backend.
For client delegation, preserve the original delegation identifier on task updates and use the appropriate session-wide form for general context. Keep a separate application operation ID and task revision. The provider’s delegation ID associates a conversation request; it is not the authority for deciding whether an external action may run.
04 — The decisionApply corrections before accepting late results
Suppose the caller changes a request from an afternoon departure to a morning departure while a lookup is running. Update the application’s active task revision immediately. When the afternoon result arrives, compare its revision with the current one before offering it to the voice layer.
For a read-only lookup, discarding the stale result may be enough. For a write, such as creating a reservation, the application must find out whether the old action was already executed. Cancelling a future step and reversing an existing action are different operations, with different consequences.
The provider guidance explicitly says that spoken interruption does not automatically cancel backend work. Do not rely on a prompt that says “stop” to enforce an action block. Apply the block in application state and verify any requested cancellation. Our safe agent stopping guide covers the broader shutdown problem.
05 — DefinitionCheck what reached the caller
The session documentation says append acknowledgments are not evidence of completed speech or playback. A result can be accepted into context and still be interrupted before the caller hears it. Track delivery separately when the confirmation matters.
If the caller asks again, query or retrieve the known result rather than repeating the action that produced it. If they ask whether the booking exists, answer from the authoritative record. If they ask to change it, create a new authorized task tied to the existing record.
Use the voice latency worksheet to distinguish backend completion, result submission and client playback. This makes it possible to diagnose whether the delay is in execution, result selection or delivery.
06 — ExampleTest interruptions at the consequential moments
Test a correction before tool dispatch, during a lookup, after an external action and during its spoken confirmation. Include a connection loss and a duplicated result event. Check the final record and the audio, not only the model’s transcript.
Closing the voice session needs its own policy. The documented close flow finalizes voice events and usage, while application-managed client work requires a separate finish-or-cancel decision. Do not leave a backend action ownerless because the caller has hung up.
The GPT-Live API decision guide helps choose the delegation path. For a production pilot, our AI transformation service can help make the task states, speaking policy and acceptance checks part of one implementation brief.
As-of date. September 12, 2026. The article is dated September 10, 2026; current documentation was reviewed later.
Method. Primary documentation and research were reviewed for the cited distinctions. Tables, worksheets and pilot checks are Digital Applied proposed methods, not observed deployment results.
Limitations. No production API workflow, vendor benchmark or participant study was executed for this article. Documentation can change; verify the selected configuration before implementation.
07 — The failure caseFour voice agents that spoke too soon
The pattern in this guide exists because speech is faster than backends and more confident than evidence. The illustrative agents below each say something true-sounding at the wrong moment. They are design examples, as the rest of the guide’s examples are, not results from a deployed system.
The narrated timer
The agent says “still working” every few seconds during a lookup. Nothing it says changes the caller’s understanding, and the pause becomes more intrusive, not more informative. The state table has a row for an accepted request; it does not have a row for repeating it.
The premature confirmation
One tool finds an available option and the agent says the booking is confirmed. The second tool has not created the reservation. The task was incomplete, and the caller now holds a confirmation nothing backs.
The stale result
The caller switches from an afternoon to a morning departure mid-lookup. The afternoon result arrives and is read out, because nobody compared its task revision with the current one before passing it to the voice layer.
The ownerless action
The caller hangs up while a reservation request is in flight. The close flow finalizes voice events and usage, but no application policy decided whether the client-managed backend task should finish or be cancelled, so it finishes with nobody to tell.
Each failure is prevented by a line in the script the next section describes: a state the voice layer may speak, the evidence it needs first, and the channel it goes through.
08 — The methodScript the states before the first call
The conclusion says to script the states a caller can encounter. Written out, the script is the second section’s states and table rows with three columns added for each: the evidence the backend must hold before the state is true, the channel the fact travels through, and the task revision it belongs to. Pending needs a recorded request. Running needs an execution start. Completed needs the acceptance condition met in the authoritative record, not a tool’s return value. Failed needs a confirmed rejection; uncertain needs a missing acknowledgment that reconciliation has not yet resolved.
An illustrative script for a travel assistant reads: request accepted, speak “I am checking the available options”, commentary channel, revision one. Lookup succeeded, speak “there is an option matching those details”, commentary, revision one, with the baggage rule the caller asked about held in quiet context. Caller corrects departure to morning, revision becomes two, and any revision-one result that arrives afterwards is discarded for a read-only lookup or reconciled for a write. Action verified, speak the reservation reference only after the record shows it, commentary, revision two. Caller hangs up, the close flow runs and the application’s finish-or-cancel policy for the in-flight task runs with it.
The script is also the test plan. The testing section’s cases, a correction before dispatch, during a lookup, after an external action and during spoken confirmation, are each a row of the script with the revision changed at that moment. Run them against the final record and the audio, as the section asks, and the script tells you what should have been spoken and what should have stayed unclaimed.
Completion. The backend record proves it, then the voice layer speaks it. A tool’s return value, a stream ending or an append acknowledgment is not the record, and the delegation guidance says a spoken interruption does not cancel backend work either.
09 — Next stepPut the decision into practice
Pick the slowest task your voice agent performs and write its script with the three extra columns. The rows that have no evidence source are the states the agent is currently inventing, and they are the first thing to fix.
Let the conversation continue without inventing progress
Choose a slow task and script the states the caller can encounter. Then make the backend prove each state before the voice layer speaks it, including when the caller changes direction.