Voicemail Detection for AI Voice Agents Gets Two Seconds

TL;DR: Voicemail detection for AI voice agents is not an accuracy problem, it is a budget problem, and the budget is two seconds. Under 47 CFR 64.1200(a)(7) a call is abandoned if it is not connected to a live sales representative within two seconds of the called person’s completed greeting, and the FTC Telemarketing Sales Rule says the same thing at 16 CFR 310.4(b)(1)(iv). Abandon more than three percent of answered calls, measured over a 30-day period for a single campaign, and the safe harbor in that rule is gone. The FCC closed the other half in FCC 24-17, adopted February 2, 2024: a voice generated or cloned by AI is an artificial voice under the TCPA, so the agent needs prior express consent before it dials, and every message it leaves has to state the responsible business at the beginning and a working callback number during or after, per 47 CFR 64.1200(b)(1) and (b)(2). That turns each classifier outcome into a rule. A false positive hangs up on a live person and books an abandoned call against the three percent. A false negative talks over the greeting, so the identification the rule wants at the beginning lands in the middle of nothing. Unknown is a real state and needs a written action, not a coin flip. Detection is also three separate events, machine detection, greeting-end detection, and beep detection, and a system can be certain it reached voicemail and still have no idea when recording starts. Write the policy first: what the agent does while classification is pending, and what it does on strong human evidence, strong machine evidence, uncertain greeting completion, unknown, and a business menu. Then measure time to decision, human dead air against the two-second line, greeting-end delay, late-event rate, and the confusion matrix by carrier and greeting type, and keep the timestamps, transcript fragments, confidence signals, and webhook history, because 64.1200(a)(7)(iii) requires records establishing compliance and those are the same records that let you debug the thing.

Most teams treat voicemail detection as a model question. Did the classifier get it right, how often, and can we push the number up. That framing hides the part that actually bites.

The moment an AI voice agent dials an outbound number, it is on a clock it did not set. The called person says hello, and federal rules start counting. Two seconds later the call is either connected, playing an approved message, or abandoned. The classifier does not get to take longer because the audio was hard.

So the useful question is not how accurate detection is. It is what the agent does with the time it has, and what each wrong answer costs when the rule, not the prospect, is grading it. That is a design question, not a model question. This guide works through the clock, the three events people collapse into one, the routing patterns, the error costs, the fallback policy, and the tests and metrics that tell you whether any of it works. It does not assume a particular voice provider.

Voicemail detection for AI voice agents starts a two-second clock

Here is the rule the engineering conversation usually skips. Under 47 CFR 64.1200(a)(7), a call is abandoned if it is not connected to a live sales representative within two seconds of the called person’s completed greeting. The FTC rule is written the same way at 16 CFR 310.4(b)(1)(iv): an outbound call is abandoned if a person answers and the telemarketer does not connect it to a sales representative within two seconds of that person’s completed greeting.

So where does the clock start? Not at dial. Not at answer. At the end of the greeting. Everything your stack does after the prospect finishes saying hello comes out of the same two seconds. The AMD verdict. The transcript. The confidence check. The routing hop. The agent’s first syllable.

The volume limit sits on top of it. The same section caps abandonment at three percent of all telemarketing calls answered live by a person, measured over a 30-day period for a single calling campaign, and if the campaign runs longer the rate is calculated separately for each successive 30-day period. The Telemarketing Sales Rule safe harbor at 310.4(b)(4) is built the same way, and it also wants the phone to ring at least fifteen seconds or four rings before you disconnect an unanswered call.

There is one more door, and it is the one voicemail detection actually walks through. Under 64.1200(a)(7)(ii), a telemarketing call that delivers an artificial or prerecorded voice message after the subscriber gave prior express written consent is not an abandoned call if the message begins within two seconds of the called person’s completed greeting. Same two seconds. The rule does not care whether a human or a machine is on the other end. It cares whether something started talking in time.

So the detection budget is not a latency preference your team negotiates with itself. It is a number somebody else wrote down.

Build backward from it.

Your AI voice agent counts as an artificial voice

This is the claim that makes the rest apply, so it is worth getting exactly right.

In FCC 24-17, a Declaratory Ruling in CG Docket No. 23-362 adopted February 2, 2024 and released February 8, 2024, the Commission confirmed that the TCPA restrictions on the use of an artificial or prerecorded voice cover current AI technologies that resemble human voices or generate call content using a prerecorded voice. Callers must therefore get prior express consent from the called party before placing a call that uses a voice simulated or generated through AI. The Commission’s reasoning is blunt: these are artificial voice messages because a person is not speaking them.

What does that change for a voicemail workflow? Three things, and they are all mechanical.

First, consent is a precondition of the dial, not a detail you sort out after a connect. Second, 64.1200(b)(1) says an artificial or prerecorded voice message must state clearly, at the beginning of the message, the identity of the business responsible for the call, using the name it is registered under. Third, 64.1200(b)(2) says the message must state a working callback number during or after it, and for telemarketing messages to residential lines that number has to let someone make a do-not-call request during business hours.

Now put that next to a detection miss. If the agent decides “machine” late and starts talking three seconds into a greeting, the identification that belongs at the beginning of the message is landing somewhere in the middle of a recording that may already have cut off. The classifier error is not just a bad customer moment. It moves a required disclosure to the wrong place.

Consent, calling, recording, identification, and messaging obligations also vary by jurisdiction and campaign type, and state rules can be stricter than the federal floor. Have qualified counsel review the workflow before it dials.

What voicemail detection actually decides

Answering machine detection, usually shortened to AMD, classifies who or what answered. The common results are human, machine, and unknown. Some platforms also emit finer events, like the end of a machine greeting or a beep.

People collapse those into one idea and then get surprised. Why does the distinction matter? Because they are three different questions, and answering one does not answer the others:

• Machine detection estimates whether voicemail or an automated system answered.
• Greeting-end detection estimates when the recorded greeting stopped.
• Beep detection listens for the tone that may mean recording has started.

A system can be completely certain it reached voicemail and still have no idea when it is safe to speak. That is the gap that produces half-recorded messages. Going the other way, leaning only on the beep breaks on voicemail services that use an odd tone, no obvious tone at all, or keep talking after the tone with instructions.

So treat the question as two decisions, not one. What answered, and when can the message start. Your routing needs an answer to both.

How voicemail detection works for voice agents

Implementations differ by provider, but nearly all of them draw on one or more of four signals.

Platform voicemail detection

Most voice platforms ship built-in AMD that reads early-call audio: speech duration, pauses, cadence, and how long the opening runs. A clipped “hello?” looks like a person, while a smooth multi-second introduction that runs on past the point where a human would have stopped looks like a recording, which is the whole heuristic in one sentence.

The appeal is speed. You get a routing decision without shipping a transcript to your application first. The catch is that behavior, event names, and tuning knobs are provider-specific, and they change. Twilio’s AMD documentation is a fair example of how much configuration detail sits behind one setting. Read your own provider’s current docs. Do not assume thresholds transfer between vendors.

Acoustic voicemail detection

You can classify the audio yourself on continuous speech length, silence intervals, tone patterns, and background characteristics. You get more control, and you also get more to own, because audio streaming, model operation, monitoring, and the ongoing drift as real-world greetings change all become your problem rather than your provider’s. That is a team commitment, not a feature flag.

Transcript based voicemail detection

Transcribe the opening audio, then let rules or a language model look for “leave a message,” “not available,” or “after the tone.” This handles custom greetings that defeat timing heuristics, which is exactly where platform AMD struggles.

So why not transcribe everything? Because it costs time, and time is the scarce thing here. Transcription adds latency, and it degrades on poor audio, crosstalk, and multilingual greetings. A live prospect can say “I am not available right now” and look exactly like a recording. Make the model return a confidence level or an explicit unknown instead of forcing a pick.

Hybrid voicemail detection

Combine them: platform AMD for the fast first read, transcript evidence to resolve the ambiguous calls, application rules on top. Hybrid buys flexibility and pays for it in failure paths, because every component you add is one more thing that can answer late, and late is the specific failure this clock punishes hardest.

Synchronous and asynchronous detection spend the same two seconds

The architecture choice is usually framed as latency versus safety. Against the rule it is simpler than that. Where do you want to spend a fixed budget?

Synchronous voicemail detection

The application waits for classification before it connects or wakes the AI agent. Routing stays simple and the agent will not open a live pitch into a greeting. The cost is dead air: a real person answers and hears nothing while the system makes up its mind. That silence is not free. It is spending the two seconds, and if it overruns, a person who answered your call is now an abandoned call.

Asynchronous voicemail detection

The agent starts listening or talking while AMD runs alongside, and a webhook or stream reports the verdict later. Initial silence drops. In its place you get interruption risk, where the machine verdict lands a beat after the agent has started its opening and you are now talking over a greeting you had already decided to respect.

Hybrid voice agent routing

Use a short bounded detection window, then let the agent proceed while you keep watching for stronger evidence. This one requires honest state management. The agent has to know that classification is still pending and keep its opening short until the state resolves, because anything it commits to during that window, a question, a pitch, a promise, may have to be unwound a second later.

A provider-neutral reference flow:

Start call, monitor opening audio, collect AMD and transcript signals, classify as human, machine, or unknown, route a human into the conversation, wait for greeting completion before an approved voicemail, apply a conservative fallback for unknown, and record the decision and the outcome.

Whatever you build, treat voicemail status as a call-state event, not a one-shot API response. It arrives, it can arrive late, and it can arrive after the call is over.

What each voicemail detection error actually costs

Do not evaluate this with accuracy. A single number averages away the one thing you need to know, which is that the two errors have completely different prices and the cheaper one is not always the one you are optimizing against.

• False positive, a human classified as voicemail. The system hangs up on a live prospect or plays a recording at them. Under the abandonment rule that is the expensive one: a person answered, nobody connected them inside two seconds, and the call counts against your three percent for the 30-day period.
• False negative, voicemail classified as human. The agent opens a conversation with a greeting, or starts before recording does. The required identification drifts out of position, and the message you meant to leave is clipped or missing.
• Unknown. The evidence is thin or it conflicts. This is a safety state doing its job, not a defect. A classifier that never returns unknown is just guessing with extra confidence.

So which error is worse? It depends on the campaign, and the honest answer changes the thresholds. A team working a short list of named accounts will take missed voicemails over hanging up on a buyer. A high-volume campaign already close to the three percent line has the opposite problem and cannot afford false positives at all. Price both before you touch a threshold, because tuning without that is just moving the pain somewhere you are not measuring.

Where Kixie AI Human Voice Detection fits the voice agent workflow

Everything above is provider-neutral, so here is the concrete version of it in one stack.

Kixie’s AI Human Voice Detection is the platform-AMD layer described earlier, covering IVR and answering machine detection. It tells the difference between a live person and a recording and connects the call to a rep when a person answers. That is the fast first read, and in the routing terms above it is the component that has to resolve inside the window, because everything downstream of it is spending time the rule has already allocated.

The second half is what happens on a machine verdict, and it is the half teams forget to design. Voicemail Drop plays a pre-recorded message so the rep is not re-reading the same script into a recording forty times a day. The operational point is not the time saved. It is that the message is a fixed, reviewed artifact. If the identification at the beginning and the callback number are in the recording, they are in every delivery of it, which is exactly the property 64.1200(b)(1) and (b)(2) are asking for. An improvised voicemail is a compliance surface. A reviewed one is not.

Underneath both sits the PowerDialer, which is where the pacing question lives. How many lines you run per rep determines how often a person answers with no rep free, and that is the input to the three percent, not the detection accuracy. The dialing mode you choose sets the abandonment exposure before any classifier runs, which is the same argument behind picking a call center dialing mode on staffing rather than on calls per hour.

What should you check in your own stack? Three things. Does detection return a usable state fast enough to route inside the window, is the voicemail you leave a reviewed artifact rather than an improvisation, and does the dialing mode keep a rep available often enough that detection is not the only thing standing between you and an abandoned call.

Write the voicemail detection fallback policy before tuning thresholds

Why write the policy before touching a threshold? Because a threshold is unsettable until somebody has written down what each result does. Define the actions first. Then tune.

A workable production policy specifies all six states:

• While classification is pending, the agent holds a short opening and commits to nothing it would have to take back.
• On strong human evidence, start the approved live conversation flow.
• On strong machine evidence, suppress live dialogue and wait for greeting completion.
• On machine detected but greeting completion uncertain, wait a bounded timeout, then hang up or follow another approved path. Pick that timeout deliberately rather than inheriting a default, because this is the exact state where messages get clipped and nobody notices until someone listens to a recording.
• On unknown, run the configured fallback for that campaign: a neutral clarification, a controlled retry, a transfer, or a hangup.
• On an interactive business menu, route it separately. A switchboard is not personal voicemail and should never get the voicemail message.

One hard boundary: the model does not improvise any of this. Call disposition, retry timing, message content, and recording behavior belong in reviewed business logic, not in a prompt. Those are the choices with rules attached to them, and a language model deciding any of them fresh at runtime is an audit problem waiting to happen, because you cannot show a regulator a decision nobody wrote down.

Idempotency matters too. A duplicate webhook or a reconnect must not play the same voicemail twice, and the application should reject a classification that arrives after the call has already ended or moved to a terminal state. Late events are normal in any asynchronous design, and the application should treat them as information to file rather than instructions to follow. Acting on them is the bug.

How to test voicemail detection for voice agents

Testing against a handful of default mobile greetings will tell you the system is excellent. It is not. It is untested on the cases that break it.

Build a permissioned, representative corpus that matches the numbers, languages, regions, carriers, devices, and business contexts the campaign actually dials. Include:

• Short and long personal greetings
• Custom greetings with pauses or background music
• Business switchboards and interactive menus
• Call-screening assistants that ask the caller to identify themselves
• People who answer with silence, a long introduction, or speakerphone noise
• Disconnected-number announcements and carrier messages
• Greetings with no clear beep, or with instructions after the beep
• Low-quality audio, crosstalk, and multilingual speech

Keep a labeled holdout set separate from the examples you tune on. When the logic changes, replay the same corpus and compare. Is the corpus ever finished? No. It grows every time production surprises you. Controlled tests should be topped up with reviewed production samples wherever recording, storage, and analysis are permitted for that traffic.

Retest on a trigger, not a calendar. Provider changes, model changes, threshold changes, routing changes, and new campaign geography all invalidate the last result.

Voicemail detection metrics worth tracking for voice agents

Track a confusion matrix, not a headline percentage. At minimum: human-to-machine false positives, machine-to-human false negatives, unknown rate, and results broken out by greeting type.

Then add the operational ones, because they are the ones tied to the clock:

• Time to decision. From completed greeting to classification. This is the number that competes with the two seconds.
• Human dead air. How long a live person waits before anything speaks. Watch the tail, not the mean. Why the tail? Because the average looks fine while the slow five percent is abandoning calls.
• Greeting-end delay. Time between the apparent end of a greeting and the start of playback.
• Message completion. Whether the intended message appears to have played in full.
• Late-event rate. Classifications that arrive after the workflow already moved on.
• Outcome by segment. Carrier, destination, language, and greeting category. Aggregates hide a single carrier behaving differently.

Review the trend. A one-time benchmark ages badly. Carrier behavior, call-screening products, handsets, and provider implementations all change underneath you, and a number you measured two quarters ago is describing a system that no longer exists.

Voicemail detection troubleshooting and the records you must keep

Custom greetings coming back as human? Look at the continuous speech limit, the transcript evidence, and how long the system is allowed to wait before deciding. Humans coming back as machines? Look for long opening statements, delayed responses, and noisy audio that reads like recorded speech.

Messages starting too early almost always means machine classification and greeting-end detection have been collapsed into a single decision somewhere in the pipeline. Separate them. Messages starting too late usually means a timeout is waiting on a beep that is never going to arrive. For business IVRs, add the distinct route rather than tuning the personal-voicemail path until it tolerates menus.

All of which depends on keeping the evidence. A final label with no timestamps, transcript fragments, confidence signals, or webhook history cannot be debugged, only argued about.

And there is a second reason to keep it. 64.1200(a)(7)(iii) requires the seller or telemarketer to maintain records establishing compliance with the abandonment rule. The per-call evidence an engineer needs in order to explain why the classifier decided what it decided is substantially the same evidence that shows the three percent was respected, so build the logging once and it answers both questions.

Voicemail detection FAQ for voice agents

Is voicemail detection the same as beep detection?

No. Voicemail detection classifies what answered. Beep detection tries to identify the tone that signals recording has begun. A workflow often needs both, and neither one guarantees the message records in full.

Should an AI voice agent speak while detection is still running?

It depends on which error you can afford. Speaking immediately cuts dead air for humans and risks talking over a greeting. Waiting does the reverse and spends the two-second window. A short, deliberately designed pending state limits both, which is why most production systems end up hybrid.

What should happen when the voicemail detection result is unknown?

Whatever you decided in advance for that campaign: a neutral clarification, a controlled retry, a transfer, or a hangup. Log it and review it. The failure mode is silently converting unknown to human or machine so the dashboard looks cleaner.

Does the two-second abandonment rule apply to an AI voice agent?

The abandonment rule at 47 CFR 64.1200(a)(7) applies to telemarketing calls answered live by a person, and 16 CFR 310.4(b)(1)(iv) states the same two-second standard. FCC 24-17 confirmed that an AI-generated or cloned voice is an artificial voice under the TCPA, which pulls the consent and identification requirements in as well. Scope depends on the campaign and the jurisdiction, so have counsel confirm how it applies to yours.

How often should voicemail detection be retested?

After any provider, model, threshold, routing, or campaign change, and continuously in production against the trend. Use your own representative traffic rather than a vendor-wide performance claim that was measured on somebody else’s call mix.

Sources

• Federal Communications Commission, 47 CFR 64.1200, Delivery restrictions, via the Electronic Code of Federal Regulations: ecfr.gov/current/title-47/section-64.1200. The two-second abandonment standard and the three percent limit over a 30-day period are at (a)(7), the records obligation at (a)(7)(iii), and the identification and callback number requirements at (b)(1) and (b)(2). Reviewed October 19, 2026.
• Federal Trade Commission, 16 CFR 310.4, Abusive telemarketing acts or practices, via the Electronic Code of Federal Regulations: ecfr.gov/current/title-16/section-310.4. The Telemarketing Sales Rule states the two-second abandonment standard at (b)(1)(iv) and its safe harbor conditions at (b)(4). Reviewed October 19, 2026.
• Federal Communications Commission, Declaratory Ruling FCC 24-17, CG Docket No. 23-362, adopted February 2, 2024 and released February 8, 2024: docs.fcc.gov/public/attachments/FCC-24-17A1.pdf. Paragraph 5 confirms that TCPA restrictions on an artificial or prerecorded voice cover AI technologies that resemble human voices. Reviewed October 19, 2026.
• Twilio, Answering Machine Detection FAQ and best practices, cited as an example of provider-specific AMD configuration rather than as a cross-vendor standard: twilio.com/docs/voice/answering-machine-detection-faq-best-practices. Reviewed October 19, 2026.

Sources verified by the Kixie Research Team on October 19, 2026.