Answering Machine Detection (AMD) for AI Outbound Voice Agents

Quick Answer

Answering machine detection (AMD) analyzes the first 1-3 seconds of audio after a call is answered to classify it as a live human or an automated answering machine/voicemail system, before connecting it to an agent. Tone-based AMD looks at silence/energy patterns and typically hits 85-90% accuracy; ML-based AMD additionally analyzes greeting length, cadence, and speech patterns, reaching 93-97%. For an AI outbound voice agent, AMD determines whether the agent starts a live conversation or triggers a voicemail-drop script instead — get the tuning wrong and you either waste agent minutes on greetings or misroute real prospects.

What Is AMD, and How Does It Work?

When an outbound dialer places a call, it doesn't know in advance whether the number will be answered by a human or by voicemail/an answering machine. AMD is the analysis step that runs immediately after answer to make that call — literally listening to the first few seconds of audio and classifying it before the dialer decides what happens next. The core signal tone-based AMD relies on is that human greetings ("Hello?") tend to be short, followed by silence while they wait for a response, whereas machine greetings tend to be longer, uninterrupted, and often end in a distinctive beep.

That signal is noisy — some people answer with a long greeting, some voicemail systems have short generic greetings — which is exactly why AMD accuracy tops out below 100% no matter how it's implemented, and why the false-positive/negative tradeoff below is a deliberate tuning decision, not a bug to eliminate.

Why AI Voice Agents Need AMD More Than Human Agents Do

A human agent can instantly recognize a voicemail greeting and hang up or leave a message — that judgment is nearly free for a person. An AI voice agent has no equivalent instinct unless AMD does the classification first: without it, the agent will happily start a full conversational turn against a voicemail greeting, burning STT/LLM/TTS costs and, worse, sometimes triggering the agent to talk over the voicemail beep and record garbled audio as a "message." At scale — thousands of outbound calls a day — the AI-minutes wasted on misrouted voicemail conversations is a real, measurable cost line, which is why AMD sits upstream of the AI pipeline in a well-architected outbound stack, not inside it.

Tone-Based vs. ML-Based Detection

Platform & Provider AMD Benchmarks

AMD accuracy varies noticeably across dialer platforms, since each vendor tunes its classifier against a different mix of caller demographics, carrier audio quality, and default thresholds. These are illustrative industry ranges, not guaranteed figures — always validate against your own call recordings before trusting a vendor's marketing number:

The gap between open-source defaults (85–91%) and a custom-trained classifier (94–98%) is almost entirely a function of how much labeled call data you feed into tuning — not a limitation of Asterisk or FreeSWITCH themselves.

False Positive / Negative Tradeoffs

Every AMD tuning decision trades one error type for the other — there is no setting that minimizes both simultaneously:

• False positive (human misclassified as machine) — the agent hangs up on or diverts a real prospect to a voicemail-drop script, silently losing a connected lead. This is the costlier error for high-value outbound sales campaigns.
• False negative (machine misclassified as human) — the AI agent starts a live conversational turn against a voicemail greeting, wasting STT/LLM/TTS cost and sometimes producing a garbled recorded 'message.' This is the more tolerable error for low-cost-per-minute campaigns.
• Longer analysis windows (2–3s) improve accuracy but increase answer-to-response latency, which worsens perceived call quality and interacts directly with TCPA abandonment-rate exposure (see below).
• The right tuning point depends on your economics: a $50,000 enterprise sale lead is worth erring toward fewer false positives even at higher AI-minute waste; a low-margin high-volume campaign should tune the other way.

The Real Cost of AMD Errors: A Worked Example

AMD tuning decisions feel abstract until you run the actual numbers for your own call volume. Take a mid-size outbound campaign: 10,000 dials/day, a 40% answer rate (4,000 answered calls/day), and a mixed tone+ML AMD setup running at 95% accuracy (5% combined error rate):

At a $200 average lead value, 40 silently lost prospects a day is $8,000/day in missed pipeline — dwarfing the roughly 40 minutes/day of wasted AI-agent compute from false negatives, which at typical STT/LLM/TTS pricing runs closer to $2–5/day. This is precisely why most high-value outbound sales campaigns tune AMD conservatively toward fewer false positives even though it means talking to more voicemail greetings: the asymmetry in what each error type actually costs is large, and it should drive your threshold choice, not an abstract "maximize accuracy" goal.

Asterisk: The AMD() Dialplan Application

Asterisk ships a built-in AMD() application that performs tone/energy-based detection directly in the dialplan, setting the channel variable AMDSTATUS to HUMAN, MACHINE, or NOTSURE, along with AMDCAUSE explaining which heuristic triggered the classification. Its parameters (initial silence, greeting duration, after-greeting silence, total analysis time) are tunable per-call, which is what lets you shift the false-positive/negative balance without touching application code.

FreeSWITCH: mod_avmd

FreeSWITCH's equivalent is mod_avmd (Advanced Voicemail Detection), which listens on a channel and fires an event once it classifies the call, rather than blocking dialplan execution the way Asterisk's synchronous AMD() does. This event-driven model fits naturally into an ESL-based outbound stack (see our FreeSWITCH ESL with Node.js guide), where your dialer already listens for channel events and can route on avmd::start_talking / voicemail-beep events the same way it handles any other call-state transition.

Runnable Dialplan & Routing Code

extensions.conf — Asterisk AMD + routing

[outbound-ai-agent]
exten => _X.,1,NoOp(Outbound AI agent call, AMD first)
 same => n,Answer()
 same => n,AMD(2500,1500,500,5000,120,50,5,256)
 same => n,GotoIf($["${AMDSTATUS}" = "HUMAN"]?live:machine)
 same => n(live),AudioSocket(${UNIQUEID},127.0.0.1:9999)  ; -> AI agent pipeline
 same => n,Hangup()
 same => n(machine),Playback(voicemail-drop-message)
 same => n,Hangup()

dialer.py — pacing-aware AMD result handler

def on_amd_result(call_id: str, status: str, elapsed_ms: int):
    """AMDSTATUS: HUMAN, MACHINE, or NOTSURE. Feed timing back into pacing."""
    metrics.record_amd_latency(elapsed_ms)

    if status == "HUMAN":
        route_to_ai_agent(call_id)
        campaign.mark_connected(call_id)     # counts toward abandonment math
    elif status == "MACHINE":
        play_voicemail_drop(call_id)
        campaign.mark_machine(call_id)       # does not count as "abandoned"
    else:  # NOTSURE
        # Conservative default: treat as human to avoid losing a real lead,
        # accepting the AI-minute cost of a possible voicemail greeting.
        route_to_ai_agent(call_id)

AMD, Pacing & TCPA Abandonment

AMD latency directly affects your abandonment-rate exposure under TCPA (see our TCPA compliance guide): a call only counts as "connected" once routed past AMD to the AI agent, so a 2-3 second AMD window adds directly to the answer-to-connect delay the FCC's 3% abandonment cap is measuring. A dialer that paces ahead assuming instant connection, without accounting for AMD's classification window, will systematically over-pace and breach abandonment limits even if every individual call is legitimate. The fix is to feed AMD's measured latency (not an assumed constant) back into the pacing algorithm in real time, the same way you would feed back an AI agent's session-spin-up latency.

Industry-Specific AMD Considerations

AMD tuning isn't one-size-fits-all — the right false-positive/negative balance depends heavily on what industry the outbound campaign serves and what regulatory regime governs it:

• Debt collection — Regulation F and the FDCPA both create documentation obligations around contact attempts; collectors typically tune AMD conservatively toward fewer false positives to avoid disputes over calls that were answered by a person but logged as a missed machine contact.
• Healthcare appointment reminders — a missed reminder is a low-severity outcome, so healthcare campaigns often accept a faster, slightly less conservative AMD pass in exchange for lower latency and a snappier caller experience.
• Political and non-profit calling — many robocall restrictions carve out exemptions for political speech, but AMD tuning still matters operationally: misrouting live respondents to a canned message wastes get-out-the-vote or fundraising touchpoints at exactly the volume where they're hardest to recover.
• B2B sales outreach — higher per-lead value generally justifies tuning toward fewer false positives, accepting more wasted AI-agent seconds on voicemail greetings as the cheaper failure mode (see the cost math above).
• Insurance and financial services — compliance-recording requirements mean every AMD decision and its outcome should be logged with the same rigor as the call itself, since an auditor may later ask why a specific call was routed the way it was.

Tuning Checklist

• Start with vendor-default AMD thresholds, then tune against a sample of your own recorded calls — generic tuning from documentation rarely matches your actual caller demographics
• Track false-positive and false-negative rates separately in production, not just an aggregate 'AMD accuracy' number
• Feed measured AMD latency into the pacing algorithm rather than assuming a fixed constant
• For NOTSURE results, default to routing as human unless your economics clearly favor the opposite (see tradeoffs above)
• Re-tune quarterly — carrier audio codec changes and caller demographic shifts both degrade AMD accuracy silently over time
• Log every AMD decision with the resulting call outcome so misclassifications can be audited and used to retrain ML-based models

Testing AMD Before Production

Vendor-quoted accuracy numbers are measured against the vendor's own test set, which rarely matches your caller demographics, carrier mix, or regional accent distribution. Before trusting any AMD configuration in production:

• Build a labeled test set from your own recorded calls — at least a few hundred real answered calls, manually tagged as human or machine, covering your actual caller mix.
• Measure precision and recall separately for each class, not just an aggregate accuracy percentage — a 95% accuracy figure can hide a much worse false-positive rate specifically, which is usually the costlier error (see the cost math above).
• Run threshold sweeps — testing AMD at multiple silence/greeting-duration settings against the same labeled set — to find where your specific false-positive/negative tradeoff sits before committing to a production default.
• Re-run the test set periodically — carrier codec changes, caller demographic shifts, and voicemail-greeting trends (e.g. more people using short AI-generated greetings) all silently erode AMD accuracy over months, not just at initial deployment.
• A/B test threshold changes in production on a small traffic slice before rolling out campaign-wide, since real-world call quality and background noise are never fully captured by an offline test set alone.

FAQ

Related Reading