Voice

What is a voice AI agent, and how does it connect to the phone network?

A voice AI agent uses software to understand and respond to speech and reaches the phone network by connecting its SIP-capable runtime to a telephone provider’s SIP trunk.

A booking assistant needs more than a voice that sounds natural. It needs a reliable way to hear the customer, act on the right request and explain the confirmed result.

What does the conversational runtime do?

The runtime processes speech, decides how to respond and produces audio for the caller.

An application may combine speech recognition, a language model and speech synthesis, or use a model that processes audio directly. It also manages turn-taking: when to listen, when to speak and what happens when the caller interrupts.

Business tools give the conversation a useful result. An appointment tool can check availability and request a booking. The application must distinguish a confirmed booking from a timeout or an unknown result before the agent speaks.

A managed platform can supply some of these pieces. Telnyx AI Assistants exposes model, voice and tool configuration. Vapi’s built-in tools include actions used during a conversation. Those runtime settings are separate dependencies when changing telephone providers.

How does the agent reach the phone network?

The agent runtime connects through a telephone provider’s trunk using SIP, the protocol that starts, changes and ends calls.

The runtime must support SIP signaling and send and receive audio over a separate media path. A successful signaling exchange does not show that it hears the caller.

For incoming calls, a telephone number routes the caller to the application’s endpoint. For outgoing calls, the application uses a permitted caller identity and a destination the connection can reach. A number’s availability, caller presentation and the receiving network’s behavior are separate concerns.

Changing the trunk does not copy the agent’s prompts, voices, tools or knowledge sources. Keep those components in the runtime you retain, or migrate them explicitly.

What makes the conversation work under interruption?

The runtime must handle a caller who speaks over a prompt, changes direction or gives an ambiguous answer.

Test names, dates and numbers over the actual phone audio path. Include background noise, slow business tools and an action whose result is uncertain. The application should check a possibly completed operation before retrying it.

Human handoff needs its own outcome. The agent must know where to send the conversation and what to say when that destination is unavailable. Transfer and conference behavior belong to the connected application or business phone system (PBX), which routes calls to people or teams. Verify that behavior across the full call path.

What should I measure?

Measure telephone connectivity, conversational behavior and business completion separately.

The call record shows the telephone outcome. Audio and transcripts help review what was heard and said. The booking, payment or case system confirms whether the requested action happened.

A transcript-only test cannot establish audio quality or interruption behavior. An answered call cannot establish a successful customer interaction. Keep missing recordings, failed transcription and uncertain tool results visible in the review.

How do I connect an AI voice application to Bird?

You connect your AI voice application through a SIP trunk. Set inbound_enabled to true for calls arriving at your agent. Enable outbound_enabled for calls it places. Both directions start disabled, so a new trunk refuses calls until you enable the direction you need.

Trunk updates require voice_management at write level.

For inbound delivery, the gateway’s sip_uri contains your runtime’s host and optional port, without a user name. The destination_format becomes the part before @ in the delivered SIP address. The default +{number} passes the dialed number through. A fixed value routes all incoming numbers to one runtime address.

The gateway’s priority determines failover order: a gateway at 0 is tried before one at 1. You then point a held, inbound-capable number at the trunk under Inbound routing.

For outbound calls, your runtime connects to the trunk’s returned domain. With API-key authentication, allowed_api_key_ids lists the permitted keys; each needs voice at write level. Your runtime uses bird as the SIP username and the selected key’s secret as its password. Updating the allowed-key list replaces it in full, so retain keys that other clients still use.

Outbound calling also requires a verified caller ID and an enabled, available destination country.

Your runtime owns business actions and human handoff. Bird’s hosted MCP tools manage workspace resources; they do not run the live speech and reasoning loop.

In short

  1. The runtime owns the conversation.

    Speech, reasoning, tools and turn-taking belong to the application or platform running the agent.

  2. The telephone connection carries the call.

    Numbers, SIP signaling, media and caller identity form the connection to the customer’s phone.

  3. Test the complete interaction.

    Audio, interruptions, uncertain tool results and human handoff need tests on the actual calling path.

  4. A business system confirms its own result.

    A spoken confirmation or generated summary does not prove that a booking or other action succeeded.

Put it into practice.

Continue with the documentation, guides and examples for this topic. Resources are in English.

Get an implementation brief

Build on the same network.

A test API key is yours immediately. Production unlocks when you add a payment method and verify a sender.

Your next idea.
Ready to connect.