Nobody owns the 150ms: why voice-agent pilots pass demo and fail on interrupts

An analysis published on dev.to argues that AI voice agents perform well in controlled demonstrations but fail in real customer interactions on one specific dimension: handling natural human interruptions ^[1]. That matters for anyone mid-pilot, because a scripted demo is the single condition under which this failure mode cannot appear.

The teardown decomposes an agent into five interconnected modules, each introducing its own interrupt vulnerability ^[2]. Speech recognition runs in real time and is therefore delay-prone, and those delays propagate downstream into intent detection and response generation, so even minor transcription lag produces misinterpretation and late replies ^[3]. The interrupt detector relies on pattern recognition and fails in both directions: false positives, where a natural pause is read as a barge-in, and false negatives, where a genuine interruption is missed ^[4]. The first produces unnecessary pauses and clarification prompts; the second leaves the agent talking over the customer ^[5]. Turn management contributes "response inertia," where the agent keeps speaking through an interruption, or incorrect yields that create awkward pauses ^[7]. Response generation degrades on partial or aborted input and on sudden topic changes ^[8]. Context management typically holds three to five turns, which the author says invites "context bleed," where stale information shapes a fresh answer ^[6].

The number that binds all of this together is a stated requirement of sub-150ms latency to preserve the perception of natural turn-taking ^[9]. Divided evenly across the five modules the analysis names, that is roughly 30ms per stage ^[14]. Nothing in the module list is accountable for the total. The analysis assigns consequences stage by stage without naming an owner of end-to-end interrupt latency ^[16], which is exactly how a pilot arrives at five components individually within spec and a call that still feels wrong. Speech-to-text tuning, intent thresholds, and barge-in detection are usually different code, sometimes different vendors, and almost always different on-call rotations.

Three constraints amplify the problem rather than sitting alongside it. Overlapping speech and ambiguous corrections have to be resolved without asking for explicit confirmation ^[10]. Model generalisation limits handling of complex corrections, jargon, and domain-specific language, raising misinterpretation rates in specialised contexts ^[12]. And error recovery thresholds are finite: consecutive misinterpretations trigger human escalation, so interruption failures burn through the allowance quickly and hand the call back to a person, cancelling the efficiency case for the agent in the first place ^[11]. The author's conclusion is that the module interplay is fragile and that these constraints turn latent weaknesses into bottlenecks under real-world interruption ^[13].

Note the standing of this material: it is one analysis of architecture and consequence, presenting no measured field data ^[17]. Treat 150ms as the author's design target, not a benchmark you can cite to a vendor.

The procurement implication is straightforward. Stop accepting scripted turn-taking demos. Interrupt the agent a third of the way into a long utterance. Interrupt with a correction rather than a new question, since that is the case the response engine is said to struggle with ^[8]. Interrupt during a numeric readback. Then measure two things separately: time to silence, and time to a relevant new answer. Ask which single team owns the sum, and what the false-barge rate is on quiet pauses ^[4].

What to watch: whether any vendor starts publishing barge-in latency distributions and false-barge rates rather than averaged response times, and whether pilot teams begin tracing their human escalation counts back to interrupt events ^[11] instead of logging them as generic containment failures.