Answering Machine Detection for Voice AI: Accuracy and Costs
Answering machine detection decides in the first seconds of an outbound call whether your voice AI talks to a person or a recording. How it works, real accuracy numbers, costs, and how to audit it yourself.

Every outbound voice AI campaign has a sorting problem: a large share of answered calls reach a voicemail greeting or an IVR menu, not a person. Answering machine detection (AMD) is the component that decides, within the first few seconds of audio, which one your agent is talking to. Get it right and your agent only spends money on live conversations. Get it wrong and you hang up on real people who answered the phone, which is the most expensive error an outbound system can make.
This post covers how AMD works, what the published accuracy numbers actually show, how to audit your own false positive rate, what detection costs at real volumes, and where the compliance rules bite. It is written for teams choosing or tuning an outbound stack, whether that is a managed API like Twilio, an agent framework like LiveKit, or an open-source dialer like Asterisk.
What answering machine detection decides in the first seconds of a call
When an outbound call connects, the audio that arrives in the first one to five seconds looks like one of four things:
- A human greeting. Short and variable: "hello", "yeah, who's this", "speaking". Usually under two seconds of speech, often followed by silence while the person waits for a response.
- A voicemail greeting. Long and structured: "Hi, you've reached Sarah, leave a message after the tone". Often 15 to 40 seconds, ending with a beep.
- An IVR menu. "Press 1 for sales, press 2 for support". Structured speech with pauses, followed by DTMF tones if you navigate it.
- Nothing useful. Fax tones, carrier messages ("the number you have dialed..."), dead air.
The detector's job is to classify that opening audio and tell the call logic what to do next: start the agent conversation, wait for the beep and leave a voicemail, navigate the menu, or hang up and log the outcome. Modern systems return one of five categories: human, voicemail, IVR, unavailable, or uncertain, and the safe convention is to treat uncertain as human, because the asymmetry of the errors matters more than raw accuracy (as LiveKit's AMD documentation puts it, the worst failure mode is misclassifying a human as a machine).
That classification has to happen fast. A person who answers a call and hears three seconds of silence assumes it is a scam call and hangs up. Every 100 milliseconds of detection delay is time the greeting is playing and the other side is deciding whether to stay on the line.
How AMD works: three generations of detection
Generation one: timing heuristics
The original approach, still shipped as the AMD() application in Asterisk, reasons purely about timing. It measures the length of the initial silence, the length of the greeting, and the silence after the greeting. Short greeting followed by silence means human. Long greeting means machine. The Asterisk AMD documentation lists the tuning knobs directly: initialSilence, greeting, afterGreetingSilence, totalAnalysisTime, maximumNumberOfWords, and a few others, and the verdicts it returns (MACHINE, HUMAN, NOTSURE, HANGUP) come with a cause code like TOOLONG or INITIALSILENCE that tells you which rule fired.
This is free, runs anywhere, and decides in one to two seconds. It is also brittle. A person who answers with "hello... hello?" breaks the silence rule. A short voicemail greeting ("leave it after the beep") looks exactly like a human. Rules tuned against one carrier's audio characteristics break on another. Reported real-world accuracy for tone-based heuristics sits around 85 to 90 percent in vendor comparisons, such as CelloIP's overview, and the error concentrates exactly where it hurts: ambiguous, real human answers.
Generation two: acoustic machine learning
Instead of hand-set timing thresholds, these systems feed the audio's spectral features (MFCCs, spectrograms, or learned audio embeddings) into a trained classifier. A 2024 paper in the Journal of Artificial Intelligence Research and Applications combined a YAMNet audio embedding model with a small recurrent network over 960 millisecond frames and reported 96.67 percent accuracy on its own test set, rising to 98.10 percent when a silence detector was added (arXiv:2410.08235). Treat those numbers as upper bounds from a controlled dataset of roughly 4,200 clips, not as production guarantees.
A more production-oriented result came from ClearGrid in April 2026: fifteen temporal features extracted from a pre-trained voice activity detector, fed into a shallow tree ensemble. It hit 96.1 percent on a mixed test set of 764 telephony recordings, and in validation over 77,000 production calls it produced a 0.3 percent false positive rate and a 1.3 percent false negative rate, with 46 millisecond inference on a commodity dual-core CPU and no GPU (arXiv:2604.09675). Two details from that paper are worth internalizing: the team searched over 3,780 model and feature combinations, and adding transcript keywords or beep-detection features did not improve the best real-time configuration. And their constraints are the constraints everyone faces: detection must happen in the first three to five seconds, audio is 8 kHz narrowband, and the inference budget is under 100 milliseconds.
Generation three: transcribe and reason
The newest approach, used by LiveKit's built-in AMD and by several voice AI platforms, runs speech-to-text on the opening audio and hands the transcript (plus timing metadata) to a small LLM that classifies it. "Hi, this is Mark, leave a message" is trivially a voicemail once you can read it, regardless of how long it is.
LiveKit's engineering write-up describes the production shape of this: a short-circuiting fast path handles obvious cases, and only ambiguous transcripts pay the LLM classification cost, with whichever path concludes first winning. Their internal benchmark with the default pairing (gemini-3.1-flash-lite for classification, cartesia/ink-whisper for transcription) reports a voicemail F1 of 97.3 percent, human F1 of 95.7 percent, macro F1 of 97.0 percent, and a median time to detection of 840 milliseconds (LiveKit's AMD benchmark post). The framework also acts on the verdict: it can start DTMF navigation when it detects an IVR and stops the agent from talking over the voicemail beep.
The trade-off is cost and a dependency: you are paying for STT and a model call on every answered call, and you are trusting a vendor's classifier unless you self-host the stack.
Why the false positive is the expensive error
AMD makes two kinds of mistake, and they are not equal:
- False positive: a human is classified as a machine. The system hangs up on a live prospect, or starts leaving a voicemail message into a live ear. The person is lost and, if you call back, annoyed.
- False negative: a machine is classified as human. The agent talks to a voicemail greeting for a few seconds, realizes, and hangs up. You wasted some telephony and model minutes. Irritating, cheap.
A worked example with explicit assumptions. Say you run 50,000 outbound dials a month:
- Answer rate 40 percent: 20,000 answered calls.
- Of answered calls, 60 percent voicemail: typical for mobile-heavy B2C lists. That leaves 8,000 live humans.
- Heuristic AMD at a 15 percent false positive rate on humans: 1,200 live people get hung up on every month.
- Value per completed live conversation, $25: conservative for collections, appointment setting, or sales qualification. That is $30,000 a month in destroyed conversations.
- Modern ML AMD at a 1 percent false positive rate: 80 dropped humans, $2,000 lost.
The difference between the two detectors is $28,000 a month on these assumptions, against a detection cost measured in hundreds of dollars (see the cost section below). This is why the number to optimize is the false positive rate on live answers, not headline accuracy. A detector that is "95 percent accurate" by misclassifying 5 percent of humans as machines is far worse for you than one that is "93 percent accurate" but only ever errs toward calling things human.
It also means vendor accuracy claims need a question attached: accurate on which list, which carriers, which countries, measured how? The honest way to know is to measure your own traffic, which is the next section.
How to audit and tune your own AMD
You do not need a research lab to measure AMD accuracy. You need call recordings and an afternoon. The procedure below follows the audit method described by Amdify's tuning guide and generalizes to any stack:
- Pull a random sample of calls your AMD classified as MACHINE. Two hundred is enough for a usable estimate. Random matters: do not let anyone pre-filter.
- Listen to the first ten seconds of each recording. Count how many were actually answered by a human. That count divided by 200 is your estimated false positive rate.
- Pull a second sample of calls classified as HUMAN. Count how many were actually voicemail. That is your false negative rate, which affects cost rather than lost contacts.
- Break the errors down by segment. Mobile versus landline, carrier, time of day, and list source. Errors cluster. A detector that is fine at 10 a.m. may fall apart at 7 p.m. when people answer in noisy environments.
- Tune one knob at a time and re-audit. On heuristic systems that means the silence and greeting-length thresholds. On ML systems it means the confidence threshold at which you accept a machine verdict.
- If you can, run a holdout route. Send 10 to 20 percent of traffic with AMD disabled and have agents or reviewers code the true outcome. Comparing the MACHINE rate between the two routes tells you whether the detector itself is over-firing.
On tuning: LiveKit exposes thresholds like human_speech_threshold (default 2.5 seconds), machine_silence_threshold (1.5 seconds), and an overall AMD timeout (20 seconds), plus a prompt override you can use to bias detection toward region-specific voicemail phrasing. Asterisk exposes the raw timing parameters listed earlier. In both cases the same discipline applies: change one value, re-run the audit sample, keep what measurably lowers the false positive rate.
One more rule: treat "uncertain" as human everywhere. Configure it explicitly if your platform does not default to it. A few wasted voicemail conversations are always cheaper than hung-up prospects.
What AMD costs at real volumes
Detection cost has three parts, and the direct fees are the smallest of them:
- Per-call detection fees. Twilio charges $0.0075 per call where AMD is enabled and the called party answers, per its GA announcement. At 20,000 answered calls a month that is $150. Asterisk and FreeSWITCH AMD are free to run; you pay in tuning time and in the false positives discussed above.
- Model and transcription usage. LLM-based detection pays for STT on the greeting plus a small classification call. With lightweight models (the flash-lite class LiveKit benchmarks with), this is fractions of a cent per answered call, but it applies to every answered call, so it scales with volume.
- The downstream savings. This is the real line item. Without AMD, every voicemail burns agent talk time: a 30-second greeting at typical voice AI platform rates of $0.05 to $0.30 per minute. On 12,000 voicemails a month that is roughly $300 to $1,800 of pure waste, before counting the human-agent time in a blended operation. AMD eliminates almost all of it.
Put together: on the 50,000-dial example from earlier, direct AMD spend is roughly $150 to $400 a month depending on stack, against low-thousands in avoided voicemail minutes and tens of thousands in avoided false-positive losses. Detection is one of the cheapest insurance policies in an outbound stack. If you are modeling the full budget of an outbound agent, our breakdown of voice AI implementation costs shows where AMD sits relative to telephony, STT, LLM, and TTS spend, and the Kenya-specific numbers are in what a voice AI agent costs to run in Kenya.
Compliance rules that AMD touches
In the United States, AMD sits directly on top of two TCPA rules in 47 CFR 64.1200, and getting AMD wrong can put you on the wrong side of both:
- The abandonment rule. Section (a)(7) prohibits abandoning more than 3 percent of telemarketing calls answered live by a person, measured per campaign per 30-day period. A call counts as abandoned if it is not connected to a live sales representative within two seconds of the called person's completed greeting. A slow or false-positive-prone AMD that hangs up on live answers is, mechanically, an abandonment generator. The same section requires that unanswered calls play a prerecorded identification message with an interactive opt-out mechanism, and that you keep records proving compliance.
- The consent rules. Autodialed or artificial-voice calls to cell phones require prior express consent, and telemarketing with an artificial or prerecorded voice requires prior express written consent. The FCC's February 2024 Declaratory Ruling confirmed that AI-generated voices, including voice cloning, count as artificial voice under the TCPA (FCC 24-17). An AI agent that talks to the human after AMD says "human" is still an artificial voice for consent purposes.
Two practical consequences. First, AMD accuracy is not just an economics problem; persistent false positives on a telemarketing campaign can push your abandonment rate toward the 3 percent ceiling, which is a regulatory number, not a vibe. Second, AMD verdicts belong in your call records alongside consent evidence. If you cannot reconstruct why your system hung up on a live answer, you cannot demonstrate compliance.
Other jurisdictions have their own versions of these rules (the UK has Ofcom's silent and abandoned call limits, and Kenya's Data Protection Act governs consent for marketing contact), so treat this section as orientation, not legal advice, and have counsel review outbound campaigns in each market you dial.
When AMD is the wrong choice, and common mistakes
When you do not need it
AMD is a tool for outbound volume. Skip it when:
- Calls are inbound. Nobody leaves a voicemail on their own inbound call.
- Volume is low and value per call is high. If you place 50 considered B2B calls a day, let the agent handle the greeting like a human would: hear the voicemail prompt, leave a good message. The economics of detection do not move the needle.
- Your list is confirmed mobile numbers with high human answer rates. If 90 percent of answers are human, a detector mostly adds latency and false positive risk. Measure first with the audit procedure above.
Mistakes that keep recurring
- Optimizing headline accuracy instead of the false positive rate. As shown above, the error direction matters more than the total.
- Trusting vendor benchmarks without an own-traffic audit. Published numbers come from specific datasets. Your carriers, lists, and greeting phrasing are yours alone.
- Tuning once and walking away. Carrier audio changes, lists age, and greeting styles drift. Re-audit monthly, and validate across your full calling window, not just off-peak.
- Letting the agent talk before the verdict. If the agent starts speaking while AMD is still deciding, you get the worst of both worlds: talking over a human or leaving half a voicemail. Use the platform's wait-until-finished behavior (LiveKit defaults to it; Twilio's docs advise starting other call features only after the async AMD callback).
- Ignoring IVR detection. Reaching a company switchboard and hanging up wastes a reachable contact. Modern detectors classify IVR separately, and LiveKit can navigate menus with DTMF. If your stack cannot, route IVR hits to a human queue.
If you are wiring AMD into a broader outbound workflow (list management, retries, voicemail drops, CRM write-backs), that orchestration is where business automation earns its keep, and the telephony setup for Kenyan numbers specifically is covered in connecting voice AI to Kenyan phone numbers.
Frequently asked questions
How accurate is answering machine detection?
It depends on the generation. Timing-heuristic AMD runs about 85 to 90 percent in real traffic. Acoustic ML detectors report 95 to 98 percent on test sets, with one production validation showing a 0.3 percent false positive rate over 77,000 calls. Transcript-and-LLM detectors report macro F1 around 97 percent. Your number will come from auditing your own calls, not from any vendor's benchmark.
What is a good false positive rate for AMD?
Under 2 percent of live answers is a reasonable target for an ML-based detector; heuristic systems often run 10 to 20 percent. Measure it by listening to a random sample of calls your system classified as machines and counting the humans. Every false positive is a live contact you hung up on, so this is the metric to minimize.
Does Twilio charge for answering machine detection?
Yes. Twilio charges $0.0075 per call where AMD is enabled and the called party answers. Open-source alternatives like Asterisk AMD and FreeSWITCH mod_avmd have no per-call fee but need manual tuning and typically deliver lower accuracy out of the box.
What is the difference between AMD and voicemail drop?
AMD is detection: deciding whether a person or a machine answered. Voicemail drop is an action: when AMD says machine, the system waits for the beep and plays a prerecorded message instead of connecting an agent. AMD is the decision layer; voicemail drop is one possible response to a machine verdict.
Can AMD detect IVR menus, not just voicemail?
Modern detectors can. LiveKit's AMD, for example, returns a separate IVR category and can automatically navigate menus using DTMF tones. Legacy heuristic AMD generally cannot tell an IVR from a voicemail greeting and will treat both as "machine".
Does AMD work on mobile networks and outside the US?
It works, but mobile-heavy lists are the hardest case: compressed audio, background noise, and short informal greetings. Detection models are trained largely on specific carriers and languages, so audit accuracy on your own traffic per country. LLM-based detectors let you bias classification toward local voicemail phrasing with a prompt override, which helps in markets like Kenya.
Where to go from here
If you are evaluating outbound voice AI, start with the audit procedure above on any existing traffic so you know your baseline before you switch anything. If you are designing a new outbound operation (collections reminders, appointment confirmations, reactivation campaigns) and want an agent that handles detection, conversations, voicemail drops, and CRM updates as one system, that is what we build under our AI Employees service: an always-on voice agent, deployed and run for you, with the detection layer tuned and audited against your own call recordings.
Related reading
About AI Agents Plus Editorial
AI automation expert and thought leader in business transformation through artificial intelligence.



