Where LLMs fit in SMS, voice and messaging platforms

We have built virtual-number and messaging products since before language models were useful, and we worked with iproxy.online, which runs mobile proxy infrastructure on thousands of Android phones. Both kinds of system generate more events per second than any team can read, and both attract the people a platform least wants as customers. That shapes how we think about LLMs in telecom. They are useful in four specific places, and in each one the volume and the latency budget decide the design before the model does.

Classification

The first use is sorting traffic. Is this message spam, phishing, a one-time code, a marketing blast with no opt-out, a grey-route attempt wearing a legitimate sender ID? Rules do this today, and rules rot. The people on the other side read them faster than you can write them.

A language model reads the message the way an operator would. But a messaging platform cannot spend a second and a cent on each of millions of messages a day. So the production shape is a small, fast model, or a classifier fine-tuned on your own labelled traffic, running in a few milliseconds per message. The large model is used for two things only: labelling the training set in the first place, and judging the small fraction of messages the small model is unsure about.

The labelled set matters more than the model. Pull a few thousand messages from your own routes with the outcome you already know (blocked, delivered, complained about) and measure everything against that. A classifier that scores well on a public spam dataset and badly on your traffic is useless, and this happens often, because your traffic has your customers’ quirks in it.

Decide the latency budget first. If routing decisions have to be made inline, the model has a single-digit millisecond budget and probably has to run on your own hardware. If classification can happen a few seconds after delivery, for reporting and account scoring, a hosted small model is fine and the design gets much simpler.

Abuse detection

The costly abuse on a messaging or proxy platform is a pattern across an account rather than one message: the sign-up with a disposable email, the jump in volume on day three, the destination mix that looks like nobody’s legitimate customer base, the proxy traffic that all goes to one login page.

Here the large model earns its cost, because the volume is small. A platform has thousands of accounts, not millions of messages, and each one can afford a slow, careful look once a day or on every suspicious event. We feed the model a structured summary of the account’s behaviour, the signals the rules already compute, and the history of similar accounts, and ask for a judgement with reasons. The reasons go to the operations queue beside the score, so a person can agree or override in seconds.

On iproxy.online the equivalent problem is spotting the customer who will get a phone’s SIM blocked or a payment charged back. The signals are different; the shape of the system is the same.

We do not let the model act on its own at this layer. Suspending an account is irreversible in the sense that matters. A good customer locked out of their messaging on a Friday is gone. The model ranks and explains; a person decides, at least until the review log shows the person agreeing with the model nearly every time.

Support agents

A messaging platform’s support queue is mostly the same forty questions. Why was my message rejected, how do I register a sender ID in this country, why is my number not receiving codes, how does billing work on this route. The answers are in the documentation and in the account.

An agent that reads both and answers in the customer’s chat is the easiest win on this list, and the one we would start with if the classifier is not urgent. It needs retrieval over the real documentation, read access to the account so it can say “your last three messages to that country were rejected for an unregistered sender ID” rather than “please check your sender ID”, and a hard rule that anything involving money, a suspension or a legal question goes to a person.

Here latency barely matters and the large model is the right choice. A ten-second answer that is correct beats an instant answer that is generic. Evaluate it the same way as everything else: a few hundred past tickets with the resolution the human gave, and a comparison.

Provisioning and compliance automation

Number ordering, sender registration and KYC checks are forms, documents and carrier portals. The work is reading a registration certificate, matching it to the account, filling the carrier form, noticing that the company name on the document does not match the one on the account, and chasing the customer for the missing page.

Models are good at the reading and the matching, and the audit trail is the point. Every extracted field links back to the page it came from, every decision is logged with the model’s reasoning, and a person signs off before anything is submitted to a carrier or a regulator. Nobody wants to explain to a carrier that a model filed the registration on its own.

Lessons from running the infrastructure

Design for the peak. Messaging traffic is spiky, and the moment a classifier’s queue backs up is the moment it was supposed to help. Any inline model needs a time limit and a decision about what happens when the limit is hit. Fail open or fail closed is a business decision. Make it in a meeting rather than discovering it in an incident.

Keep the model swappable. Most of the models we used two years ago are not the ones we would pick today. The code that calls the model should be a thin layer with the evaluation set behind it, so a swap is an afternoon and a number rather than a rewrite.

Log everything the model saw. When an operator asks why a message was blocked, “the model said so” is not an answer. The input, the output and the reasoning belong in the log next to the message ID.

Put the operations team in the loop from the first week. They know which rules are load-bearing and which are superstition. The classifier will replace some of each, and the team will tell you which is which only if they trust it.

If you run a messaging, voice or proxy platform and have a queue nobody is reading, the telecom and messaging AI page covers what we build, and you can tell us about the queue.