Designing for Interruptions and Backchannels: UX Patterns for Full-Duplex Voice Skills

For three years, every voice assistant you built ran on the same conversational contract: one speaker at a time. You talk, it transcribes, it thinks, it talks back. The turn boundary was a hard wall, and the whole experience was shaped by that wall — the awkward pause after you stop, the assistant barreling over you the instant you try to correct it, the dead air while it "thinks."

As of July 2026, that wall is gone. OpenAI's GPT-Live, which rolled out July 8 and replaces Advanced Voice Mode as the default consumer voice experience, is full-duplex: it can listen and speak at the same time. According to OpenAI's launch post, the model decides many times per second whether to speak, keep listening, pause, interrupt, or call a tool. The press summary was blunt — ChatGPT is finally "learning to just listen and not interrupt."

If you build voice skills, this is not a consumer curiosity. The same behavior is available to build on through the Realtime API (gpt-realtime), and it resets what "good" sounds like. A voice skill that still waits for a hard turn boundary now feels visibly dated next to one that backchannels and yields. This piece turns GPT-Live's four observable behaviors — acknowledge, stay quiet, interrupt-aware, tool-mid-turn — into design rules you can apply.

Key Takeaways

• Full-duplex is a UX shift, not a latency tweak. The model listening and speaking simultaneously changes how a conversation feels, and users will now expect that feel from every voice skill.
• Backchannels are a feature you design, not an accident. Brief acknowledgments ("okay", "mhmm") and deliberate silence are signals — decide when your skill emits them.
• Barge-in must be instant and cheap. When the user cuts in, your agent stops mid-word and adjusts immediately; anything slower reads as "it isn't listening."
• Silence is a valid response. Staying quiet while the user thinks is often the correct behavior — don't fill every gap.
• Build on the Realtime API, not GPT-Live. The consumer app isn't your surface; gpt-realtime gives you the full-duplex primitives plus function calling over live voice.
• Pair every UX rule with a latency budget. Backchannels and barge-in only land if the round trip is fast enough to feel real — see the latency budget breakdown.

Why full-duplex changes the design problem

The old pipeline was three services in a line: speech-to-text, then an LLM, then text-to-speech. Each hop added delay, and — more importantly — each hop assumed turns. The model literally could not hear you while it was talking, because the microphone stream and the speaker stream were separate phases.

GPT-Live collapses that into a single speech-to-speech model. OpenAI says this preserves nuance and cuts latency compared to the transcribe-then-synthesize chain, but the deeper consequence is architectural: because one model handles the whole loop, it can hold the floor and monitor the floor at once. That's what makes "listen and speak at the same time" possible.

For a skill designer, the mental model flips. You're no longer scripting a request/response exchange. You're designing an agent that is continuously deciding what to do with the audio channel — and most of those decisions are about restraint. When to stay silent. When to acknowledge without taking over. When to stop talking because the user started.

Pattern 1: Backchanneling — acknowledge without taking the floor

A backchannel is a short signal ("mhmm", "yeah", "okay") that means I'm still here, keep going — not my turn now. Humans do it constantly. GPT-Live does it too: press coverage highlighted that it can emit brief acknowledgments when you pause, which is precisely the behavior that makes it feel like it's listening rather than waiting.

The design trap is over-using it. A backchannel after every clause is worse than silence — it reads as nervous. Some rules:

• Backchannel on genuine pauses, not on every gap. A short pause mid-thought is an invitation to acknowledge; a pause at the end of a complete thought is an invitation to respond.
• Keep backchannels sub-word-length. "Mhmm" is a signal; "Okay, got it, keep going" is a small speech and defeats the purpose.
• Never backchannel while delegating. If your agent is mid tool call or reasoning, a stray "okay" implies it's done. Stay silent until you actually have the answer.

Pattern 2: Deliberate silence — let the user think

The counterintuitive one. GPT-Live can stay quiet while you think — it doesn't rush to fill the gap. For a skill, silence is a design decision with a cost model: every second your agent talks is a second it can't hear a correction, and every second of unnecessary speech is latency and (on the API) tokens.

Design silence explicitly:

• After asking a question, wait. Don't re-ask or "help" after 800ms. Give a real beat.
• If the user trails off mid-sentence, hold. They're formulating, not yielding.
• Only break silence to backchannel (Pattern 1) or when a genuine turn boundary has clearly passed.

A voice skill that treats silence as failure will interrupt the user's thinking — the exact behavior GPT-Live was praised for avoiding.

Pattern 3: Barge-in — stop instantly, adjust immediately

Barge-in is the user cutting in while the agent is talking. GPT-Live lets you interrupt anytime, with immediate adjustment. This is the single most important behavior to get right, because failing it is the most obvious "the robot isn't listening" tell.

Two things must happen the instant speech is detected from the user:

1. The agent stops speaking mid-word. Not at the end of the sentence. Mid-word.
2. The agent re-plans from what it just heard. If you interrupted to say "no, the other one," the next thing out of its mouth reflects that correction.

On the Realtime API side, this is where your architecture earns its keep. The stream has to be cancellable at any moment, and your state has to survive the cancellation — the agent can't lose the thread just because it was cut off. If you're wiring tools into this loop, the function-calling guide covers keeping a call graph coherent across interruptions.

Pattern 4: Speak while you work — tool calls mid-turn

Because the model decides "call a tool" as one of its per-moment options, a full-duplex agent doesn't have to go silent to do work. GPT-Live delegates hard requests to a frontier model (GPT-5.5 for now) in the background for web search or deeper reasoning while keeping the conversation flowing.

For your skill, this means designing the cover behavior for latency:

• If a tool call will take more than a beat, say what you're doing ("let me check that") and keep the channel warm.
• Don't narrate every call — only the slow ones. A fast lookup should just resolve.
• Reuse the tools your text agents already use. A voice skill and a text skill can share the same functions and MCP servers; voice is a new interface, not a new backend.

A UX checklist for full-duplex voice skills

Run every voice skill against this before you publish it:

• Barge-in stops speech mid-word — measured, not assumed.
• Interruptions re-plan — the agent uses what it heard during the interruption, not the pre-interruption plan.
• Backchannels fire on pauses, not on every gap — and are sub-word-length.
• Silence is allowed — no re-asking or filler within the first real beat after a question.
• Slow tool calls have cover behavior — the agent signals it's working; fast ones resolve silently.
• No backchannel during delegation — the agent never implies it's done before it is.
• Turn-end detection distinguishes "done" from "thinking" — a complete thought gets a response; a trailing thought gets patience.
• The whole loop fits the latency budget — backchannels and barge-in are worthless if the round trip drags.
• Graceful downgrade — if the full-duplex path is unavailable, the skill still works turn-by-turn instead of breaking.

Tuning restraint on the Realtime API

The Realtime API exposes a reasoning effort knob — minimal, low, medium, high, xhigh, with low as the default as of the July 6 gpt-realtime-2.1 release. For conversational UX, effort and restraint interact: higher effort means better answers but more time before the agent speaks, which stresses your silence and barge-in design. A reasonable default is to keep effort low for the conversational layer and escalate only for the specific sub-tasks that need it — the same "delegate the hard part" pattern GPT-Live uses when it hands off to a frontier model.

Conversational layer:   reasoning effort = low   (fast, responsive, backchannel-friendly)
   └─ hard sub-task:     escalate to higher effort / frontier model, with cover behavior

The point is to protect the feel of the conversation. Every millisecond you spend reasoning at the top level is a millisecond the user is waiting, and waiting is exactly what full-duplex was supposed to end.

Where this goes next

Full-duplex resets the baseline. A year ago, a voice skill that answered your question was impressive. Now the bar is a skill that knows when not to answer — that acknowledges, waits, yields, and works in the background without breaking stride. Those are design decisions, and GPT-Live just made them table stakes.

Start by auditing an existing turn-based flow against the checklist above, then rebuild it on the Realtime API primitives. If you want the broader map of how the consumer app and the API differ, the consumer-vs-API breakdown is the place to start, and the full ChatGPT Voice series walks the rest. When you're ready to ship, the agents and workflows channels are where voice-first skills will live — and the ones that nail restraint will be the ones people actually keep talking to.