I Built an Outbound Voice Agent That Knows When It’s on Hold
A practical Telnyx Voice example for pausing AI assistant runtime during hold and resuming when a representative answers.
I Built an Outbound Voice Agent That Knows When It’s on Hold
A practical Telnyx Voice example for pausing AI assistant runtime during hold and resuming when a representative answers.

Most outbound voice agents look simple at first.
Call a company. Listen to the IVR. Press the right menu option. Wait for a representative. Then have the useful conversation.
But real calls are not mostly useful conversation. They are often mostly waiting.
The agent dials. It listens to a phone tree. It chooses a menu option. Then it sits through hold music, silence, queue updates, and repeated wait messages while no real conversation is happening.
If the assistant stays active the whole time, you are spending AI resources on the least useful part of the call.
That is the problem behind this outbound hold agent example:
https://github.com/team-telnyx/telnyx-code-examples/tree/main/outbound-hold-agent-python
The Useful Pattern
The key idea is to treat hold as a call state, not as part of the same continuous conversation.
An outbound business call has phases:
- dialing
- IVR navigation
- menu selection
- queue or hold
- representative pickup
- live conversation
- call completion
Those phases should not all use the same assistant behavior.
The IVR phase needs an assistant that can listen to automated menus and request DTMF. The live conversation phase needs an assistant that can explain the objective, answer questions, and complete the task.
Hold needs something else: the call should stay connected, but the full assistant does not need to be running.
What the Example Does
The example uses Telnyx Voice to manage the call lifecycle from the backend.
The flow is:
- place an outbound call with Telnyx Call Control
- start an IVR-focused assistant after the call is answered
- let the backend own DTMF/menu actions
- detect hold from webhooks, tools, or transcript phrases
- stop the active assistant during hold
- monitor the call for representative pickup
- start a representative-focused assistant with the original objective and recent context
That gives the system a cleaner shape. The assistant is active when it needs to do conversational work, and paused when the call is just waiting.
Why I Like This Shape
The main design choice is using two assistants instead of one giant prompt.
One assistant can technically be told to handle IVR navigation, hold behavior, representative pickup, live conversation, and call completion. But that prompt gets crowded quickly.
Splitting the workflow keeps each assistant focused.
The IVR assistant handles automated menus. The representative assistant handles the human conversation. The backend owns the transition between them.
That matters because hold detection becomes a system event, not a prompt instruction. The backend decides when to stop the assistant, when to monitor, and when to resume.
Where This Fits
This pattern is useful for outbound calls where the useful conversation happens after a lot of waiting.
Examples:
- confirming a hotel reservation
- checking appointment availability
- calling an insurance or benefits line
- asking a vendor about order status
- navigating a support queue
- reaching a billing or operations representative
In all of those cases, the agent should not treat the whole call as one continuous conversation. It should understand the phases of the call and use the right behavior for each one.
Try It
Clone the example:
git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/outbound-hold-agent-python
cp .env.example .env
pip install -r requirements.txt
python app.py
You will need a Telnyx account, a Call Control application, assistant IDs, and a public HTTPS URL for webhooks.
The Bigger Point
The goal is not just to make an outbound call.
The goal is to avoid keeping an AI assistant active when the call does not need one.
That changes the architecture. You stop building one long-running assistant and start building a call workflow with modes.
The agent should navigate when it needs to navigate, wait when it needs to wait, and speak when there is finally someone worth speaking to.
Resources
메타데이터
- post_id
- 8d34ce897eed
- slug
- i-built-an-outbound-voice-agent-that-knows-when-its-on-hold-8d34ce897eed
- url
- https://medium.com/@anusha.thukral/i-built-an-outbound-voice-agent-that-knows-when-its-on-hold-8d34ce897eed
- canonical_url
- https://medium.com/@anusha.thukral/i-built-an-outbound-voice-agent-that-knows-when-its-on-hold-8d34ce897eed
- author_url
- https://medium.com/@anusha.thukral
- status
- ok
- fetched_at
- 2026-07-23 02:48:33