Why we made the agent an extension

Most AI voice products begin with a migration. Point your numbers here, run your calls through our platform, and once that’s done the agent can answer. For a service provider with a base of customers already running on a softswitch, that first step is the whole project — and it is usually where the project stops.

Telzino registers as a SIP extension instead. The agent is a device on the PBX you already run, in the same sense that a desk phone is. Nothing is ported, no dial plan changes, no session border controller work.

What that buys you

The obvious benefit is speed. Adding an extension is a task your provisioning team does dozens of times a day, so the path from “we should try this” to “it answered a call” is measured in minutes rather than change windows.

The less obvious benefit matters more: the blast radius is one extension. If the agent is wrong for a customer, you delete the extension and the phone system is exactly as it was. Nobody has to unwind a migration. That changes the conversation from a platform decision into an experiment, and experiments get approved.

What it doesn’t change

The agent is still a full participant in the phone system. It can read the directory, follow the timeframes you already maintain, transfer to a colleague, and hand the call to a person when the conversation needs one. On Netsapiens it goes further and runs inside the portal your customers already log into.

The part we got wrong first

Our early assumption was that customers would want the agent to own the number. They didn’t. They wanted it behind the number they already had, reachable from the auto-attendant they had already built, with their existing rules intact. The extension model is not a compromise to avoid migration work — it is what people actually asked for.

If your PBX can register an extension, it can run an agent. That is the whole integration.