An AI Mission for Telecom: SIM Provisioning

Every carrier measures provisioning by whether the order succeeded. The states that generate the support calls are the ones where it half-succeeded — and nothing in the stack is responsible for noticing.
A customer walks out of a retail store holding a phone that works. Data flows, the browser loads, the store associate watched the screen go green and closed the ticket. Three days later the same customer calls in because voicemail has never worked, because the plan on their bill is not the plan they were sold, and because a roaming bar they never asked for is attached to their line. Nothing failed. The order system recorded a completed activation, the billing platform holds a subscriber record, the subscriber register in the core network holds an entry, and the charging system is metering usage. Every one of those systems, asked individually, will report that it did its job. They simply do not agree with each other about what the customer bought, and no component in the chain has the job of asking whether they do.
That gap is the real subject of SIM provisioning, and it is badly served by the way the industry talks about it. Provisioning is usually described as a pipeline — take an order, push it to the network, confirm activation — as if it were a single operation with a single outcome, when it is really a distributed transaction spread across an order capture system, a billing and rating platform, a subscriber data register, an IMS and voicemail layer, a number inventory, a SIM or eSIM profile manager, a charging function, and often a partner system beyond the carrier's walls. Those systems were built in different decades by different vendors under different data models, and none was designed to participate in somebody else's transaction. The interesting state in a provisioning estate is therefore never success and rarely outright failure. It is the partial commit: the subscriber who exists in billing but not in the network, or in the network but not in billing, or in both but with two different ideas of what they are entitled to.
There is no coordinator, so every order is a bet on best effort
In a database, a transaction touching several tables either lands completely or leaves no trace, because a coordinator holds the whole thing until every participant agrees to commit. Provisioning has the same shape and none of the machinery. Nothing can hold a subscriber register, a billing platform, and a third-party profile manager in a prepared state while it decides whether the activation as a whole is valid, and there is no realistic path to building it, because the participants do not expose the primitives that would make it possible. What exists instead is a sequence of independent calls, each with its own timeout, its own retry semantics, and its own definition of "done", orchestrated by a workflow that hopes they all land.
Most of the time they do, which is precisely what makes the failures so hard to see. When they do not, the divergence is created quietly and by ordinary causes: a call that timed out at the transport layer after the remote system had already applied the change, so the orchestrator retried and created a duplicate; a step that succeeded but returned a response the workflow could not parse, so it was recorded as failed and compensated for on one side only; an ordering assumption that held for years until an upgrade changed the latency profile and two updates began arriving out of sequence. Compensation logic — the rollback meant to undo earlier steps when a later one fails — is itself a set of network calls that can time out, so the cleanup path carries the same failure modes as the path it cleans up after, is exercised far less often, and is correspondingly less trustworthy.
Semantics make it worse, because the same subscriber state carries different names and different meanings in each system, and the mapping between them lives in integration code and tribal memory rather than in any shared model. A line that billing considers suspended for non-payment, the network may hold as barred for outgoing calls only; a plan change the catalog treats as one product swap may decompose into several network-side attributes, most updated atomically and one not. When a carrier migrates a billing platform, absorbs a portfolio through an acquisition, or moves from physical SIM to remote profile provisioning, those mappings are re-derived under time pressure, and every migration leaves behind a population of subscribers whose true state is a matter of interpretation.
The partial commit is not an edge case, it is the inventory
Once you accept that inconsistency is produced continuously by normal operation, the useful question stops being how to prevent it and becomes what kinds you are carrying and for how long. The taxonomy is short, and every entry has a direct financial or customer consequence. A subscriber present in billing but absent or incomplete in the network is a paying customer with degraded service, and they will find out before you do. A subscriber present in the network but not correctly reflected in billing is service delivered without revenue recognized, the least visible and often the most expensive category, because nobody calls to complain about a bill they are not receiving. Entitlement drift — where the network grants a feature the customer no longer pays for, or withholds one they do — sits between the two and generates both leakage and complaints. Orphaned resources are the fourth kind: numbers, identifiers, and profiles held as assigned to accounts that no longer exist, quietly shrinking a finite pool.
What unites these is that they are invisible from the vantage point everyone actually monitors. Order-level dashboards report on orders, and each of the orders that created these states was, from its own perspective, fine; the systems are internally consistent, and only the estate is not. Detecting the difference means reading two or more systems of record at once, translating their vocabularies onto common ground, and comparing populations rather than transactions — a different operation from anything in the provisioning path, and one no single component owns. So it gets done as a project: a sweep before a migration, an audit after a bad quarter, a script somebody wrote once and left running until it broke. Between those sweeps, divergence accrues without a meter.
One class deserves separate treatment, because subscriber identity is exactly the sort of state reconciliation touches. Any divergence in the binding between a person, an account, and a SIM profile should be treated as the highest-severity inconsistency there is, and it deserves the opposite of automatic repair: detect it, freeze it, and route it to a human with the authority and the training to investigate, with the identity-verification controls around any change to that binding treated as something to strengthen and audit rather than streamline. Reconciliation should make those controls easier to prove and harder to bypass; a design that silently harmonizes identity records to whichever system spoke last is worse than no reconciliation at all.
The discipline is continuous repair, not a better pipeline
If inconsistency is generated continuously, then the only proportionate response is a capability that runs continuously — one that reads both sides of every important boundary on an ongoing basis, produces a classified diff rather than an alert, decides for each class whether the divergence is repairable, executes the repair where it plainly is, and escalates where it is not. The reason this has historically been done by sweeps rather than by a standing function is that the hard part is not the comparison but the interpretation. Deciding whether a subscriber marked suspended in one place and barred in another represents the same real-world condition requires context encoded nowhere: the catalog's history, the recent orders on the account, the known behavior of a particular integration, whether a migration is in flight. A rules engine can encode last year's version of that context and will be quietly wrong about this year's.
This is where reasoning systems change the economics rather than merely the interface, and the distinction is worth stating bluntly, because the market is full of things that do not. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear value, and what it calls "agent washing" — established rule engines and dashboards relabeled without any change in what they can actually do unattended. A tool that flags a mismatch and waits for a person has not solved reconciliation; it has added another queue to the one already unstaffed. What closes the loop is something that can hold the semantics of several subscriber-bearing systems in one working model, reason about which side is authoritative for a given attribute, take corrective action through the same interfaces an engineer would use, and stop at a human gate where judgment or authority genuinely belongs — anything touching identity, anything touching money above a threshold, anything it has not seen before.
Framed that way, provisioning reconciliation is a good example of what the growing body of work on the autonomous enterprise describes as the shift from instrumenting a process to owning it end to end. It is also the shape of what StudioX calls an AI Mission: a standing objective rather than a triggered workflow, carried by specialist agents that reach into each system of record through its own interface, share one view of subscriber state, and run under explicit human-in-the-loop gates. The value is not that a machine found a mismatch faster. It is that the mismatch stops being something a carrier discovers when a customer calls, and becomes something the estate corrects about itself while nobody is watching.
The mental model worth carrying away is that a carrier's true subscriber state is not what the orders said and not what any single platform believes; it is the intersection of what every system agrees on, and the distance between that intersection and the union is the real inventory of customer-facing failures waiting to surface. Measured that way, the number that matters about provisioning is not the completion rate of orders but the half-life of divergence: how much disagreement exists across the estate at any moment, and how long a given piece of it survives before something detects and repairs it. Carriers that keep optimizing the pipeline will keep getting more efficient at producing states nobody checks, while the ones that treat reconciliation as a permanent, running function will find that most of what they used to call provisioning defects were never defects in provisioning at all — they were the accumulated silence between systems that were never built to agree.
Discussion
No comments yet — start the conversation.