Compare
PyAI AMD vs Twilio Answering Machine Detection
Twilio AMD answers one question, person or machine, and it is good at that question. The problem is that an AI now answers the phone before the person does, and Twilio's AnsweredBy field has no value for it. PyAI AMD returns screening as its own outcome, caught 45 of 45 Google Call Assist screeners on real harvested calls with zero false fires across 182 human calls, and attaches the reason to every decision. One line of TwiML.
The category shift
The phone tree changed. The 2015 question didn't.
Answering-machine detection was built to ask: person, or machine? Twilio's default answers it by watching how long the far end talks, and calls it a machine once speech runs past 2400 ms. That is a sound proxy for a voicemail greeting, which runs long and never yields. An AI screener does the exact opposite: it says one short line, hands the turn back, and waits for you. The mechanism that makes greeting-length detection work is the mechanism that makes a screener invisible to it, and there is no value in the enum to report it with even if it noticed. Read the screening row first.
| PyAI AMD | Twilio AMD | |
|---|---|---|
| An AI screener answeredThe shift | screening, its own outcome. 45 of 45 on real harvested Google screeners, 0 false fires across 182 human calls | No such value exists. AnsweredBy is human, machine_start, machine_end_*, fax, unknown |
| How machine gets decided | Words, tones and timing, fused. A short line that yields the turn is still catchable | Speech that runs longer than MachineDetectionSpeechThreshold, 2400 ms by default |
| Why it decided that | A reason on every call, quoting what it heard and when | One label, no reason |
| Dead or disconnected number | sit_invalid with dead_number, off the carrier's intercept announcement | No value for it in AnsweredBy |
| Hold music with no words | machine with subtype music, off sustained tonal energy; cannot fire on anyone who spoke | No value for it in AnsweredBy |
| Operating point | One aggressiveness dial from 0 to 1, human-safe default, per account or per call | Four MachineDetection* timing parameters |
| Speed vs the answer | About 940 ms earlier at the median than Twilio AMD on the same 200 real calls (our measurement, not an SLA) | No detection-latency figure published; MachineDetectionTimeout defaults to 30 s |
| Migration | One line of TwiML, your carrier and routing unchanged | n/a |
Every Twilio cell is from Twilio’s published AMD documentation: the AnsweredBy values and the MachineDetection* parameter defaults, as of writing. Our figures are our own measurements on real customer traffic, not an SLA. Twilio AMD is also tunable through its MachineDetection parameters; the difference here is what the label can express, not whether it has knobs.
When to switch, and when Twilio AMD is fine
Switch to PyAI AMD when
Switch- Calls are being answered by an AI that asks who's calling before a person picks up
- You have had caller-ID numbers flagged as spam
- You run live agents and cannot afford to drop a real prospect
- You want to know why a call was classified the way it was
- You are burning retries on numbers that are already dead
Twilio AMD is fine when
Stay- You only need person versus machine, and it is good at that
- You are already deep in the Twilio stack and it is working
- You have not seen AI screeners in your traffic yet
We are not going to tell you Twilio AMD is bad. It answers the question it was built for, and if that is your question you should keep it. We built this for the calls where the answer is not a person or a cassette.
Move off Twilio AMD in one line
Already on Twilio? Point one line of TwiML at PyAI and keep your carrier and your code. Theanswered_by_twiliofield speaks Twilio’s exact vocabulary, so your routing logic does not change.
<Response>
<Start>
<Stream url="wss://api.pyai.com/v1/amd/stream">
<Parameter name="api_key" value="YOUR_PYAI_KEY"/>
<Parameter name="aggressiveness" value="0.25"/>
<Parameter name="webhook" value="https://you/amd-events"/>
</Stream>
</Start>
<!-- Standalone test: replace this pause with your existing call flow. -->
<Pause length="30"/>
</Response>Pricing is simple and public: 5,000 answered calls free every month, then $0.004 per answered call, and free when the call already runs on PyAI telephony. You only pay when a call is actually answered.
FAQ
What is the difference between PyAI AMD and Twilio AMD?
Twilio AMD answers one question: person, or machine? Its AnsweredBy field returns human, machine_start, fax or unknown, and with DetectMessageEnd it adds machine_end_beep, machine_end_silence and machine_end_other. There is no value in that list for an AI screener, a dead number, or hold music, so those calls come back as something else with no explanation. PyAI AMD returns screening, voicemail, ivr, music and dead_number as distinct outcomes, attaches the reason it heard to every decision, and still speaks Twilio's exact enum through answered_by_twilio so your routing does not change.
Why can't Twilio AMD see an AI screener?
It is a design consequence, not a bug. Twilio's documented default decides machine when the far end keeps speaking past MachineDetectionSpeechThreshold, 2400 ms. That is a good proxy for a voicemail greeting, which runs long. An AI screener does the opposite: it says one short line, then hands the turn back and waits for you, exactly like a person would. The mechanism that makes greeting-length detection work is the same mechanism that makes a screener invisible to it. Screeners announce themselves in words instead, which is why we detect them lexically.
How hard is it to switch from Twilio AMD?
One line of TwiML. Point the call's media at wss://api.pyai.com/v1/amd/stream and keep your carrier and your code. PyAI AMD speaks Twilio's Media Streams protocol natively, and the answered_by_twilio field maps to Twilio's exact AnsweredBy enum, so your routing logic does not change on day one. Read subtype when you are ready to act on screening, IVRs and dead numbers.
Will it hang up on a live person?
That is the only failure that costs you a customer, so the design is bent around it. A false machine on a human is catastrophic; a false human on a machine costs your agent one second of voicemail. In our side-by-side on 1,341 real calls where both engines committed to an answer, Twilio AMD marked a live person as a machine 6 times; PyAI AMD did 0. We publish the number rather than claim never. When the window expires with nothing decisive, the human-safe default returns unknown and lets the agent listen instead of guessing machine.
Is PyAI AMD faster than Twilio AMD?
On the one side-by-side we have run, yes: 200 real answered calls replayed at real-time pace through the live endpoint, PyAI's decision landed about 940 ms earlier at the median than Twilio AMD's recorded decision on the same calls, and about 1.5 s earlier on calls a person answered. That is our measurement on one run, not an SLA, and Twilio publishes no detection-latency figure to compare against. Every PyAI decision carries decision_ms so you can check it on your own traffic.
Why does call screening matter for a dialer?
Google Call Assist and iPhone Call Screening answer unknown calls with an on-device AI before the person picks up. If your AMD has no outcome for it, your agent runs the pitch into a transcript that nobody hears, and your numbers pick up spam flags. That reputation hit compounds across every number in the rotation, which is a far bigger cost than a wasted agent-second.
How much does PyAI AMD cost versus Twilio AMD?
PyAI AMD is billed per answered call: the first 5,000 answered calls each month are free, then $0.004 per answered call, and it is included at no charge when the call already runs on PyAI telephony. Calls that are never answered are never billed. Twilio prices AMD separately from the call itself. Check both vendors' current published pricing before procurement, ours included.
Dial a screened number. See what comes back.
A free key and one line of TwiML. Point one call at it, read the reason, and decide from there. No card.