Answering machine detection (AMD) classifies the first seconds of an answered outbound call and decides whether a human picked up or the call reached a machine. For an unattended campaign or an AI voice agent, that classification is the difference between engaging a live person and paying an AI agent to talk to a voicemail greeting. This post covers when to enable AMD, what the verdict taxonomy means, and how the result reaches your campaign logic.
What AMD is and where it fires
AMD runs on the outbound leg of a call you originate through the `/api/v1/voice/calls` endpoint. You opt in per call by sending amd: true. With the flag set, detection happens in the first second or two after the call is answered, before an AI agent says anything or a campaign counts the attempt as connected. With the flag unset, the call behaves exactly as before: no classification, no extra events.
Three flows benefit most:
- Unattended outbound campaigns. A dialer placing thousands of calls cannot afford to treat every answered call as a conversation. AMD sorts answered calls into "bridge to the script" and "this was a machine" before your flow commits resources.
- AI-agent dialing. An AI voice agent starts consuming speech pipeline the moment the session opens. AMD lets the agent engage only when a human answered.
- Voicemail-critical flows. If your flow leaves a recorded message, you want to know it actually reached a voicemail box, and you want that fact in your webhook stream, not inferred from a hangup.
AMD is not relevant for click-to-call, where a human agent is on the originating leg and the far end is answered into an attended conversation anyway.
The verdict taxonomy
The classifier returns one of eight verdicts. They split into two branch groups:
| Verdict | Branch |
|---|---|
machine | drop |
machine_beep_detected | drop |
fax | drop |
ios_call_screening | drop |
ios_live_voicemail | drop |
human | continue |
no_answer | continue |
silence | continue |
Machine-side results end the call: there is no person to talk to, so the call is hung up and your campaign learns about it through the webhook event rather than a full call lifecycle. ios_call_screening and ios_live_voicemail are the Apple-specific cases: Apple's call screening answers on the callee's behalf, and Live Voicemail transcribes the greeting while the phone never rings to a person. Both are machine-side outcomes for an outbound campaign.
Human-side results continue the call normally. no_answer and silence sit on the continue side deliberately: a line that produced no detectable greeting pattern is not proof of a machine, so the call proceeds rather than being dropped on an ambiguous signal.
Your campaign logic reads the verdict from the webhook event described below; the taxonomy matters because "AMD on" is only useful if you branch on the specific verdict, not on a binary answered-or-not.
Why AMD matters for AI agents and compliance posture
Two costs show up when an AI agent runs without AMD.
The first is direct spend. Once the agent session opens, every second of a voicemail greeting is speech-to-text and model processing with zero chance of a conversation. Detection in the first second or two stops the session before that meter runs, so machine-answered calls cost a classification instead of a conversation.
The second is how your operation handles machine-answered calls at scale. A campaign that repeatedly connects an AI agent to voicemail greetings, or leaves long agent recordings in voicemail boxes, is a dialing-pattern question your compliance counsel will have an opinion on. Devotel Orbit gives you the control (amd: true per call, verdict-specific webhook branching) and leaves the posture to you: whether to drop machine verdicts, leave a message, or retry later is your tenant's configuration decision under your own legal guidance, not something the platform mandates.
The shipped surfaces
AMD is wired end to end, and each surface is documented:
- The API field.
amdis an opt-in boolean on POST /api/v1/voice/calls, defaulting to off. No setup, provisioning, or account flag is required. - The detection path. With the flag set, the call goes out over the Devotel softswitch with a detection marker on the SIP signaling; the classifier runs on the outbound leg and its verdict drives the drop-or-continue branch above.
- The webhook event. A machine-side verdict fires `call.hit_voicemail` with the specific
amd_typeverdict and adetected_attimestamp, before the hangup events. Campaigns use this event to log, retry, or branch instead of waiting for the call to end. - AI-agent outbound calls. The AI agent outbound calling doc covers the same flag from the agent side, including the
call.hit_voicemailbranch. - Dialer dispositions. Voicemail outcomes land in the disposition model; the dialer dispositions doc maps how machine-answered attempts are recorded.
- Troubleshooting. If a predictive campaign sees near-everything classified as a machine, the Predictive AMD storms section maps the symptom to its usual causes.
Enabling AMD on a call
Send amd: true on the create-call request, alongside whatever flow the call runs when a human answers:
{
"to": "+14155552671",
"from": "+12025551234",
"agent_id": "agt_abc123",
"amd": true,
"record": true
}Pairing amd with record: true is the common pattern for AI-agent campaigns: recording starts when the call is answered, and the AMD verdict decides within the first seconds whether the call continues at all. Sessions that reach a human are recorded from the answer point; machine verdicts are dropped and surfaced through call.hit_voicemail instead. The branch then happens in your webhook handler: on call.hit_voicemail, log the amd_type, apply your retry policy, and do not re-engage that number immediately.
Frequently asked questions
Does AMD work on SIP trunks?
Yes. Detection is requested per call with the amd flag on the voice API, and outbound calls ride the Devotel softswitch regardless of how your numbers are provisioned. There is no separate trunk-side configuration to enable; inbound and outbound numbering arrangements do not change the behavior of the flag.
What does the call.hit_voicemail event tell me?
It fires when AMD classifies an outbound answer as machine-side: machine, machine_beep_detected, fax, ios_call_screening, or ios_live_voicemail. The payload carries the specific amd_type verdict, the detected_at timestamp, the call legs, and the agent ID when the call is tied to an AI agent. Use it to retry, log, or branch without waiting for the call to end.
Is AMD always accurate?
No. The classification happens in the first second or two of an answered call, so an occasional misread in either direction is inherent to any detection that fast. Ambiguous signals (no_answer, silence) fall on the continue side so a borderline call is not dropped on a guess.
Do I have to use AMD for compliance reasons?
AMD is an opt-in per-call control. How your operation treats machine-answered calls is your tenant's posture to set with your own counsel; the platform provides the detection and the branching events, and does not mandate a policy on top of them.