Telnyx AI Assistants Review: Voice Agents Inside the Carrier

Telnyx AI Assistants is the platform where I run the most agents in production, and it earned that position for one structural reason: the AI agent lives inside the carrier. The number, the SIP trunk, the call control API, and the assistant are all in one account. There is no handoff between a telephony vendor and an AI vendor, no second bill, and no arguments about whose side the problem is on when a call goes wrong. For a telecom client I run six-plus live assistants in a multi-tenant setup, plus around sixteen demo agents for their prospects. That fleet has taught me exactly where this platform is strong and exactly how it fails.

What it actually is

You create an assistant in the Telnyx portal or through their API. It has instructions (the system prompt), a model, a voice, greeting text, dynamic variables, and a set of tools. You assign it a phone number you already own in the same account, or point a SIP connection at it. When a call comes in, Telnyx handles the audio, runs the conversation loop, and lets the assistant call tools mid-call.

The tooling story is where it gets interesting. Assistants can call HTTP endpoints, and they can connect to MCP servers, which means you can expose a whole set of capabilities to an agent through one integration rather than defining tools one at a time. There are also built-in telephony tools: transfer the call, hang up, send DTMF. Those built-ins matter because they operate on the live call rather than through an external API, which is exactly what you want when a caller is waiting.

Because everything is API-driven, you can operate a fleet programmatically. My multi-tenant setup edits assistants over the API, keeps per-client configuration in a datastore, and injects it at call time through dynamic variables. That is not a feature you notice on a single build. It is the entire reason a fleet is maintainable.

What I have shipped on it

Six-plus live assistants for one telecom client, each fronting a different end business, all on separate numbers, all sharing a common architecture. Add roughly sixteen demo assistants that exist so a salesperson can hand a prospect a number and say call this. The demos are cheap to stand up and they close deals, the same pattern I use on ElevenLabs Agents.

The live ones do real work: answering, qualifying, routing to the right department, transferring to humans, taking messages after hours. They pull per-tenant data at call time so the same assistant architecture can greet callers with the right business name, hours, and service list. Everything I know about running voice agents at scale, rather than building one, I learned on this fleet.

What it is great at

One vendor for number and agent. When a call fails you look in one place. You have the call detail record, the SIP signaling, and the assistant's conversation log in the same account, correlated by the same call ID. Anyone who has debugged a voice agent across two vendors knows what that is worth. The alternative is exporting logs from one system and timestamps from another and hoping they line up.

Real call control. The assistant can act on the live call, not just talk about it. Transfers, DTMF, hangup: these are first-class operations against the actual call leg. That makes call transfer flows genuinely reliable once you configure them correctly, which brings me to the biggest gotcha on this page.

Fleet operations through the API. Every part of an assistant is patchable over HTTP: instructions, model, voice, greeting, variables, tools. I can push a prompt fix to a live assistant in seconds without touching a UI. For multi-tenant agency work this is not a nice-to-have, it is the whole thing.

Dynamic variables. Values injected at call time let one assistant serve many tenants. Business name, hours, service list, and destination extension all come from data rather than from the prompt. Fewer assistants, less drift, one place to fix a bug.

Cost structure. Carrier-native pricing means the telephony leg is priced like telephony, not marked up as an AI feature. On a per-minute basis it is one of the cheaper ways to run a real phone agent.

Where it bites you

These are the ones that cost me actual nights, and all four look like something other than what they are.

Empty dynamic variables produce total silence on answer. An assistant configured with an empty dynamic variables object answered the call and then said nothing. Dead air. No greeting, no error, no failed call record. It looks exactly like a carrier problem, and I chased it as one for far too long before finding it was a config bug. If your assistant answers and goes silent, check the dynamic variables before you check anything else. I wrote the full diagnostic sequence in voice agent dead-air debugging.

Unsubstituted placeholder tokens silently break the prompt. If your instructions contain a template token that never got a value, the prompt does not error. It goes to the model with a literal brace-wrapped token in it, and the model does something unpredictable, usually mentioning the token or ignoring the surrounding sentence. The assistant seems to have "forgotten" its instructions. Always render and read the final instructions after substitution, not the template. See dynamic variables for the concept.

Transfer tools must use the live call's control ID. This one is unambiguous and it will get you once. A transfer tool has to reference the current call's control ID, injected at call time. If you hardcode a value, or copy a working config from another assistant, the transfer returns a 422 and the caller is stuck listening to an agent that just promised to connect them. It is one of the worst failure modes possible because the caller was mid-way to a human and now has nothing. Test transfers on a real call to a real phone every single time you touch that tool.

No fallback model means dead air during an outage. If you configure a primary model and no fallback, an upstream model outage produces silence on answer. Same symptom as the dynamic variables bug, completely different cause, which is precisely why the debugging is annoying. Always configure a fallback model. It costs nothing until the day it saves the client's phone line.

Assistant versioning needs discipline. Editing a live assistant is easy, and that cuts both ways. Know which version is serving traffic before you patch it, and keep a record of what changed. On a fleet, an unlogged prompt edit at 11pm is a mystery for someone else at 9am.

Voice selection is more limited than a dedicated voice platform. The voices are perfectly usable, and there are good options, but if the client is precious about a specific voice character, a TTS-first platform gives you more range.

Pricing model as of mid-2026

Telnyx prices AI assistants per minute of conversation, layered on top of standard carrier pricing for numbers and inbound or outbound minutes. Numbers are a small monthly fee each. Minutes are fractions of a cent to a couple of cents depending on type and destination. The AI conversation charge is the larger line, and it is still measured in cents per minute rather than dollars. Model usage may bill separately depending on which model you select, so a cheap model on a chatty agent can be cheaper than an expensive model on a terse one.

There is no seat licensing to speak of, which suits agency work: you pay for what the calls actually cost, and you can run twenty demo assistants that take almost no traffic for almost nothing. That is genuinely different from platforms with per-agent or per-seat fees, where a demo fleet becomes a real line item. For overall project budgeting see how much an AI chatbot costs.

Who should pick Telnyx AI Assistants

Pick it if you are already a Telnyx customer or you are building something telephony-heavy, because having numbers, SIP, call control, and the agent in one account removes an entire class of problems. Pick it if you run many agents rather than one, since the API-first design and dynamic variables make multi-tenant fleets tractable. Pick it if transfers, IVR-replacement, and department routing are central to what the agent does, because the call control primitives are real. Pick it if per-minute cost matters at volume.

Skip it if your deliverable is primarily a website chat widget, because this is a voice platform living inside a carrier and chat is not the point. Skip it if you want the absolute best voice quality and nothing else matters, where a TTS-first platform wins. Skip it if you want a visual canvas your client can edit themselves, which is Voiceflow territory. And if you are choosing between the two big carrier-adjacent options, I broke that down in Telnyx vs Twilio for voice agents.

FAQ

My assistant answers and then there is silence. What is wrong?

Check in this order: empty or malformed dynamic variables, unsubstituted placeholder tokens in the instructions, and no fallback model configured during a primary model outage. All three produce identical dead air on answer, and none of them look like a config bug from the outside. I have shipped all three of these mistakes personally.

How do I make call transfers work reliably?

The transfer tool must reference the live call's control ID, injected at call time rather than hardcoded. Get that wrong and you get a 422 with the caller stranded. Then design the no-answer path: where does the caller go if the human does not pick up? Test the whole thing by calling from a real phone, not a simulator.

Can one assistant serve multiple businesses?

Yes, and that is the strongest reason to be here. Put the per-business details into dynamic variables injected at call time, keep the instructions generic, and one assistant architecture serves many tenants. It also means you fix a prompt bug once instead of six times.

How does testing work, and what does the simulator miss?

The simulator cannot inject the system variables that a real call provides, most notably caller ID, so anything keyed off the caller's number behaves differently live. That gap has hidden real bugs from me. Call the number from your own cell before any client sees it. My broader routine is in testing voice agents.

Is it cheaper than assembling the pieces myself?

At small and medium volume, yes, and the real saving is operational rather than financial. One vendor, one set of logs, one bill, and correlated call records mean incidents get resolved in minutes instead of hours. If you are running at large enough scale to negotiate carrier rates and staff an on-call team, assembling your own stack starts to make sense.