Most voice-agent launches obsess over the first ten seconds of a call. The greeting has to land, the disclosure has to fire, the intent has to be captured. Meanwhile, the last ten seconds get almost no attention, and that is where the same launches quietly leak trust. The agent hangs up on someone mid-sentence. The agent says goodbye and then sits in silence for eight seconds. The agent refuses to end the call after the caller has said goodbye three times. The agent ends the call, and only afterward does the CRM write-back reveal it never captured the callback number.
The hangup is a decision, and it is testable. This is a PM-shaped guide to the failure modes that show up at the end of a call, how to design the decision, and what to put in your regression suite before you ship the next prompt change.
Why the end of the call is different
Every voice-agent platform exposes some version of the same two mechanisms for ending a call: a tool the model can call, and a phrase that triggers termination. Vapi documents both explicitly in its default tools: endCall hangs up the active call immediately when the model invokes it, and end-call phrases can be configured to fire when the agent says something on a match list. Retell splits the same problem across voicemail detection, IVR detection, and explicit end-of-call decisions, each with its own disconnection reason. Every serious platform in the stack has a version of these primitives.
Those primitives are also where the failure modes live. Ending a call is not like other turns. It is irreversible: once the SIP session is torn down, there is no "let me correct that" recovery. It is also invisible to the caller in a specific way, because the human on the other end cannot see the model deliberating. A one-second pause before the agent says goodbye is polite. A one-second pause after the agent's last word, before the line drops, is confusing. Two seconds is a bug report.
The other thing that makes end-of-call different is that the caller has usually stopped participating. In the middle of a conversation, the caller will correct you, interrupt you, and push back. At the end, they often will not. Whatever your agent does in its last three turns is what your caller will remember, and often the only person who catches it going wrong is your QA reviewer, days later, listening to a recording.
The four ways a voice agent ends a call badly
Across production call reviews, end-of-call failures cluster into four buckets. Building a test plan starts with naming them.
1. Premature termination. The agent hangs up in the middle of the conversation. The most common cause is the endCallPhrase mechanism firing on innocuous language. One engineer describes exactly this: an agent that terminated mid-authentication because "We will get back to you shortly" was on the end-call phrase list and the model produced it inside a confirmation question. The caller was mid-utterance when the line dropped. The other common cause is the LLM calling endCall too eagerly, especially when a system prompt says "end the call when the caller has no more questions" and the caller says "okay, thanks" as a backchannel rather than a farewell.
2. Refusal to hang up. The opposite failure. The caller says goodbye, the caller says "we're done", the caller falls silent, and the agent keeps offering. Vapi's own community threads are full of teams debugging this: the assistant says goodbye, then just sits there because the endCall tool was never actually wired into the assistant's tools list. It is a configuration bug that looks like a behavior bug, which is why it survives so much manual QA.
3. Dead air after farewell. The agent produces a clean closing line and then takes one to three seconds to actually tear down the call. The caller hears silence and starts speaking again out of confusion, which either restarts the conversation or gets clipped by the belated hangup. This is a wiring issue between the TTS completion event, the endCall trigger, and the SIP BYE, and it is invisible from the transcript alone. You have to listen to the audio.
4. Wrong-reason termination. The call ends because the agent thought it hit a voicemail, or thought the caller said "goodbye", or thought its own error message was the end of the flow. Retell's docs explicitly enumerate this: voicemail and IVR detection are handled separately, and misclassifying an IVR system as a voicemail (or vice versa) leads to a hangup that looks correct in the logs but was catastrophic on the call. The EVA-Bench paper prompts its simulated caller with a rule that captures this directly: never call the end-conversation tool in the same turn where the agent is asking for more information.
The design decisions PMs actually make
Before you write a single test, four decisions determine what "correct" hangup even means for your agent. If you skip them, your test suite will be a random walk.
Who decides? Two candidates: the model (via a tool call) or a matcher (via a phrase list). The tool call gives the model context, but it also gives the model latitude to end things it should not. The matcher is deterministic, which cuts both ways: it will never fire on ambiguous language, and it will absolutely fire on innocuous language that overlaps with your list. Most production agents use both, and most premature-termination bugs come from the interaction between them.
How courteous is the close? There is a real spectrum, from a curt "thanks, goodbye" to a full summary of what happened, what will happen next, and a reference number. The right point on that spectrum is a product decision, not a technical one. A cold-call outbound agent that hangs up too warmly wastes minutes. A support agent that hangs up without recapping the resolution generates callbacks. Decide on the shape of the close per flow, and write it down.
What must land before hangup? This is the checklist that gets forgotten. For a scheduling agent: appointment time confirmed back to the caller, confirmation message queued for send, callback number captured. For an FNOL agent: claim number spoken and repeated, deadline stated. For a payment agent: transaction ID given, receipt method confirmed. If any of these are missing, hangup is a bug regardless of what the closing line sounded like.
When should the agent give up? The CloudTalk hangup docs enumerate the natural cases: task complete, lead disqualified, voicemail reached, multiple retries failed. "Multiple retries failed" is the one PMs consistently under-specify. Three failed name-capture attempts, then hang up? Three failed authentications, then transfer to a human? The number and the fallback are both product decisions with real consequences.
Once those are settled, testing becomes tractable. You are no longer asking "did the call end well?" You are asking "did the call end in the way we said it should, given the flow it followed?"
A pre-launch test suite for hangup behavior
The suite that catches these bugs has a specific shape. It is not a general "conversation quality" suite. It is a set of scenarios engineered to exercise the last three turns of the call, and it runs over real phone calls, because dead air is an audio artifact that a text-only harness will not catch.
At minimum, run these scenarios against every prompt or model change:
- Clean goodbye. Caller resolves the task, says "great, thanks, bye" and hangs up. The agent should acknowledge, deliver the mandated close, and trigger hangup within the target latency budget.
- Caller changes mind at the end. Agent has begun its closing line; caller says "wait, actually, one more thing." Agent must recover, reopen the flow, and not fire endCall on the "actually, thanks" language.
- Ambiguous farewell. Caller says "okay" or "alright" as a backchannel, not a farewell. Agent must not treat it as end-of-call.
- Silent caller at the end. Caller resolves the task, then says nothing. Agent should wait, then offer a graceful close and hang up after a configured silence threshold, not immediately.
- Failed authentication. Caller fails auth three times. Agent must escalate or hang up per your policy, not loop indefinitely, and must not leak partial account info in the close.
- Voicemail on outbound. Outbound call reaches a voicemail. Agent must classify correctly and take the configured action (leave message, drop, callback). Retell's docs note this only runs in the first three minutes of the call, so scenarios that push past that boundary are worth exercising too.
- Phrase-list landmine. Craft a scenario that forces the agent to produce a phrase that is close to but not on your end-call phrase list. Then craft one that produces something exactly on the list, mid-flow. If either terminates the call, your phrase list is a bug.
- Mid-payment interruption. For any agent that handles money: put the endCall trigger next to a payment step and confirm the call cannot terminate until the transaction resolves and the confirmation is spoken.
Each of these should produce a clear pass or fail, and each should be replayable against tomorrow's prompt. The bar is not "the call ended eventually", it is "the call ended in the shape we specified, at the latency we specified, with the checklist items delivered."
What to score on live calls
Pre-launch is only half of it. Once the agent is answering real calls, the same failure modes drift in. Every serious voice-agent operation scores end-of-call behavior on live traffic. A useful minimum set:
- Time from farewell to BYE. How long between the agent's last spoken word and the actual SIP teardown. Anything over a second is a candidate for review.
- Time from caller's last word to agent hangup on a clean close. Should be within your configured silence budget, plus the closing line duration. Outliers are premature or laggy hangups.
- Endpoint checklist coverage. For each flow, did the mandated items land before termination? Confirmation number spoken? Callback number captured? Consent restated?
- Termination reason distribution. Voicemail, IVR, model-decided, phrase-matched, timeout, caller-hung-up. A sudden shift in the mix is almost always a regression from the last deploy.
- Post-farewell caller speech. Any case where the caller spoke after the agent's closing line but before the hangup is worth reviewing. It is either dead air the caller was trying to fill, or the caller had more to say and got cut off.
None of these require anything exotic. They require that your call recordings are timestamped, that your metric layer knows what "end of call" looks like on the audio (not just the transcript), and that failures get filed as issues instead of drowning in dashboards.
Where Roark fits
Roark is a simulation-testing, observability, and reporting platform for voice agents, and end-of-call is one of the places where the two halves meet cleanly.
On the pre-launch side, Roark's simulation testing dials your agent over real phone calls, from personas designed to exercise the failure modes above: the caller who says "okay" as a backchannel, the caller who goes silent, the caller who circles back at the last moment. Because runs happen over PSTN and WebRTC rather than a text loopback, dead air after the agent's closing line shows up as dead air, not as a clean transcript. The suites are replayable, so the same scenarios run again on the next prompt change and gate CI.
On the live-call side, every production call is scored against Roark's audio-native metric suite, which includes the pace, pauses, and interruption signals that end-of-call bugs actually manifest as. When a call terminates outside the expected shape, Roark files it as an issue rather than burying it in a dashboard. And when a production call reveals a genuinely new failure, Roark can capture it and replay it against your updated agent as a regression test, so the fix stays fixed.
The pattern to internalize is that hangup behavior is not one thing you test once. It is a decision your agent makes on every call, and the way to keep it correct is to write down what "correct" means, exercise it before launch, and score it after.
Ship the greeting. Then ship the goodbye.
