International roaming still settles through bilateral agreements, negotiated one counterparty at a time. The structural complexity of those agreements (OECD, 2013) is documented and unglamorous: each pair of operators sets its own wholesale terms, on its own renewal cadence, in its own currency of concessions. That is the published half of the fact. The half nobody publishes is what the structure does to an operations team — because every agreement is an input to a routing decision, and the decisions multiply with corridors, hours, and traffic classes until the review cycle is slower than the thing it reviews.
A top 10 global telecom company reached that point on international roaming margin. ML LABS was engaged through Gigster to design and build a custom ML platform that could analyze roaming traffic worldwide and optimize cost and routing together, running on roughly 1TB of new data every day: live network telemetry, agreement terms, and historical traffic patterns. The operator is not named here, and their operational volumes are theirs to publish, not ours. What follows is the architecture, the decisions, and the cleared outcomes.
That is the kind of workload ML LABS is built for — more than ten heavy-workload systems taken to production over fifteen-plus years, across healthcare, telecom, PropTech, and finance. This one had the largest decision surface of any of them.
Why Manual Review Was Losing
The manual workflow had reached a point where the decision space was structurally larger than the team could traverse. Each routing decision sat at the intersection of carrier agreement terms, real-time congestion, regional regulatory constraints, and per-corridor demand forecasts. By the time analysts had modeled one corridor in a spreadsheet, the demand pattern they had modeled against was already a week old. The operator held a portfolio of bilateral agreements across its global footprint, and the portfolio grew as it expanded — so the surface widened faster than the review capacity did.
Two forces made that worse rather than merely bigger. The bilateral terms changed on different cadences, so the pricing baseline against which analysts compared options was never stable long enough to reason about. And traffic itself was becoming more volatile as roaming usage shifted between consumer travel cycles and enterprise patterns — the wholesale settlement structure that governs those flows (GSMA, 2024) assumes commercial terms move slowly while traffic moves fast, which is exactly the mismatch that makes the arithmetic expensive. Every analytical answer had a shrinking shelf life, and margin leaked in the gap — which is where the operational margin in telecom actually sits (McKinsey, 2024): not in the headline tariff, but in the thousands of small routing decisions nobody has time to revisit.
Three signals tell an operator that this line has already been crossed, and they are worth measuring before any build is funded. Margin per session drifts downward on corridors that were profitable a quarter earlier, but the drift hides at the aggregate level because high-volume corridors average it out. Quality complaints rise on a small set of paths where the cheapest carrier is still being chosen after congestion has degraded its throughput, because nobody had time to re-price the alternative. Agreement renewals get signed against pricing baselines built from stale traffic, so commercial terms are optimized for the network the operator had at analysis time rather than the one it has at signing. When two of those are visible at once, adding analysts flattens the curve without changing its shape — the point at which network optimization stops being a staffing problem and becomes an AI problem.
What ML LABS Built
The engagement delivered a production ML platform with three core capabilities, not a research prototype:
- Time-series models. Trained on global roaming traffic to forecast demand and cost across markets.
- Cost optimization engine. Identified the lowest-cost routing paths that still held the quality thresholds.
- Routing recommendation system. Adapted to shifting traffic patterns and agreement terms as they moved.
graph LR
A["Live Network<br/>Telemetry"] --> B["Streaming<br/>Ingestion"]
B --> C["Time-Series<br/>ML Models"]
C --> D["Cost Optimization<br/>Engine"]
D --> E["Routing<br/>Decisions"]
E --> F["Network Ops<br/>Dashboard"]
style A fill:#1a1a2e,stroke:#e94560,color:#fff
style B fill:#1a1a2e,stroke:#0f3460,color:#fff
style C fill:#1a1a2e,stroke:#ffd700,color:#fff
style D fill:#1a1a2e,stroke:#ffd700,color:#fff
style E fill:#1a1a2e,stroke:#16c79a,color:#fff
style F fill:#1a1a2e,stroke:#0f3460,color:#fffThe parts that made it operational rather than impressive were the unglamorous ones. A streaming pipeline that could absorb terabytes of daily traffic without a backlog. Models retrained on live data rather than on a frozen snapshot. A decision layer that produced recommendations inside the operating horizon they were meant to govern. And a dashboard where network ops could monitor, override, and audit every decision the system made — because an optimizer whose recommendations cannot be overridden is a system nobody will switch on.
Why Time-Series Beats A Solver
A static optimizer would have been the wrong tool, and the reason is a property of the cost function rather than a preference about models. Demand for a corridor follows hourly, weekly, and seasonal cycles, so the cheapest path at one moment is the congested path at another. Time-series models capture the autocorrelation in traffic and pricing dynamics — a property the survey of deep learning for network traffic prediction (ACM Computing Surveys, 2024) treats as the load-bearing assumption for telecom forecasting — so the routing engine plans against the demand curve instead of the demand snapshot.
Take a schematic corridor, illustrative rather than a client record, to see what that buys. The cheapest carrier on paper congests predictably during the morning commuter window, and the month's average tariff washes the peak out entirely. A static solver keeps routing into the congestion, because on its inputs the path still looks favorable. A forecasting model resolves the same corridor differently: it anticipates the peak, shifts a share of traffic to a carrier whose quality holds under load, and comes out lower on blended cost once the retries and the service overhead the cheap path generates are priced into the objective.
The same property governs the optimization layer. A naive shortest-cost solver routes everything into the cheapest carrier until its quality collapses under the load it just created, then oscillates away. The time-series formulation keeps the optimizer aware that its own decisions shape near-future congestion, which is what makes the recommendations stable over an operating horizon rather than oscillating with each twitch in the input distribution.
What The Platform Returned
The cleared outcomes are the ones worth stating plainly. The platform surfaced optimization opportunities across 128% more corridors than the original scope targeted — inefficiencies the manual analysis had never physically reached. Cost per session came down on the targeted corridors. And measured against the cost of the engagement, the optimization returned over 12x in the first year.
"He led a program to build a custom ML platform for a top-10 global client. The work continuously exceeded expectations and became their foundation." — VP of Customer Success, Gigster
The harder gain does not reduce to a number. Once the optimization loop ran continuously, proposed agreement structures could be priced against current traffic instead of against last quarter's snapshot, which changes what a commercial conversation with a partner carrier is made of. The same architecture — streaming ingestion, time-series modeling, an automated decision layer — is a substrate that adjacent problems can be built on rather than a point solution: capacity planning, fraud detection on roaming traffic, and quality-of-service forecasting all consume the same feeds and the same models.
Where Program Scale Bites
The boundary condition here is not technical difficulty. It is that this was never one workflow, and buying it as one is how it fails. Corridor pricing, agreement modeling, telemetry ingestion, and the network-ops decision surface are four workflows sharing an architecture, and their interactions are the whole point — the multi-objective nature of network planning (Xue et al., 2025) is what defeats tools that optimize one axis well. Scope one of them alone and you get a model that is right about cost and wrong about quality, which is worse than the spreadsheet it replaced.
The narrow start is what makes program scale survivable, and it is a sequencing decision rather than a caution. Covering the full agreement portfolio in the first deployment would have made every model error look like a system error and stalled adoption with the team whose sign-off the system needed. Proving the optimization where the cost signal was unambiguous is what bought the credibility to extend into ambiguous traffic, where the gains are smaller per corridor and additive at scale. That extension only stays cheap if the architecture grows by configuration rather than by rebuild, which is a decision made at design time or not at all.
First Steps
- Time one corridor by hand. Price it end to end and measure how long it took. If the demand pattern shifts faster than that, the decision space has already outgrown the review cycle and more analysts will not close the gap.
- Build against the costliest corridor first. Deploy to a market subset, and measure cost per session against the pre-platform baseline before anyone discusses expansion.
- Name the owner of the shared substrate. Ingestion, models, and the decision layer are what the second and third workflows will land on. Decide who owns them before they do.
Extend Reach After Narrow Proof
The pattern that works at this scale is narrow proof followed by deliberate reach: one corridor where the signal is clean, one deployment that survives live traffic, then extension across the portfolio on the same substrate — with the decision layer and the override path built from the first day rather than retrofitted once operations have stopped trusting the numbers. The engineering path from pilot to production is what separates a model that forecasts from a system an operations team runs on.
Several workflows on one architecture, with targets written per workflow before anyone starts, is what an enterprise AI program exists to deliver — and it includes its first 90 days of Operate, run by the person who built it, because a decision system with no owner in production is a decision system the operators route around. If the decision surface is already larger than the team reviewing it, and the corridors nobody has time to price are where the margin is leaking, that is the shape of the problem this solves.
References
- Aouedi, O., Le, V. A., Piamrat, K., & Ji, Y. Deep Learning on Network Traffic Prediction: Recent Advances, Analysis, and Future Directions. ACM Computing Surveys, 2024.
- OECD. International Mobile Roaming Agreements. OECD Digital Economy Papers, 2013.
- GSMA. Roaming. GSMA, 2024.
- McKinsey & Company. How Generative AI Could Revitalize Profitability for Telcos. McKinsey & Company, 2024.
- Xue, Y., et al. TelePlanNet: An AI-Driven Framework for Efficient Telecom Network Planning. arXiv, 2025.
