# Full duplex changed the voice-agent state machine

Why the GPT-Live-1 API release changes voice-agent state ownership, and how concurrent speech exposes cancellation and stale-result boundaries.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-10
Original announcement: https://openai.com/index/introducing-gpt-live-1-in-the-api/
Canonical URL: https://retrivium.ai/retrospectives/live-api-full-duplex-state-machine/

## From alternating turns to concurrent audio

The [Realtime API announcement on October 1, 2024](https://openai.com/index/introducing-the-realtime-api/) established an earlier speech interaction API. [GPT-Live arrived on July 8, 2026](https://openai.com/index/introducing-gpt-live/), before [its developer API release on September 10](https://openai.com/index/introducing-gpt-live-1-in-the-api/). The latter made simultaneous listening and speaking an application concern. That shift matters because a conversation cannot be represented adequately by a single switch between user input and assistant output. Incoming speech may revise a request while the assistant is already explaining an earlier interpretation.

## Separate acoustic activity from task ownership

A microphone becoming active does not necessarily mean that the user has taken over the task. A brief acknowledgement, a correction, and speech to another person carry different implications. An application should distinguish the presence of audio from the intention to interrupt. This is a design consequence of concurrent channels, rather than a claim that every intent is perfectly recognized. A useful state model tracks what the assistant is saying, which task version it is answering, and whether an incoming utterance changes that version.

## Cancellation has more than one target

Suppose an illustrative booking assistant is describing a morning appointment when the caller asks for an afternoon slot. Stopping the spoken description is different from cancelling a pending availability lookup. Replacing the lookup is different again from reversing an already committed booking. Treating all of these as the same interruption hides consequences. The orchestration layer needs to know which operation is still provisional and which has crossed an external action boundary. Full-duplex audio alone does not supply a transactional rollback mechanism.

## A trace that can explain overlap

A practical fixture can retain the spoken prompt, the moment a correction starts, the task version associated with a backend request, and the response that eventually reaches the caller. Review whether speech about the old appointment continues after the new preference has been understood. Also inspect whether a late result for the old request is discarded or clearly qualified. These are proposed observations, not reported product measurements. They reveal ownership mistakes that an average response-start latency would miss even when the voice sounds natural.

## The boundary of the architectural claim

Concurrent audio can remove an artificial need to finish every turn before listening again. It does not remove the need to define interruption policy, action approval, or stale-result handling. The more valuable acceptance question is therefore whether an evolving request remains consistent across speech and work. A convincing demonstration should include a correction during an explanation, not merely rapid answers to isolated questions. That scenario tests the new state boundary directly while leaving claims about overall reliability to a properly measured evaluation.

## Related reading

- [Tracing request ownership](/journal/provider-request-id-trace-context/)
- [Measuring timing boundaries](/journal/provider-monotonic-latency-measurement/)