Two Very Different Categories of AMD

If you're shopping for answering machine detection in 2026, you'll run into two fundamentally different kinds of product, and conflating them is the most common mistake buyers make:

  1. Cloud voice API AMD — the machine detection built into general-purpose voice platforms like Twilio, Vonage, and Telnyx. You get it as a parameter on a call (MachineDetection=Enable in Twilio's case) as part of a much broader programmable voice product.
  2. Purpose-built AI AMD — software built specifically to solve the AMD problem for dialers, usually plugging directly into VICIdial or Asterisk, trained specifically on greeting patterns rather than being a feature bolted onto a broader voice API.

Both categories claim high accuracy numbers. Both will work, in the sense that they'll return a "human" or "machine" classification. The difference that actually matters is what happens in the 10-20% of cases where the classification is wrong, and how much control you have over tuning it for your specific lead mix. Here's how to evaluate the options like a buyer, not just compare marketing pages.

The Comparison Framework

Criteria Cloud Voice API AMD (Twilio/Vonage/Telnyx) Purpose-Built AI AMD
Deployment Requires routing calls through their voice infrastructure Plugs into your existing Asterisk/VICIdial trunk, no carrier lock-in
Pricing model Per-minute or per-call fee, bundled with their voice API usage Usually flat/tiered pricing independent of your carrier choice
Accuracy claims Vendor-published, often 85-97% depending on provider and settings Vendor-published, should be independently verifiable against your own call recordings
Tuning control Limited — mostly on/off, sometimes a timeout parameter Often tunable per-campaign or per-lead-source
Carrier independence Locked to their platform's call routing Works regardless of which SIP trunk provider you use
Latency Adds their processing time before webhook fires Depends on implementation, but built specifically to minimize detection-to-connect delay
Best fit Teams already fully built on that voice API for other reasons Teams running VICIdial/Asterisk who want AMD as a dedicated, swappable component

Questions to Ask Any AMD Vendor Before You Sign

Regardless of which category you're evaluating, these are the questions that separate a real evaluation from a sales-page comparison:

1. What's your false positive rate, and how was it measured? Ask specifically about false positives (human misclassified as machine), not just overall accuracy — a vendor can post a high overall accuracy number while still having a high false positive rate if false negatives are rare in their test set. Ask for the methodology, not just the number.

2. Can I test it against my own call recordings before buying? Any AMD vendor confident in their numbers should let you run a batch of your own recorded calls (with consent/compliance handled) through their engine and compare the output against manual QA. If a vendor won't do this, treat their accuracy claims as unverified.

3. How does the engine handle voicemail greeting variety? Bilingual greetings, corporate voicemail systems, cell carrier default greetings, and short "leave a message" clips all behave differently acoustically. Ask specifically how the vendor's model was trained — a model trained mostly on US carrier defaults may perform noticeably worse on greeting styles common in South Asian or Gulf-region carriers, which matters a lot if you're calling internationally or running BPO operations across multiple regions.

4. What's the detection latency? The time between "call answered" and "AMD decision" directly affects how natural the connect feels to a live human. Too slow, and a live answer sits in silence long enough to hang up before your agent is bridged — which also, incidentally, looks identical to a spam call to the recipient and can hurt your caller ID reputation over time.

5. Does it work with my existing dialer, or does it require a migration? This is the single biggest practical differentiator. Cloud voice APIs generally require your call flow to run through their platform. If you're already deep into a VICIdial setup with an existing SIP trunk relationship and don't want to re-platform your entire voice infrastructure just to get better AMD, a purpose-built AMD layer that integrates into your existing Asterisk stack is the lower-risk path. We cover what that integration actually looks like in our VICIdial AMD integration guide.

6. What happens when the AMD engine is uncertain? Every AMD system has an ambiguous middle ground — greetings that are hard to classify confidently either way. Ask what the default behavior is in that zone (routed to agent? treated as machine? flagged for review?) — this default has a real cost either direction, per the false positive cost framework we've written about separately.

A Note on Asterisk's Native AMD

If you're currently running Asterisk's built-in AMD (the AMD() application) with no third-party layer, you're the baseline this whole comparison is measured against — and it's worth knowing where that baseline actually sits before you evaluate paid options. We did a direct breakdown of Asterisk's native AMD vs. AI-powered AMD if you want the specific accuracy gap.

Making the Call

If your operation is already fully committed to a cloud voice API for other reasons (SMS, video, a broader CPaaS relationship), their bundled AMD is a reasonable default to start with — just go in with realistic expectations on the accuracy ceiling and make sure you can pull your own QA sample to verify it.

If your core stack is VICIdial or Asterisk and AMD is the actual problem you're trying to solve — not a side effect of a bigger platform migration — a purpose-built AMD layer will almost always outperform a general-purpose API's bundled detection, because that's the one thing it was built to do well.

That's the category amdify.io sits in. It's built specifically to plug into VICIdial and Asterisk-based dialers without requiring you to change carriers or re-platform, and it moves AMD false positive rates from the 15-25% range typical of Asterisk's default engine down to 1-3%. If you're mid-evaluation and want to run it against your own call recordings before deciding, amdify.io is worth including in the comparison.