DEV Community: Sonam

Build an AI Outbound Call Campaign with Python and Telnyx

Sonam — Wed, 26 Aug 2026 21:58:10 +0000

Outbound call campaigns look simple until you need them to behave like real software.

Calling one number is easy. Calling a list of numbers means you suddenly care about queueing, rate limits, call state, webhook verification, result tracking, and summaries for the team.

I built a small example for that pattern: an AI Call Campaign Orchestrator using Python, Flask, Telnyx Call Control, the Telnyx Agent SDK, SQLite, and SMS.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-call-campaign-orchestrator

What the app does

The app exposes a simple API:

POST /campaign starts a campaign from a list of phone numbers
GET /campaign/<campaign_id> returns campaign status and call results
POST /webhooks/call receives Telnyx Call Control events
GET /health confirms the service is running

The interesting part is what happens after you submit the campaign.

The CampaignAgent queues the calls, applies a rate limit, places outbound calls through Call Control, stores results in SQLite, and sends an SMS summary when the campaign is complete.

POST /campaign
  -> queue calls
  -> rate-limit delivery
  -> place calls with Call Control
  -> receive signed webhooks
  -> store results in SQLite
  -> send SMS summary

Starting a campaign

You send a list of E.164 phone numbers to POST /campaign:

curl -X POST http://localhost:5000/campaign \
  -H "Content-Type: application/json" \
  -d '{
    "phone_numbers": [
      "+15551234567",
      "+15557654321",
      "+15559876543"
    ]
  }'

The API returns a campaign ID:

{
  "campaign_id": "3f2c1a5e-8b7d-4e6f-9a0c-1d2e3f4a5b6c",
  "status": "started"
}

From there, the agent owns the campaign lifecycle.

Why rate limiting matters

Outbound communication workflows need pacing.

If you fire too many calls at once, you can create a bad user experience and run into carrier or operational limits. This sample uses CALL_RATE_LIMIT_PER_MINUTE so campaign delivery is controlled from configuration instead of buried inside the call loop.

That makes the campaign behavior easier to tune without rewriting the app.

Placing calls with Call Control

For each queued number, the app places an outbound Call Control call with the Telnyx Python SDK.

The app needs:

TELNYX_API_KEY
TELNYX_CONNECTION_ID
TELNYX_PHONE_NUMBER
TELNYX_WEBHOOK_URL

The webhook URL points back to the app, so call lifecycle events can update campaign state as calls are answered, completed, or fail.

Verifying webhooks

The webhook endpoint uses telnyx.webhooks.unwrap() with the Telnyx Ed25519 public key.

That matters because webhook handlers should not blindly trust incoming HTTP requests. The app verifies that the event really came from Telnyx before it updates call state.

Telnyx Call Control event
  -> POST /webhooks/call
  -> verify signature
  -> update campaign result

Tracking status

At any point, you can poll:

curl http://localhost:5000/campaign/<campaign_id>

The response includes total calls, completion status, and per-number results.

That gives you a simple campaign dashboard API without adding another database service just for the sample.

Closing the loop with SMS

When the campaign finishes, the app sends a summary SMS using Telnyx Messaging.

You configure:

TELNYX_SMS_FROM
TELNYX_SMS_TO

For a demo, this is a clean way to prove the workflow completed. In a production version, the same step could also notify Slack, update a CRM, or send a report to another internal system.

What I like about this pattern

The app is not trying to be a full campaign product.

It is showing the backend shape you need for one:

one API to start the work
an agent to manage queueing and pacing
Call Control for the voice workflow
signed webhooks for lifecycle updates
SQL for campaign state
SMS for completion notification

That is the useful part. It gives you the skeleton for a durable communications workflow without starting from a pile of disconnected services.

Run it yourself

Clone the repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/ai-call-campaign-orchestrator

Create a virtual environment and install dependencies:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Configure your environment:

cp .env.example .env

Then fill in your Telnyx API key, connection ID, phone number, webhook URL, public key, SMS settings, and call rate limit.

Run the app:

python app.py

Resources:

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-call-campaign-orchestrator
Telnyx AI toolkit: https://github.com/team-telnyx/ai
Telnyx docs: https://developers.telnyx.com
Telnyx Portal: https://portal.telnyx.com

Build a Live Call Transcription Agent on Telnyx Edge Compute

Sonam — Tue, 25 Aug 2026 05:38:03 +0000

Call recordings are useful, but they are usually passive.

This example turns a live phone call into something your app can use right away.

The edge-call-transcription-agent example answers an inbound call on Telnyx Edge Compute, starts streaming transcription, stores final transcript segments in an Agent SDK actor, summarizes the call after hangup with Telnyx AI Inference, persists the record, and sends the summary by SMS.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-call-transcription-agent

What it builds

The app is a TypeScript Edge Compute function with two Agent SDK actors:

TranscribeAgent - one actor per call
TranscriptRegistry - one shared actor for listing stored transcripts

The call flow:

call.initiated
  -> record call state
  -> answer call

call.answered
  -> speak greeting

call.speak.ended
  -> start inbound transcription

call.transcription
  -> append transcript segment

call.hangup
  -> summarize
  -> store
  -> SMS summary

Routes

POST /webhooks/voice receives Telnyx Call Control events
GET / serves a lightweight dashboard
GET /transcripts lists recent stored transcripts
GET /transcripts/:call_control_id fetches one transcript
GET /debug/state?call_control_id=... shows live actor state
GET /health/liveness and GET /health/readiness are health checks

Why actors help

Streaming transcription arrives as many events.

The app needs to remember:

which call this is
whether it is answering, transcribing, summarizing, sending, or done
interim transcript segments
final transcript text
start and end timestamps
summary status

An actor per call makes that state easy to hold.

The source maps each call_control_id to one TranscribeAgent, so the transcript can build up across webhook events.

The AI summary

After hangup, the actor queues a finalize pipeline:

summarize -> store -> notify

The summary uses Telnyx AI Inference through the Edge Compute binding:

this.env.TELNYX.ai.openai.chat.createCompletion({
  model,
  messages: [
    { role: "system", content: SUMMARY_SYSTEM_PROMPT },
    { role: "user", content: transcript },
  ],
  max_tokens: 200,
  temperature: 0.3,
});

The default model is:

zai-org/GLM-5.2

The prompt asks for a concise SMS-friendly summary under 320 characters.

SMS notification

Once the summary is ready, the app sends it over Telnyx Messaging:

this.env.TELNYX.messages.send({
  from: this.env.SMS_FROM,
  to: this.env.SMS_TO,
  text: state.summary,
});

Use placeholders in examples and configure real numbers only as private runtime values:

SMS_FROM=<TELNYX_SMS_FROM>
SMS_TO=<SUMMARY_RECIPIENT>

Try it

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-call-transcription-agent
npm install

Set secrets:

telnyx-edge secret set TELNYX_API_KEY <YOUR_TELNYX_API_KEY>
telnyx-edge secret set SMS_FROM <TELNYX_SMS_FROM>
telnyx-edge secret set SMS_TO <SUMMARY_RECIPIENT>

Deploy:

telnyx-edge ship

Point your Call Control app webhook to:

https://edge-call-transcription-agent-<id>.telnyxcompute.com/webhooks/voice

Then call the Telnyx number assigned to the Call Control application.

Production notes

Before using this with real callers, add:

webhook signature verification
auth on transcript and debug endpoints
transcript redaction
retention rules
SMS opt-out and consent handling
idempotency for Call Control and SMS actions
monitoring for STT, LLM summary, storage, and SMS delivery

The useful pattern is simple: live call events, durable state, AI summary, and post-call notification in one edge app.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-call-transcription-agent
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Call Control API reference: https://developers.telnyx.com/api-reference/call-control
Streaming transcription guide: https://developers.telnyx.com/docs/voice/programmable-voice/transcription
Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Switch AI Models at Runtime on Telnyx Edge Compute

Sonam — Thu, 20 Aug 2026 22:13:11 +0000

Most AI examples hardcode the model name.

That is fine until you actually want to compare models.

If every model change requires a code edit and redeploy, experimenting gets annoying fast. The multi-model-inference-switcher example turns model choice into runtime configuration instead.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/multi-model-inference-switcher

What it builds

This is a TypeScript app running on Telnyx Edge Compute with the Agent SDK.

It gives you:

an admin UI
a model dropdown
a chat panel
durable conversation history
usage stats by model
a KV-backed active-model flag

The active model is read from Telnyx KV Storage every time /chat is called. When you switch the model from the UI or API, the next message uses the new model immediately.

No redeploy.

The flow

GET /
  -> admin UI

POST /model
  -> validate model
  -> write active-model to KV

POST /chat
  -> read active-model from KV
  -> SwitcherAgent.process(text, model)
  -> Telnyx AI Inference
  -> return reply + model

The sample includes these models:

moonshotai/Kimi-K2.6
zai-org/GLM-5.2
meta-llama/Llama-3.3-70B-Instruct

Why this is useful

Model choice is product behavior.

Changing the model can affect:

latency
cost
output quality
reasoning depth
tone
reliability

So it helps to make the active model observable and switchable without mixing that decision into application deploys.

API examples

Switch the active model:

curl -X POST https://multi-model-inference-switcher-<id>.telnyxcompute.com/model \
  -H "Content-Type: application/json" \
  -d '{"model":"zai-org/GLM-5.2"}'

Send a chat message:

curl -X POST https://multi-model-inference-switcher-<id>.telnyxcompute.com/chat \
  -H "Content-Type: application/json" \
  -d '{"text":"Explain feature flags for AI models."}'

Example response:

{
  "reply": "Feature flags let you change behavior at runtime...",
  "model": "zai-org/GLM-5.2"
}

Inspect history and usage:

curl https://multi-model-inference-switcher-<id>.telnyxcompute.com/history

Agent SDK primitives used

The SwitcherAgent uses:

durable message history for chat context
actor state for total requests and model usage
the Telnyx binding for zero-credential AI Inference
KV Storage for the global model flag

The inference call looks like:

this.env.TELNYX.ai.openai.chat.createCompletion({
  model,
  messages,
  max_tokens: 2000,
  temperature: 0.7,
});

The key part is that model comes from KV, not a hardcoded constant.

Run it

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/multi-model-inference-switcher
npm install

Create and seed KV:

telnyx-edge storage kv create --name "switcher-flag"
telnyx-edge storage kv key put <kv-id> active-model moonshotai/Kimi-K2.6

Set your namespace ID in telnyx.toml, add your secret, and deploy:

telnyx-edge secrets add TELNYX_API_KEY <YOUR_API_KEY>
telnyx-edge ship

Production notes

Before exposing this publicly, add:

auth on the admin UI and /model
audit logging for model changes
a reviewed model allowlist
fallback behavior if the active model fails
latency and cost tracking per model
scoped flags by environment, tenant, or cohort

The small idea here is powerful: keep your app deployed, but make model selection something you can operate.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/multi-model-inference-switcher
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build an SMS Triage Bot on Telnyx Edge Compute

Sonam — Thu, 13 Aug 2026 18:58:07 +0000

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 },
    { role: "user", content: `Customer message: "${text}"` },
  ],
  max_tokens: 2000,
  temperature: 0.2,
});

The SMS reply uses the same binding pattern:

await this.env.TELNYX.messages.send({
  from: state.fromNumber || state.phoneNumber,
  to: from,
  text: replyText,
});

That means the example does not hardcode an API key in application code. Messaging and inference both go through this.env.TELNYX.

Try the debug endpoint

After deploying with telnyx-edge ship, you can test without sending a real SMS:

curl -X POST https://agent-sms-triage-bot-<id>.telnyxcompute.com/debug/triage \
  -H "Content-Type: application/json" \
  -d '{"from":"<customer-number>","to":"<triage-number>","text":"Why was I charged twice this month?"}'

Example response:

{
  "action": "triaged",
  "from": "<customer-number>",
  "to": "<triage-number>",
  "text": "Why was I charged twice this month?",
  "topic": "billing",
  "route": "billing-queue",
  "confidence": 0.95
}

Then inspect the actor history:

curl "https://agent-sms-triage-bot-<id>.telnyxcompute.com/history?number=<triage-number>"

Why this pattern is useful

For a small support workflow, this keeps the first version compact:

Telnyx Messaging receives and sends SMS
Telnyx AI Inference classifies intent
Edge Compute hosts the webhook
Agent SDK durable state stores routing memory

You can later replace queue names with real integrations: Slack, Zendesk, Salesforce, email, or an internal queue.

Production notes

Before using this with real customer traffic, I would add:

webhook signature verification
SMS opt-out and consent handling
duplicate webhook idempotency
PII redaction and retention controls
role-based route updates
human review for low-confidence classifications
alerting when outbound SMS fails

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/agent-sms-triage-bot
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build an AI Snooze Reminder Agent on Telnyx Edge Compute

Sonam — Thu, 13 Aug 2026 18:28:40 +0000

Most reminder examples stop at "send this message later."

This one goes a little further.

The scheduled-reminder-agent example sends an SMS reminder, waits for the user's reply, uses Telnyx AI Inference to classify whether the reply means "snooze" or "acknowledged," and then either marks the reminder done or schedules the next reminder with adaptive timing.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/scheduled-reminder-agent

What it does

The app runs on Telnyx Edge Compute with the Telnyx Agent SDK.

The flow:

POST /remind
  -> ReminderAgent.scheduleReminder()
  -> this.schedule(delay, "sendReminder")
  -> Telnyx Messaging sends the SMS
  -> user replies by SMS
  -> /webhooks/sms
  -> ReminderAgent.receiveReply()
  -> Telnyx AI Inference classifies intent
  -> reminder is acknowledged or snoozed

One actor instance owns one recipient's reminder state.

That means active reminders, snooze count, reply status, and scheduled work live together instead of being split across a webhook server, queue, scheduler, and database.

Agent SDK primitives used

The ReminderAgent extends the Agent SDK Agent class from @telnyx/edge-runtime.

It uses:

this.schedule() for durable reminder delivery and reply timeouts
this.setState() and this.getState() for per-phone-number reminder state
this.env.TELNYX.messages.send() for SMS
this.env.TELNYX.ai.openai.chat.createCompletion() for snooze detection

The [telnyx] binding in telnyx.toml gives the function a pre-authenticated Telnyx client:

[telnyx]
binding = "TELNYX"

So the application code does not hardcode an API key.

Main routes

POST /remind schedules a new SMS reminder
POST /webhooks/sms receives Telnyx inbound SMS replies
POST /cancel cancels a pending reminder
POST /debug/remind schedules a short test reminder
POST /debug/reply simulates an inbound SMS reply
GET /debug/state inspects actor state
GET /health/liveness and GET /health/readiness are health checks

Try it

After deploying with telnyx-edge ship, schedule a reminder:

curl -X POST https://scheduled-reminder-agent-<id>.telnyxcompute.com/remind \
  -H "Content-Type: application/json" \
  -d '{
    "to":"+15551230000",
    "from":"+15559870000",
    "message":"Time for your meeting",
    "delay_minutes":5
  }'

Then simulate a snooze reply:

curl -X POST https://scheduled-reminder-agent-<id>.telnyxcompute.com/debug/reply \
  -H "Content-Type: application/json" \
  -d '{
    "from":"+15551230000",
    "text":"snooze for 2 hours"
  }'

Inspect the state:

curl "https://scheduled-reminder-agent-<id>.telnyxcompute.com/debug/state?from=+15551230000"

Adaptive snoozing

If the user says something specific like "snooze for 2 hours," the model extracts that delay.

If the user just says "later" or "not now," the agent uses exponential backoff:

30 minutes -> 1 hour -> 2 hours -> 4 hours -> 8 hours

That makes the reminder less repetitive over time.

Production notes

Before using this in production, I would add:

webhook signature verification
SMS opt-out and consent handling
timezone-aware scheduling
idempotency for reminder creation and outbound sends
retry handling for failed SMS delivery
max snooze and escalation rules
PII-safe logs and retention policies

But as a starter pattern, this is a clean way to build scheduled agent workflows on Edge Compute.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/scheduled-reminder-agent
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Agent SDK quickstart: https://developers.telnyx.com/docs/agent-sdk/quickstart
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build an SMS Triage Bot on Telnyx Edge Compute

Sonam — Wed, 12 Aug 2026 01:59:23 +0000

Support SMS inboxes are usually a routing problem before they are an AI problem.

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

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 },
    { role: "user", content: `Customer message: "${text}"` },
  ],
  max_tokens: 2000,
  temperature: 0.2,
});

The SMS reply uses the same binding pattern:

await this.env.TELNYX.messages.send({
  from: state.fromNumber || state.phoneNumber,
  to: from,
  text: replyText,
});

That means the example does not hardcode an API key in application code. Messaging and inference both go through this.env.TELNYX.

Try the debug endpoint

After deploying with telnyx-edge ship, you can test without sending a real SMS:

curl -X POST https://agent-sms-triage-bot-<id>.telnyxcompute.com/debug/triage \
  -H "Content-Type: application/json" \
  -d '{"from":"<customer-number>","to":"<triage-number>","text":"Why was I charged twice this month?"}'

Example response:

{
  "action": "triaged",
  "from": "<customer-number>",
  "to": "<triage-number>",
  "text": "Why was I charged twice this month?",
  "topic": "billing",
  "route": "billing-queue",
  "confidence": 0.95
}

Then inspect the actor history:

curl "https://agent-sms-triage-bot-<id>.telnyxcompute.com/history?number=<triage-number>"

Why this pattern is useful

For a small support workflow, this keeps the first version compact:

Telnyx Messaging receives and sends SMS
Telnyx AI Inference classifies intent
Edge Compute hosts the webhook
Agent SDK durable state stores routing memory

You can later replace queue names with real integrations: Slack, Zendesk, Salesforce, email, or an internal queue.

Production notes

Before using this with real customer traffic, I would add:

webhook signature verification
SMS opt-out and consent handling
duplicate webhook idempotency
PII redaction and retention controls
role-based route updates
human review for low-confidence classifications
alerting when outbound SMS fails

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/agent-sms-triage-bot
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build a Voice Agent That Holds a Live Call on Telnyx Edge Compute

Sonam — Wed, 12 Aug 2026 00:35:01 +0000

Getting an AI agent to answer a phone call is only the beginning.

The harder part is keeping the call going.

This example builds a voice agent on Telnyx Edge Compute that answers an inbound call, speaks a greeting, listens with streaming transcription, sends the caller's speech to Telnyx AI Inference, speaks the reply with TTS, and then goes back to listening.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-voice-agent-holds-call

The call loop

The core flow is:

call.initiated
  -> answer
call.answered
  -> speak greeting
call.speak.ended
  -> start transcription
call.transcription final
  -> stop transcription
  -> run LLM turn
  -> speak reply
call.speak.ended
  -> listen again
call.hangup
  -> persist final call state

Each live call gets a VoiceAgent actor keyed by call_control_id.

That actor stores:

call phase
caller and callee
turn count
last transcript
last reply
durable message history

The main routes

POST /webhooks/voice receives Call Control webhooks
GET /debug/call?call_control_id=<call_id> inspects actor state
POST /debug/respond tests an LLM turn without a live call
GET /health/liveness and GET /health/readiness support health checks

The Agent SDK piece

The VoiceAgent extends the Agent SDK Agent class from @telnyx/edge-runtime.

It uses:

this.messages.add() to store caller and assistant turns
this.messages.toOpenAI() to format history for the model
this.setState() and this.getState() for durable call state
this.env.TELNYX.ai.openai.chat.createCompletion() for zero-credential inference through the [telnyx] binding

The model call looks like this:

const completion = await this.env.TELNYX.ai.openai.chat.createCompletion({
  model,
  messages: [{ role: "system", content: SYSTEM_PROMPT }, ...history],
  max_tokens: 200,
  temperature: 0.5,
});

The webhook handler speaks the returned text through Call Control TTS.

Why streaming transcription?

The sample uses Call Control streaming transcription because the app owns the conversation loop.

The caller speaks. Telnyx sends a final transcript. The app stops transcription, runs the LLM turn, speaks the reply, and starts transcription again after TTS ends.

That gives you room to add your own logic:

human handoff
CRM lookup
order status tools
turn limits
cost tracking
transcript summaries
safety rules

Deploy

npm install
telnyx-edge ship

Set the Call Control API key as an Edge secret:

telnyx-edge secret set TELNYX_API_KEY your_telnyx_api_key

Point your Call Control application webhook to:

https://edge-voice-agent-holds-call-<id>.telnyxcompute.com/webhooks/voice

Then call the Telnyx number assigned to that Call Control application.

Production notes

Before shipping this pattern for real callers, I would add:

webhook signature verification
idempotency for Call Control actions
max turn count and call-duration limits
human transfer
transcript redaction
latency monitoring across STT, LLM, and TTS
stronger barge-in handling
observability around call phases

But even as a starter, this is a useful reference for building a voice agent that can actually stay on the call.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-voice-agent-holds-call
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Call Control API reference: https://developers.telnyx.com/api-reference/call-control
Streaming transcription guide: https://developers.telnyx.com/docs/voice/programmable-voice/transcription
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build an SMS Support Agent with Follow-Up on Telnyx Edge Compute

Sonam — Tue, 11 Aug 2026 21:51:10 +0000

A lot of AI support demos stop after one reply.

Customer asks a question. Model answers. Demo done.

Real support usually needs a little more than that. You need message history, background processing, a way to send the reply, and sometimes a follow-up if the customer goes quiet.

This example builds that flow as an SMS support agent on Telnyx Edge Compute.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/sms-support-agent-with-followup

What it does

The app receives inbound SMS messages, routes each sender to a durable Agent SDK actor, calls Telnyx AI Inference, sends a reply through Telnyx Messaging, and schedules a 24-hour follow-up.

The flow:

Inbound SMS
  -> /webhooks/sms
  -> SupportAgent.receive()
  -> this.messages.add()
  -> this.queue("process")
  -> Telnyx AI Inference
  -> Telnyx Messaging reply
  -> this.schedule(24h, "followup")

The important part is that the webhook does not need to wait on the LLM. It stores the message and queues the work, so the webhook can acknowledge quickly.

Agent SDK primitives used

The SupportAgent extends the Agent SDK Agent class from @telnyx/edge-runtime.

It uses:

this.messages.add() for durable conversation history
this.messages.toOpenAI() to format history for the model
this.queue("process") for background AI processing
this.schedule(86400, "followup") for the next-day check-in
this.setState() and this.getState() for sender/recipient state
this.env.TELNYX for zero-credential Telnyx API access

The [telnyx] binding in telnyx.toml handles API auth:

[telnyx]
binding = "TELNYX"

Then the agent can call:

await this.env.TELNYX.ai.openai.chat.createCompletion(...)
await this.env.TELNYX.messages.send(...)

No API key is hardcoded in the application code.

The main routes

POST /webhooks/sms receives Telnyx message.received webhooks
POST /debug/message simulates an inbound SMS for testing
GET /debug/state inspects an actor state for a sender
GET /health/liveness and GET /health/readiness are health checks

Try the debug route

After deploying, you can simulate an inbound SMS:

curl -X POST https://sms-support-agent-<id>.telnyxcompute.com/debug/message \
  -H "Content-Type: application/json" \
  -d '{
    "from":"+15551230000",
    "to":"+15559870000",
    "text":"How do I send an SMS?"
  }'

Response:

{
  "action": "queued",
  "from": "+15551230000",
  "to": "+15559870000"
}

For real SMS, set your Telnyx Messaging Profile webhook URL to:

https://sms-support-agent-<id>.telnyxcompute.com/webhooks/sms

Then text the Telnyx number.

The follow-up logic

The follow-up task runs 24 hours later.

It checks the last message in the durable conversation history. If the last message is still from the assistant, the customer has not replied since the AI answer, so the agent sends:

Did that solve your problem? Reply yes or no, or ask for a human.

If the customer already replied, it skips the nudge.

That is the piece I like. The agent is not just a stateless webhook. It has memory and scheduled work.

Production notes

Before shipping this pattern in a real support workflow, I would add:

webhook signature verification
opt-out handling for SMS
idempotent outbound sends
rate limiting per phone number
human handoff rules
message retention policy
monitoring for queued and scheduled tasks

But as a starter pattern, this is a clean way to build an AI support agent that can answer, remember, and follow up.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/sms-support-agent-with-followup
Agent SDK docs: https://developers.telnyx.com/docs/agent-sdk
Agent SDK quickstart: https://developers.telnyx.com/docs/agent-sdk/quickstart
Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

A/B Test AI Prompts at the Edge with Telnyx Stateful Actors

Sonam — Tue, 04 Aug 2026 23:40:32 +0000

Changing a prompt is easy. Knowing whether the new prompt is actually better is the hard part.

This example builds a small prompt A/B testing API on Telnyx Edge Compute. You send one task and two prompt variants. The app runs both variants through Telnyx AI Inference, stores the experiment in a Stateful Actor, and lets users vote on which result they prefer.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-prompt-ab-tester

What it does

The app gives you a tiny evaluation loop:

create an experiment
compare two model responses
vote for variant A or B
close the experiment
check aggregate stats

Routes:

POST /experiments
POST /experiments/<id>/vote
POST /experiments/<id>/close
GET /experiments
GET /experiments/<id>
GET /stats
GET /health/liveness
GET /health/readiness

Create a prompt experiment

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments \
  -H "Content-Type: application/json" \
  -d '{
    "task": "Write a one-sentence tagline for an edge compute platform.",
    "variant_a": "You are a concise marketing copywriter. Return just the tagline.",
    "variant_b": "You are a technical explainer. Return just the tagline, focus on latency."
  }'

Response:

{
  "id": "exp-msf712rs-0",
  "task": "Write a one-sentence tagline for an edge compute platform.",
  "variant_a": {
    "prompt": "You are a concise marketing copywriter. Return just the tagline.",
    "response": "Real-time compute, right where your data lives."
  },
  "variant_b": {
    "prompt": "You are a technical explainer. Return just the tagline, focus on latency.",
    "response": "Execute code milliseconds from your users to eliminate network latency."
  },
  "votes_a": 0,
  "votes_b": 0,
  "status": "open",
  "created_at": "2026-08-04T21:51:55Z"
}

Vote on a result

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments/exp-msf712rs-0/vote \
  -H "Content-Type: application/json" \
  -d '{"variant":"a"}'

Close the experiment:

curl -X POST https://edge-prompt-ab-tester-<id>.telnyxcompute.com/experiments/exp-msf712rs-0/close

Check stats:

curl https://edge-prompt-ab-tester-<id>.telnyxcompute.com/stats

Example:

{
  "total_experiments": 3,
  "open_experiments": 2,
  "closed_experiments": 1,
  "total_votes": 15,
  "leader": "variant_a",
  "leader_votes": 9
}

The AI call

The app uses:

POST /v2/ai/chat/completions

Default model:

zai-org/GLM-5.2

Each prompt variant becomes the system message. The task becomes the user message. Both variants run against the same input, which makes the comparison easier to reason about.

Why Stateful Actors?

Prompt tests need a little bit of memory.

This example uses an ABTester Stateful Actor to store:

experiments
prompt variants
model responses
vote counts
open or closed status
aggregate stats

That means the API can remember experiment state without adding a separate database just for the demo.

Run it

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-prompt-ab-tester

Store your API key as an Edge Compute secret:

telnyx-edge auth api-key set <YOUR_API_KEY>
telnyx-edge secrets add TELNYX_API_KEY "KEY0123..."

Install and deploy:

npm install
telnyx-edge ship

Then use the deployed URL to create experiments and collect votes.

Production notes

Before using this pattern for real product decisions, I would add:

authentication
evaluator identity
duplicate vote prevention
randomized or blinded variants
fixed evaluation sets
scoring rubrics
prompt version history
privacy controls for sensitive tasks

But even in this small form, it is useful. Prompt changes should not be judged only by vibes. They should leave a trail of examples, votes, and outcomes.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-prompt-ab-tester
Telnyx Edge Compute docs: https://developers.telnyx.com/docs/edge-compute
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai
Telnyx Portal: https://portal.telnyx.com/

Build an Edge Crop Advisory API with Telnyx AI Inference

Sonam — Tue, 04 Aug 2026 20:50:37 +0000

I built this as the next step after the Edge URL Summarizer example. The URL summarizer showed a simple pattern: run an AI workflow at the edge, fetch external content when needed, summarize it, and keep useful state close to the request. This crop advisory example takes that same pattern into a more real-world workflow.

Instead of only summarizing a page, the app accepts a farmer’s field note or an agriculture advisory URL, classifies the crop issue, returns structured JSON, stores the advisory in a Stateful Actor, tracks issue/severity stats, and flags critical cases for escalation.

So the goal is not “AI gives farming advice” in a vacuum. The goal is to show how an edge-hosted AI app can turn messy field input into something operational: triage, history, stats, and a clear handoff path when a human expert needs to step in.
Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-agri-crop-advisory

What it does

You send the app a crop issue description:

curl -X POST https://edge-agri-crop-advisory-<id>.telnyxcompute.com/advisory \
  -H "Content-Type: application/json" \
  -d '{"description":"Tomato leaves have holes all over them. I can see green caterpillars on the underside of the leaves."}'

It returns a structured advisory:

{
  "id": "adv-msf1zxyc-0",
  "farmer_description": "Tomato leaves have holes...",
  "source": "text",
  "crop_type": "tomato",
  "issue_type": "pest",
  "severity": "medium",
  "confidence": 0.76,
  "recommendation": "Inspect the underside of leaves and remove visible caterpillars. Consider an appropriate biological or labeled treatment if damage continues.",
  "escalate": false,
  "generated_at": "2026-08-04T19:31:04Z"
}

If the case is critical, it gets flagged:

{
  "severity": "critical",
  "escalate": true,
  "escalated_to": "agronomist-on-call"
}

Routes

The example includes:

POST /advisory - create an advisory
GET /advisories - list recent advisories
GET /advisories/<id> - get one advisory
GET /stats - see issue/severity/escalation stats
GET /health/liveness - liveness check
GET /health/readiness - readiness check

POST /advisory accepts either:

description
url

If you pass a URL, the app fetches the page, strips HTML, and uses that text as input.

The AI call

The app calls:

POST /v2/ai/chat/completions

The current code path uses:

zai-org/GLM-5.2

The prompt asks the model to return JSON only with:

crop_type
issue_type
severity
confidence
recommendation

Issue types are constrained to:

disease | pest | nutrient | water | weather | unknown

Severity is constrained to:

low | medium | high | critical

That structure makes the response easier to store, display, route, and review.

The Stateful Actor part

The app uses a CropAdvisory Stateful Actor.

It stores:

advisories by ID
total advisory count
counts by issue type
counts by severity
escalation count
recent crop types

So after a few requests, you can inspect the accumulated stats:

curl https://edge-agri-crop-advisory-<id>.telnyxcompute.com/stats

Run it

Clone the repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-agri-crop-advisory

Set your Telnyx API key:

telnyx-edge auth api-key set <YOUR_API_KEY>
telnyx-edge secrets add TELNYX_API_KEY "KEY0123..."

Install and deploy:

npm install
telnyx-edge ship

Health check:

curl -sS --retry 30 --retry-delay 5 \
  https://edge-agri-crop-advisory-<id>.telnyxcompute.com/health/liveness

Create an advisory:

curl -X POST https://edge-agri-crop-advisory-<id>.telnyxcompute.com/advisory \
  -H "Content-Type: application/json" \
  -d '{"description":"My corn has yellow streaks on bottom leaves with dark brown spots. About 30% of plants affected."}'

Production notes

This is a triage example, not a replacement for an agronomist.

Before using this pattern in production, I would add:

authentication
farmer/account identity
region and crop stage
photo input
weather data
human review for high and critical cases
localized treatment guidance
safety warnings
SMS or webhook escalation

Still, the pattern is useful: edge function for intake, AI model for structured classification, Stateful Actor for advisory history and stats.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-agri-crop-advisory
Stateful Actors Quick Start: https://developers.telnyx.com/docs/edge-compute/stateful-actors/quick-start
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Chat Completions API: https://developers.telnyx.com/api/inference/chat-completions
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Build a URL Summarizer at the Edge with Telnyx AI Inference

Sonam — Tue, 04 Aug 2026 19:06:39 +0000

I have been playing with a pattern that feels useful for small AI tools:

accept a request
call an AI model
cache the result close to where the request runs
avoid building extra infrastructure until you actually need it

This example applies that pattern to URL summarization using Telnyx Edge Compute Stateful Actors.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-url-summarizer

What it builds

The app is a Node.js / TypeScript Edge Compute example.

You send it a URL:

curl -X POST https://edge-url-summarizer-<id>.telnyxcompute.com/summarize \
  -H "Content-Type: application/json" \
  -d '{"url":"https://telnyx.com/blog"}'

On the first request, it:

fetches the page
extracts text from the HTML
sends the text to Telnyx AI Inference
asks for exactly three bullet points
stores the result in Stateful Actor storage

On repeat requests for the same URL, it returns the cached summary.

API routes

The example includes:

POST /summarize - summarize a URL
GET /summarize/cached?url=... - read a cached summary
POST /summarize/refresh - invalidate a cached URL
GET /stats - view cache hit/miss stats
GET /cached - list cached URLs
GET /health/liveness - liveness check
GET /health/readiness - readiness check

Example response

{
  "url": "https://example.com/article",
  "title": "Example Article",
  "bullets": [
    "The article explains the main problem.",
    "The implementation uses an edge function and AI model.",
    "Cached results make repeat requests faster."
  ],
  "word_count": 1234,
  "generated_at": "2026-08-04T12:00:00Z",
  "cached": false
}

Call the same URL again and the response comes back with:

{
  "cached": true
}

The Telnyx AI call

The app calls:

POST /v2/ai/chat/completions

The current sample uses:

zai-org/GLM-5.2

The model is prompted to return JSON only:

{
  "bullets": ["point 1", "point 2", "point 3"]
}

That keeps the app response easy to consume from a dashboard, workflow, or internal tool.

The Stateful Actor part

The cache lives in a Telnyx Stateful Actor.

The actor stores:

summaries by URL
cache hits
cache misses
total requests
unique URL count

That means the app can remember previous summaries without adding Redis or a database just for the demo.

Run it

Clone the repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-url-summarizer

Set your Telnyx API key:

telnyx-edge auth api-key set <YOUR_API_KEY>
telnyx-edge secrets add TELNYX_API_KEY "KEY0123..."

Install and deploy:

npm install
telnyx-edge ship

Test the deployment:

curl -sS --retry 30 --retry-delay 5 \
  https://edge-url-summarizer-<id>.telnyxcompute.com/health/liveness

Summarize a page:

curl -X POST https://edge-url-summarizer-<id>.telnyxcompute.com/summarize \
  -H "Content-Type: application/json" \
  -d '{"url":"https://telnyx.com/blog"}'

Check cache stats:

curl https://edge-url-summarizer-<id>.telnyxcompute.com/stats

What I would add before production

For a production version, I would add:

authentication
rate limiting
URL allowlists or SSRF protections
URL normalization
TTL-based cache expiration
better HTML extraction
retries and observability

But as a runnable example, this is a clean way to see Edge Compute, Stateful Actors, and Telnyx AI Inference working together.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-url-summarizer
Stateful Actors Quick Start: https://developers.telnyx.com/docs/edge-compute/stateful-actors/quick-start
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Chat Completions API: https://developers.telnyx.com/api/inference/chat-completions
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai

Route Voicemails with Python and Telnyx AI

Sonam — Thu, 30 Jul 2026 18:18:05 +0000

I built a small Flask example that turns voicemail into a routing workflow.

Code:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/voicemail-smart-router-python

The app accepts either:

a voicemail transcript
an uploaded voicemail audio file

For audio, it transcribes the voicemail first. Then it uses Telnyx AI Inference to classify the message and decide where it should go.

Run it

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/voicemail-smart-router-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Configure .env:

TELNYX_API_KEY=your_telnyx_api_key
AI_MODEL=zai-org/GLM-5.2
FALLBACK_MODEL=meta-llama/Llama-3.3-70B-Instruct
HOST=127.0.0.1

Optional Slack webhook for urgent messages:

SLACK_WEBHOOK=https://hooks.slack.com/...

Classify a transcript

curl -X POST http://localhost:5000/voicemails/transcript \
  -H "Content-Type: application/json" \
  -d '{
    "transcript": "This is an emergency. Our production system is down and we need help immediately.",
    "caller_number": "+17177247292"
  }'

Example response:

{
  "category": "urgent",
  "confidence": 1.0,
  "priority": "high",
  "reason": "The caller reports a production system outage requiring immediate attention.",
  "suggested_action": "Escalate immediately to the on-call engineering team.",
  "route": "slack",
  "routed_to": "#oncall-alerts",
  "routing_status": "delivered"
}

Process voicemail audio

curl -X POST http://localhost:5000/voicemails/process \
  -F "file=@voicemail.wav" \
  -F "caller_number=+17177247292"

For audio, the app calls:

POST /v2/ai/audio/transcriptions

using:

distil-whisper/distil-large-v2

Then it calls:

POST /v2/ai/chat/completions

to classify the transcript.

Routes included

POST /voicemails/transcript
POST /voicemails/process
GET /voicemails
GET /voicemails/<id>
GET /routes
GET /health

Production ideas

This sample uses in-memory storage and a simple routing map.

For production, I would add:

auth
durable storage
webhook ingestion from real voicemail events
retries for failed delivery
real email, ticket, and CRM integrations
review queues for low-confidence messages
audit logs
configurable routing rules
PII handling before storing transcripts

The useful pattern is not just classification. It is classification plus action. The model turns a voicemail into structured intent, and the application routes it to the right workflow.

Resources:

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/voicemail-smart-router-python
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Audio Transcriptions API: https://developers.telnyx.com/api/inference/create-transcription
Chat Completions API: https://developers.telnyx.com/api/inference/chat-completions
Telnyx AI skills and toolkits: https://github.com/team-telnyx/ai