Why Voice AI Needs to Respond in Under 1.5 Seconds

The conversation latency floor

Human conversation operates on a tight rhythm. Studies of natural dialogue across languages put the typical response gap between speakers at 200 to 500 milliseconds. Anything longer and the conversation starts to feel off. Anything past 2 seconds, and the listener assumes the other party did not hear them.

For voice AI, this is not a UX preference. It is the line between a phone call that closes a deal and one the caller hangs up on.

Where the seconds disappear

A voice agent has to do four things between when the caller stops talking and when they hear a response. Detect end of speech. Transcribe the audio. Generate a response. Synthesize the response back into audio. Each step has its own latency budget, and a sloppy implementation in any one of them blows the whole budget.

Speech recognition

The transcription step needs to be streaming, not batch. A batch approach waits until the caller is fully done to start processing. A streaming approach processes as the audio comes in, so the transcript is ready within milliseconds of the caller finishing. On the same compute, that is the difference between 100 milliseconds and a full second.

Language model response

The model needs to produce the first token of the response fast. On dedicated infrastructure inside the same network as the rest of the pipeline, this is sub-second. On a remote AI API behind a public internet hop, it adds 200 to 500 milliseconds before any meaningful work has started.

Text to speech

Like recognition, this should be streaming. The first audio chunk should reach the caller before the full response has been generated. The caller hears the response start while the system is still composing the rest of it.

What Edah AI commits to

Edah AI holds end-to-end voice response under 1.5 seconds at the 95th percentile. Reaction to interruption is under 120 milliseconds. Both numbers are budgets, not aspirations, and they are measured on every release.

The path to those numbers is not a single optimisation. It is owning every layer of the pipeline, keeping every component in the same network, and treating latency as a product feature you can ship cuts to.