
Why first: Seagull shows how transcription, streaming, drift and subjective evaluation make ordinary agent problems harder. Caryotakis follows by deciding which of those problems matter to the customer on the other end of a call.
A voice agent can have a strong model and still fail because it talks over someone, leaves a dead pause or hands a caller to a person with no useful context. Turn-taking sets the floor: the agent must know what the call should accomplish, when someone has finished speaking, and which interruptions should stop it. Latency then becomes a system problem. Speech recognition, model calls, synthesis and every network hop spend part of the same budget. Smaller models and state machines move decisions off the speaking path; colocated services recover more time. Intercom's support deployment then meets real callers. Monitoring, escalation and a useful context handoff decide whether the design can answer a real phone line rather than merely impress in a demo. The last talk shows why that monitoring has to hear the audio, because a clean transcript can hide a failed call.

Why first: Seagull shows how transcription, streaming, drift and subjective evaluation make ordinary agent problems harder. Caryotakis follows by deciding which of those problems matter to the customer on the other end of a call.

Why second: Seagull inventories the ways a voice agent can fail. Caryotakis makes a product choice among them: finish the conversation reliably before chasing a more realistic voice, then read the script aloud to find the awkward parts.

Why here: Caryotakis asks teams to design the conversation as spoken behavior. Shapland explains the mechanism that most often ruins that behavior: a serial pipeline that mistakes a short silence for the end of a turn.

Why here: Shapland explains why endpoint prediction is hard. Agrawal and Wirjo compare three ways to make that decision in a working pipeline, then show why a cough, an acknowledgement and a correction should not trigger the same response.

Why here: Agrawal and Wirjo settle how the user gets the floor. Sherbakov and Kotha widen the choice to the whole agent, weighing chained and speech-to-speech systems and delegating difficult work away from the frontline voice model.

Why here: Sherbakov and Kotha choose what runs inside the agent. DuBois and Kramer turn to the path between user and model, where ordered delivery, packet loss and jitter can make a fast architecture feel slow.

Why here: DuBois and Kramer fix the media path from the user's device. Bhargava budgets the delay that remains across speech recognition, the language model and speech generation, then shows what colocation and a thinker-talker split can save.

Why here: Bhargava keeps a small model on the conversational path and sends harder work elsewhere. Allou and Bahidika make the bargain concrete by moving lesson state into code so the speaking model can answer in time.

Why here: Allou and Bahidika move lesson state into code. Venky B makes the same move for what the caller says: a phone number or a date becomes a typed field with validation rules and a confirmation step, and the model's output is normalized before it reaches speech synthesis.

Why here: Venky B cleans what goes into the model and what comes out of it. Kiely finds the next constraint in speech serving, where first-byte latency and concurrent streams matter more than raw token speed, and careless client code can give the gain back.

Why here: Kiely gets the listening, thinking and speaking machinery into its latency budget. Bar puts it on a real support line, where short answers, filler speech, monitoring, escalation and a useful handoff decide whether callers keep using it.

Why last: Bar names monitoring as one of the things that decide whether a support line works. Ali shows what that monitoring has to hear. His refund call reads fine as a transcript, while the audio holds 2.4 seconds of dead air, the agent talking over the caller and a refund for the wrong order.