标签：#telnyx

Nobody likes phone trees. "Press 1 for billing, press 2 for support." Miss an option? Start over. It is friction at its worst. The voice-ivr-with-agent-backend example replaces that with a natural language conversation. Callers just say what they need, and the app routes them to the right department. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/voice-ivr-with-agent-backend What it builds A Python/Flask app that handles inbound calls with a conversational IVR: Inbound Call -> answer with Call Control -> look up menu config from KV -> LLM generates a dynamic greeting -> gather(speech) — caller says what they need -> LLM routes intent to a department -> transfer call The core primitives The app combines four Telnyx primitives: Call Control : answer() , speak() , gather_using_speech() , transfer() AI Inference : telnyx.ai.openai.chat.completions.create() for greetings and intent routing KV store : menu config per phone number (business name, departments, transfer numbers, keywords) Agent state machine : an IVRAgent class that tracks call state, turn count, and retry logic Dynamic greeting via LLM Instead of a hardcoded "Press 1 for billing," the app generates a conversational greeting from the KV config: def generate_dynamic_menu_prompt ( menu_config : dict ) -> str : departments = menu_config . get ( " departments " , []) dept_list = " \n " . join ( f " - { d [ ' name ' ] } : { d [ ' description ' ] } " for d in departments ) return ( f " You are an IVR assistant for { menu_config [ ' business_name ' ] } . " f " Available departments: \n { dept_list } \n\n " f " Greet the caller briefly and ask how you can help. " f " Keep it conversational and under 2 sentences. " ) The LLM generates the greeting through the OpenAI-compatible Telnyx Inference binding. If it fails, the app falls back to a static greeting from the KV config. Intent routing via LLM When the caller speaks, the transcription is passed to route_intent_with_llm . The LLM is instructed

Most package tracking flows make the customer do the work. You get a tracking number. You open a page. You refresh it. Maybe you get a generic text that says the package is out for delivery. If you need to ask a real question, you usually end up somewhere else entirely. I wanted to build the opposite shape: what if the package itself had an agent? The shipment-agent example is a Python and Flask app that treats a shipment as a durable AI entity. It can send proactive SMS updates, understand customer replies with Telnyx AI Inference, and answer inbound calls with shipment context. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/shipment-agent What it builds The app centers around a ShipmentAgent . The agent owns: shipment status carrier and tracking context customer phone number interaction history messaging and voice behavior Instead of a stateless chatbot waiting in a web page, the agent lives alongside the shipment lifecycle. Carrier update -> Flask webhook -> ShipmentAgent updates state -> SMS customer Customer SMS reply -> Telnyx Messaging webhook -> AI Inference response -> SMS reply Customer phone call -> Telnyx Call Control -> ShipmentAgent answers with context Why this is useful Shipment status is not just data. It is a customer communication problem. People want to know: Is my package delayed? Can I leave delivery instructions? Did it already arrive? Who do I call if something looks wrong? Traditional tracking pages are good at showing status, but not at handling conversation. This example shows how to turn the shipment into a small communications agent that can respond across SMS and voice. The main flow When a carrier status changes, the app receives a webhook. For example: out_for_delivery delayed delivered The ShipmentAgent updates its internal state and sends a message to the customer through Telnyx Messaging. If the customer replies, the app passes the message and shipment context to Telnyx AI Inference. That lets the response incl

Support SMS inboxes are usually a routing problem before they are an AI problem. Someone asks about billing. Someone else needs technical support. A third person wants to talk to sales. The app has to understand the message, pick the right destination, reply to the customer, and remember what happened. This TypeScript example does that on Telnyx Edge Compute with the Agent SDK. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/agent-sms-triage-bot What it builds agent-sms-triage-bot receives inbound SMS webhooks, classifies each message into one of four topics, looks up the route for that topic, replies by SMS, and stores triage history in durable actor state. The topics are: billing support sales general The default route table maps those topics to queue names: billing -> billing-queue support -> support-queue sales -> sales-queue general -> general-queue The request flow Inbound SMS -> POST /webhooks/sms -> TriageAgent.triage(from, text) -> Telnyx AI Inference classifies topic -> durable route table lookup -> SMS reply -> triage history update The app uses one TriageAgent actor per inbound number. That actor stores route rules, recent history, total messages, and topic counts. The main routes POST /webhooks/sms receives Telnyx message.received events POST /debug/triage simulates inbound SMS POST /routes updates the route table GET /routes lists route rules GET /history returns recent triage history GET /debug/state inspects actor state GET /health/liveness and GET /health/readiness provide health checks The Agent SDK piece The core class is TriageAgent . It extends the Agent SDK Agent class and uses durable state for: route table triage history total message count topic counts The AI classification call uses the Telnyx binding: const completion = await this . env . TELNYX . ai . openai . chat . createCompletion ({ model : this . env . AI_MODEL || " moonshotai/Kimi-K2.6 " , messages : [ { role : " system " , content : CLASSIFY_SYSTEM_PROMPT }, { r

Telnyx ships over 700 Ultra voices across 36 languages with sub-100ms time-to-first-byte. The voices are not the problem. Hearing them is. The docs list three. The Voices API returns 4,000+ across every provider. Voice pickers play a fixed sample sentence per voice. None of that tells you how a voice handles emotion, pacing, or character inside a real scene. So I built a small app that lets you do exactly that. You write a short scene with a few characters, assign each character a different Telnyx Ultra voice and an SSML emotion, and render the whole thing into one MP3. Every voice speaks in character, in context, in one continuous audio file. The Telnyx code example is: https://github.com/team-telnyx/telnyx-code-examples/tree/main/multi-character-narrator-python The Use Case Voice pickers exist. They play a fixed sample sentence per voice. What they do not do is let you hear a voice inside a real scene — a tense argument, a calm narrator, a panicked character, a reassuring guide — because a single sample sentence does not tell you how a voice handles emotion, pacing, or character. This example solves that. You write a short scene with a few characters. Each character gets a different Telnyx Ultra voice. Each character gets an SSML emotion. You hit render. The app fans out parallel TTS calls, stitches the per-line audio in script order, and plays you one continuous MP3 with every voice speaking in character. The default scene is the Ides of March from Julius Caesar. Five characters, ten lines, five distinct voices, five different emotions: Cassius — determined, plotting the assassination Caesar — surprised, realizing the betrayal Brutus — apologetic, justifying the act Mark Antony — angry, mourning the fallen leader Narrator — calm, setting the scene One render, one MP3, every voice in context. That is the demo. The Eight Curated Ultra Voices The app ships with eight pre-built Telnyx Ultra voices curated for the most common use cases. Each one is a real Telnyx voice

Subtitle: Build a Python app with Telnyx AI Inference that turns customer activity signals into churn risk, recommended actions, and retention next steps. Most customer churn is only surprising because the signals were scattered. Usage dropped in one place. Support tickets went up somewhere else. A renewal date got closer. A login did not happen for two weeks. Payment issues started showing up. None of those signals alone proves a customer is leaving, but together they usually tell a story. That is the workflow I wanted to make easier to build: take customer activity data, pass it through an inference model, and return a structured churn assessment that a product or customer success team can actually use. The example is here: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-customer-churn-predictor-python It is a small Flask app using Telnyx AI Inference through the chat-completions API. The App Shape The app exposes a few routes: POST /predict for one customer POST /predict/batch for up to 20 customers GET /predictions for recent in-memory predictions GET /health for app health The current default model is set in .env.example : AI_MODEL=moonshotai/Kimi-K2.6 Under the hood, the app calls: POST https://api.telnyx.com/v2/ai/chat/completions The prompt asks the model to behave like a customer success analyst and return JSON only. That is the important part. This is not a chatbot. It is an application endpoint that produces structured output. What Goes In A request can look like this: curl -X POST http://localhost:5000/predict \ -H "Content-Type: application/json" \ -d '{ "customer_id": "CUST-123", "call_volumes": [120, 105, 80, 55], "message_volumes": [450, 420, 300, 190], "support_tickets": 6, "account_age_months": 18, "renewal_days": 21, "last_login_days": 14, "payment_issues": 1 }' Those fields are deliberately simple. The point is to show the pattern, not to pretend this is a full enterprise churn model. The model gets the trend data, support contex