Build1 distinct publisher3 min readPublished
A telephony rewrite took response times from 2,500ms to under 1,800ms. Most of the delta came from one detection change, and a single CRM lookup can still undo all of it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Start with the arithmetic the post does not print. Moving from 2,500ms to under 1,800ms is a cut of at least 700ms, roughly 28 percent [14]. Replacing an 800ms silence timer with a neural voice activity detector that declares end-of-turn after 280ms accounts for 520ms of that on its own [6][16] - about three quarters of the whole improvement [16]. Nothing in that decision is a model decision. It is a decision about when you are permitted to believe the caller has finished.
The tuning is where the risk lives. A 280ms minimum silence window is fourteen frames at 20ms apiece, and the three frames of prefix padding retain 60ms of audio ahead of speech onset [17]. The detector opens at 0.65 and closes at 0.35, a hysteresis band 0.30 wide [7][21], which is what stops the state machine flapping inside a word. Shah says the shorter window did not produce false cutoffs when callers paused mid-thought [6]. That is a single-sourced claim with no error rate attached, and it is the one number a buyer would most want.
The savings also do not add up, and that is informative rather than damning. The two published wins are 520ms on turn detection and 600ms on time-to-first-audio [6][9], which together come to 1,120ms against a headline delta of 700ms [18]. Overlapping stages behave that way: a saving on one stage disappears behind another that is still running, and the author separately lists jitter on cellular networks, variance in LLM response time and buffering in TTS output as real-condition overhead [12]. The per-stage budget table the post refers to is not present in the text we were given [13], so the route to under 1,800ms cannot be reconciled line by line.
Then there is the path that undoes everything. A standard tool-calling roundtrip to check technician availability or look up an address routinely added 1,100ms [10]. Bolted onto a 1,800ms turn, that is 2,900ms, which is 400ms worse than the prototype the rewrite replaced [19]. Every hang-up the architecture fixed comes back the moment the agent has to ask the CRM anything. Shah says he implemented speculative pre-fetching, but the account we have breaks off mid-sentence [11], so what the system does when the speculation is wrong is not on record.
The barge-in handler is the part that should reshape a vendor shortlist. When speech is detected while the agent is speaking, the code clears the audio output buffer and aborts the in-flight generation before returning to listening [8]. That requires a text-to-speech stream you can flush and a model you can cancel. A faster model you cannot interrupt is worse on a phone call than a slower one you can, because the caller talking over stale audio is the failure everyone remembers.
And the ceiling stays where it was. Human turn gaps run 200 to 300ms, with 600ms already feeling awkward [3]. Under 1,800ms is three times the awkwardness threshold and six to nine times a natural gap [20]. The rewrite bought a caller who stays on the line. It did not buy conversation.
Ranked by verification strength, evidence, and original report placement.
Instead of waiting for full LLM completion, a boundary detector splits streamed tokens on clause punctuation and dispatches the first clause to TTS immediately, so the caller hears the first word within about 600ms of the LLM receiving the prompt rather than waiting 1,200ms for the full sentence.
The author states that speculative pre-fetching was implemented, but the supplied text breaks off mid-sentence at "while the user is still", so the mechanism is not described.
Parvej Shah describes building the telephony dispatcher for Minions.AI, a voice-based service dispatch platform for trade contractors; the piece ran on dev.to and originally on his own blog.
In human conversation the natural gap between one speaker finishing and the other beginning is around 200 to 300 milliseconds, and anything beyond 600ms starts to feel awkward.
The original design waited for 800ms of audio silence before assuming the caller had finished; it was replaced with a WebRTC-compatible neural voice activity detection model running on 20ms audio frames that reads prosodic completion, dropping end-of-turn detection to 280ms without causing false cutoffs when callers paused mid-thought.
The post refers to a stage-by-stage latency budget for the original sequential design, but the budget itself is not present in the supplied text.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed code, self-reported numbers, missing budget
The post supplies unusually concrete artifacts for a single-source claim: a VAD config with five named parameters, a barge-in handler, a clause-splitting TTS streamer, and an interim-transcript prefetch listener. But every performance number is self-reported by the builder, the two promised stage-by-stage latency budgets are absent from the text, the stage savings do not reconcile with the end-to-end delta, no tail latency or sample size is given, and no vendor, model, repository, or third party is available to check any of it.
One self-reported deployment, no external signal
The only adoption signal is the author's own statement that the rewritten dispatcher runs on real phone calls for Minions.AI. There is no second deployment, no customer or call-volume figure, no release or repository, and no independent user. Techniques described (neural VAD, clause-boundary streaming, speculative tool prefetch) are presented as in-house implementation rather than a distributable artifact others have picked up.
Moderately overstated against its own arithmetic
The framing - a conversation-grade voice agent - runs ahead of what the published numbers show. The result is three times the author's own 600ms awkwardness threshold and six to nine times the human turn gap, the two disclosed stage savings sum to 1,120ms against a 700ms end-to-end improvement, the supporting budget tables never appear, and an uncached CRM lookup at 1,100ms would put a turn at 2,900ms - worse than the prototype. The gap is moderate rather than severe because the mechanisms are genuinely specified in code and the headline claim is stated as a median bound, not a best case.
Builder promoting own product and profile
The piece is written by the engineer who built the system, about the commercial platform he built (Minions.AI), syndicated from his personal consulting blog to dev.to with no editorial review, and closes with a professional bio positioning him as a platform architect. Favourable latency and conversion numbers advance both the product and the author's practice, and no adverse metric (false cutoffs, prefetch misses, tail latency, cost) is reported.
Mechanisms credible, magnitudes unverified
Confidence is moderate-low. The architectural mechanisms are described precisely enough to be assessed and are internally coherent, so the qualitative claim - that turn-taking and tool scheduling dominate perceived voice-agent latency - is reasonably well grounded. The specific magnitudes rest entirely on one self-interested source with missing budget tables, absent tail statistics, and no corroboration, so the numeric claims should be treated as indicative only.
build
Three services you can delete: queue, cache and search in one Postgres1 distinct publisher
build
The /userinfo fallback that quietly made Auth0 a hard dependency on every request1 distinct publisher
build
Budgets that fail the build, not dashboards: where the sample Magento CI thresholds leak1 distinct publisher
build
Four control planes, one Postgres: a team's case against polyglot persistence1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026