Another 5G Promise.

The vendor proposals for the autonomous network are on the table, and the managed-service contract is up for renewal with autonomy written into it. The CEO looks at the strategy slide that says Level 4 by 2028, the level where the system runs its loops alone inside the range it is approved for, and asks the CTO: show me the money, or is this another 5G?

The question has company. In November 2025 the managing director of Airtel, one of the world’s largest mobile operators, told analysts that 5G had not lived up to its promise, with no monetization anywhere in the world.

This essay is the long form of Issue 14 of Level 4 Autonomy Insights. It answers the CEO’s question in four parts: why a level is being asked for money at all, where the money is spent and where it is earned, the four places it appears, and the one rule that keeps the case honest.

Automation had no levels, so a script was paid for by the hours it removed, and that was the whole case. I have never seen a strategy slide that said “Automation Level 4 by 2010”.

Digital transformation had a maturity model, and I have read no operator strategy that set a maturity level as its goal. Everyone chased transformation and everyone bought it, and the line of those years was that transformation is something a company becomes, with no purchase order attached.

The one place a level was the goal was software process maturity. In 1994 the US Air Force adopted a policy that bidders on its software contracts should hold Level 3 on the maturity model for how software is built. Companies reached Level 3 to be allowed in the room, and nobody asked what the level earned, because the level was the ticket.

Autonomous networks are new on that list. Level 4 is written into multiyear strategy plans across the industry, the term has become a buzzword, and for the first time a level has to answer the money question on its own.

In Level 4 Means Nothing I separated the level from the value: a level measures what the system can do, and value measures what happened after it was deployed. This essay is about where the value sits once they are apart.

An autonomy investment lands in two places, both before anything runs.

The first is the foundation: the data the loops read, the platform they run on, the integration into the systems they act through, and the testing environment that proves a loop closes before it touches the live network. Every closed loop stands on it, and it is bought once for all of them.

The second is the features: the closed loops themselves, and the intent features on top of them. A closed loop detects a problem, decides, acts and checks the result, and at the higher levels it does so without a person in the middle. An intent feature lets you hand it a goal and work out the settings itself, the move in The Last Number You Own.

The vendor proposal prices both, and neither earns anything until the loops run. Run time is where the case is paid or missed: how many faults the loop closes alone, how many minutes it takes off an outage, how often a person steps in, and what the loop costs to run, in computing, licences and re-testing after every change.

The CEO’s question is answered on that second side only. The sections below take the four places the run-time money appears, in the order they mature in most operations.

Almost every case lives here, and it is the easiest to count. Here is one loop, simplified on purpose so the shape is easy to follow, with every figure illustrative.

At ten past two in the morning, a cell on a busy site stops accepting new connections. It raises no alarm, and the network map still shows it as working. This is a sleeping cell, and only the traffic counters show it.

The loop restores cells that stop serving: 5,000 a month that need action, most raised by an alarm and some, like this one, found only in the counters. Five operators share the shifts so that someone is at the desk 24 hours a day, and today they work with tools, which is Level 1.

Each fault takes 7 minutes of desk work on average, about 583 hours a month. After breaks, handovers and training the desk has about 584 working hours a month, so today it runs full.

I call each fault that is fixed and stays fixed a closure. The ticket system shows 4,800 of them a month, after the 4 percent that came back. Divide what the five operators cost in a month by those 4,800 closures, and call the result 100 cost units.

At Level 3 the system reads the counters, flags the cell after one reporting period, at 2:25, and proposes a restart, and a person approves it. The cell is back at 2:50, ten minutes sooner than today, and desk work falls from 7 minutes to 5.

Two minutes saved on 5,000 faults is about 167 hours a month, about 2,000 hours a year. The desk still needs five people to stay staffed through the night, so the people still cost 100 units, and the machine adds 8 for computing, platform fees and re-testing. With the closures held at 4,800, a closure now costs 108 units, 8 percent more, and the team has 2,000 hours it did not have.

At Level 4 the system finds the cell, restarts it, confirms the traffic is back and closes the fault, for every fault it is approved to handle alone. The 8 percent outside that range, 400 a month, go to one operator on the day shift and to the desk that already covers the network overnight, which gains one person.

Two of the five operators stay on that work. The other three move to jobs in operations that the plan was about to fill. Counted on this loop alone, the two people’s share at 40 units, computing at 12 and re-testing at 8 make a closure 60 units, 40 percent cheaper than today.

The company still pays the three operators, now from the budgets of the teams they joined, so its spending on people is unchanged. The 60 is this loop’s share of the bill, and it is labelled an allocation.

Money appears only when someone decides to stop a payment and puts a date on it. The decisions that count come from a short list.

• A managed-service or outsourced contract reduced on its notice date.
• Contractor or overtime hours no longer bought.
• A planned role not needed, named against the funded workforce plan and dated from its planned start, recorded by the operator.
• Service credits, contractual penalties and regulatory fines no longer paid.
• Energy, where the loop switches equipment off.

Hours are reported as hours, with the team they go to named, and cash carries a name and a date. The hours a decision banks can never exceed the hours the loops freed that year, and an hour banked by one decision is unavailable to every other.

This is the category the excitement about autonomous agents will test first. When an agent hampers the customer’s experience, operations tend to pull it back behind fixed rules. SAP said in May 2026 that its customers had asked for hard rules and approval gates on its agents, and that the general release of its agent studio had slipped a year.

Autonomy for the customer works where ten years of experience programs built the foundation: the journeys, the care data, the measurement of what a customer felt. One reason it lags is that the industry’s map of autonomy scenarios, the catalogue operators plan against, covered the network and the service layers first, and the customer layer is still being drawn.

Satisfaction, in the part of it a fault loop can show, is read on the service, one interruption at a time. The fault loop shortens the interruption, and the interruption is measured where the customer felt it, in minutes of the service not working, counted once however many loops helped.

Those minutes become money only through a conversion the operator’s Finance team names: care contacts per interruption minute and the cost of a contact, or the credit schedule in a business contract with its thresholds and caps. A faster fix with no named conversion is reported beside the case and stays out of the payback.

Monetization is the far category. The early cases are chains of loops across the network, commercial and care teams, and I present two at the TM Forum autonomous networks workshop in London this week.

In congestion to cash, a loop sees a cell filling up, frees capacity, and the commercial system offers the right customers an upgrade before anyone feels the slowdown. In silent fault to prioritised repair, a degradation that raised no alarm is found, traced across radio, transport and core, and the repairs are ordered by the revenue at risk.

Revenue enters the case through two doors. Usage-billed revenue, the traffic and the upgrades customers pay for by use, counts with its margin; subscription revenue is billed through an outage, so an outage minute on a subscription has no revenue to convert.

Adaptive products, which reshape themselves to how each customer uses them, are the step after that. They need these chains underneath them, because a product that adapts is a loop that runs from the customer’s use back into the network and the catalogue.

This category matures last. The industry’s value framework counts it beside the other three, and the example is a product you could not have operated by hand: a slice of the network sold by the hour, a guarantee priced per customer, a service switched on for the length of one event.

It is reported beside the case, and rarely banked, because the revenue it brings is counted under revenue once the product sells. What innovation adds is the option, and an option is written down as a line, with the loops it depends on named.

The trap runs through all four. Loops observe the systems that run them from several angles. The cell outage loop, the congestion loop and the customer-care loop all watch the same cells and the same customers, and they share one desk.

An outage minute shortened by two loops is one minute. A foundation serving five loops is paid once.

The rule has three parts. Each interruption on the service is counted once, and its reduction is split across the loops that contributed to it by shares that add up to one. The hours freed on a team are counted once per loop, and split across the investments that moved them by the minutes each one moved. The foundation is carried once, in the portfolio, and every investment that stands on it is labelled “assumes the foundation”.

Counting once changes decisions in both directions. A loop that looks good alone can add little once the loops beside it already claim its outage minutes, and a loop that looks uneconomic alone can pay once the foundation under it is shared with four others.

That gives the test for every benefit line in the case: name the service outcome it changes, and name the other loops that already claim it. A line that cannot name its outcome is a feature description, and it stays out of the money.

Under that test the model is short. Measure what each loop does: the faults as they arrived, the closures from the ticket export, the minutes of work per fault, the minutes on the clock, the machine spending. Decide the investment once per platform or program, as a schedule of cash by year, with costs in the years they are paid and savings from the dates of the decisions that release them. Read the value on the service over months, and pay for the foundation once.

A proof of concept proves the loop closes. A pilot proves the cost per closure, the exception rate, the minutes of work and the clock, read as a curve with checkpoints, against sites that kept the old loop where that comparison is possible. The pilot’s measurement replaces the expected figures in the case, and a case whose expected figures still carry more than half of its value says so in plain words.

Three cases per investment, conservative, base and aggressive, vary the demand trend, the platform and token prices, the share of work left with people, the exception rate and the adoption ramp on one investment scope. A lower target level is a separate case, because it changes both the investment and the benefit.

5G was bought, and its promise was in the purchase. Autonomy’s promise is kept at run time, in the outage minutes a loop takes off and the payments someone stops, each counted once.