Full duplex is not a feature. It changes conversation behaviour.

“Full duplex” is often listed as a specification, as if it were a checkbox next to a sample rate. In practice it is a behavioural property of the whole pipeline: the system can keep listening while it speaks, and it can decide, in real time, what to do with what it hears.

Turn-taking is a decision, not a pause#

Half-duplex behaviour alternates: speak, stop, listen, speak. The customer can hear the mechanism. Full-duplex behaviour overlaps the two, which is closer to how people talk — but it creates a harder problem: the system now has to distinguish a genuine interruption from a backchannel such as “mm-hm”, a background word from a different speaker, or the customer’s own hesitation.

Getting this wrong produces two opposite failures. Too eager, and the system talks over the customer. Too cautious, and it stalls, and the customer assumes they were not heard.

What this changes in production#

When interruption handling works, customers use shorter, more natural turns. They correct themselves instead of restarting. They answer the question they were asked. That behaviour is not a conversion claim; it is a visible change in how the conversation proceeds, and it is the reason architecture matters more than a feature list.

The question is not whether the system can speak. It is whether it can listen while speaking and act on what it hears.

Where architecture enters#

Governance and limitations#

Full duplex does not remove the need for a deterministic layer. The promise or the next step still has to be controlled where it matters. Full duplex changes how the conversation flows; it does not change who is accountable for what the process commits to.