Summary

  • LACNIC’s new guest essay usefully separates the ability to execute from the authority to decide, but an autonomy level becomes misleading when it is detached from the scenario, network part and closed-loop dimension that were actually evaluated.
  • A durable claim needs a scenario ledger: a dated record of the workflow, five human-or-system roles, minimum derived level, evidence, outcome baseline, exceptions and reevaluation trigger. That is more useful than an operator-wide badge.

The seductive thing about a maturity ladder is that it turns a complicated operating system into one character. L0 says manual. L5 says full autonomy. Everything between them appears to describe a steady climb. Put the result on a slide, attach it to a procurement answer or repeat it at an industry conference, and a large collection of decisions begins to resemble a single property of the company.

That resemblance is the problem.

On 9 September 2026, LACNIC published an essay by Hernán Arcidiacono on autonomous networks and a new operating model. The page identifies him as chief technology officer of Iplan Argentina and a member of the IANA Review Committee, and it also states that the opinions are his own rather than necessarily LACNIC’s. His opening distinction is clean: automation concerns the capacity to execute, while autonomy concerns the capacity to decide. A conventional automated system follows fixed rules. An autonomous one has some awareness of its state, its objectives or intents, and its environment.

The essay makes two further moves that matter. First, it says the TM Forum framework reaches beyond the resource layer into service and business layers. “Autonomous network” is therefore narrower than the operating transformation under discussion; the company is changing how it decides, delivers and supervises work. Second, it recommends starting with one autonomous domain and one operating process. An access network or IP domain might be paired with fault management. The human can gradually leave some steps of an awareness-analysis-decision-execution loop and move toward supervising the process.

That is a practical way to begin. It is also the reason an unqualified company-level score is unsafe. If the implementation starts with one domain and one process, the evidence naturally belongs to that domain and process. It does not automatically travel to billing, service activation, backbone changes, security response, energy optimisation or customer remediation. A successful loop is an observation about a bounded object. It is not a passport for the whole operator.

The level belongs to an evaluation object

The standards material behind the discussion is more careful than the shorthand often used around it. The public description of TM Forum’s IG1252 says its methodology can assess a network or part of a network. It works through operational processes, sub-processes, tasks and task criteria. That phrasing puts the scope before the score.

ITU-T Y.3173 makes the boundary explicit. Its evaluation looks at workflows over the network lifecycle and at network subsystems. It says the intelligence level of a whole network reflects the levels of the individual workflows and subsystems. A whole network reaches a level only when the relevant components and workflows reach or exceed it. Because those objects vary by use case, the result can vary by use case too.

This is not a semantic nicety. Consider two hypothetical assessments.

In the first, a fault-management loop collects alarms automatically, correlates them automatically and recommends a recovery plan. A human decides whether to execute it, and the system then performs the approved change. In the second, a service-fulfilment loop maps a product order into a machine-readable intent, plans the configuration and deploys it without a human decision, but a technician still gathers part of the inventory evidence by hand. Both systems mix human and machine work. A single label cannot tell a buyer, engineer or regulator which dependency remains human, which action is automatic or which failure mode is being accepted.

Y.3173 addresses that ambiguity with five dimensions:

  1. demand mapping, which turns an operational requirement into instructions the network can execute;
  2. data collection, which obtains the information required for analysis;
  3. analysis, which interprets the current state and may predict a future one;
  4. decision, which selects a configuration or service action; and
  5. action implementation, which carries out the decision.

Each dimension is classified according to whether it is performed by a human, by a human and system together, or by the system. The overall level for a use case is then derived from the minimum applicable per-dimension level. The least autonomous relevant step constrains the result. The method does not award the whole loop the status of its most impressive demonstration.

That minimum rule is institutionally important. It resists showcase accounting. A provider cannot take an excellent classifier, an automated remediation script or an agent that writes plausible plans and silently promote that component’s capability to the status of the entire operating process. The weak join remains visible.

The same Recommendation adds a restraint that is easily lost in sales language: human decisions and execution instructions retain the highest authority at every level. A numerical level therefore does not settle who is legally accountable, who can interrupt the process or whose instruction prevails. It describes a distribution of operational capability under a defined use case. Governance still has to be designed.

Capability is not outcome

A second category error appears when a high autonomy level is treated as proof of a good result. ITU-T Y.3063, approved in December 2025, treats effectiveness as a separate measurement problem. It builds a four-layer framework: business-value objectives; end-to-end business-scenario outcomes; domain-specific network-capability metrics; and the system data from which those metrics are calculated.

The distinction is elementary and often neglected. A system can automate more tasks without improving service availability. It can reduce handling time while increasing the cost of rare exceptions. It can raise the ratio of automated actions while making it harder to diagnose an incorrect one. It can lower energy use in a radio-access scenario while shifting risk to coverage or customer experience. Capability says who or what performs a step. Effectiveness asks what changed because it did.

Y.3063 groups business objectives under customer experience, operational efficiency and resource efficiency. Its examples include service delivery and activation time, service availability, interruption time, mean time to recovery, deployment time, the operation automation ratio, energy measures and resource-fulfilment measures. Crucially, it says not every indicator applies to every scenario. The benchmark and the scope have to be declared before improvement can be judged.

Appendix II starts with an inventory of end-to-end business scenarios across relevant operating domains. Metrics are derived for each scenario; scenarios are ranked by their contribution to outcomes; pilots precede scale. This is almost the inverse of a company badge. The operator does not begin by choosing a flattering number for itself. It begins by listing the work, deciding what value should change and preserving the evidence that connects a particular capability to a particular result.

The difference matters to smaller providers as much as to large carriers. Arcidiacono argues that medium and small ISPs should not assume autonomous networking is reserved for the largest operators. A scenario ledger makes that advice more attainable. A smaller ISP does not need to imitate a multinational transformation programme or claim a sweeping maturity level. It can identify one costly, repetitive or failure-prone process; record its present division of labour; automate a bounded part; measure the result; and stop or reverse the change if the evidence disappoints.

That is not a diminished version of autonomy. It is a more legible one.

What the ledger should record

A credible autonomy claim should be inspectable after the conference slide has disappeared. The minimum record is not difficult to describe, although producing it consistently requires discipline.

First comes identity and scope: the operator, accountable owner, evaluated domain or network part, named use case, workflow, trigger and evaluation period. “Fault management” is still broad; the record should distinguish, for example, cell-outage compensation from an optical-backhaul fault or a configuration-drift alarm.

Second comes the five-dimensional vector. For demand mapping, data collection, analysis, decision and execution, the record should say whether a human, a system or both performed the step. It should identify the evidence: an intent version, data-set reference, model or rule version, decision record, change identifier and postcondition. The headline level must be the minimum level derived under the declared method, accompanied by the vector that produced it.

Third comes outcome. The record should name the baseline, the scenario-specific effectiveness indicators, the observation window and the result. A shorter mean time to recovery is not interchangeable with a higher automation ratio. A reduction in manual tickets may be useful while customer complaints rise. Keeping the measures separate prevents a capability improvement from being laundered into an unsupported business claim.

Fourth comes control. The ledger should identify the human-intervention authority, the action’s blast-radius constraint, the exception path, the rollback owner and the evidence used to verify the postcondition. If an automatic cell-compensation plan worsens interference, the important fact is not merely that the system can roll back. It is that the trigger, decision, change, observed deterioration and rollback are joined in one retrievable episode.

Finally comes expiry. An evaluation is not timeless. A model update, new intent, changed topology, different data source, altered vendor component, expanded action permission or redesigned workflow can invalidate the old result. The ledger needs a reevaluation trigger and an expiry rule. Otherwise a level earned by one version survives long after the system it described has ceased to exist.

Several loops, several authorities

The ETSI ZSM material shows why scope becomes harder as autonomy grows. Its reference architecture distinguishes management within a domain from end-to-end management across domains. Several closed loops can run at different granularities, overlap in the services they use and communicate horizontally or through a hierarchy.

The January 2026 study on agents adds another layer. It distinguishes human-led copilots, supervised autonomous agents and fully autonomous agents, while also classifying agents by function and action type. An agent might diagnose faults, another might optimise quality and another might apply configuration. A registry may group them by capability, scenario or a role such as human decision. In a cross-domain fault case, an agent detects a local problem, discovers other capabilities, escalates to an end-to-end coordinator, forms an investigation team, assigns tasks and receives post-resolution feedback.

None of that fits safely inside “our network is L4” unless the statement is accompanied by its object. Which agent? Which loop? Which domain? Which decision right? Which action? Which observed result? A cross-domain system can be sophisticated while one decisive handoff remains manual, unavailable or weakly evidenced. Conversely, a modest single-domain process can be highly reliable without justifying an operator-wide claim.

This is why the ledger is not merely compliance paperwork. It is the map of where autonomy actually lives.

A level is a claim with an expiry date

There are five recurring ways to overstate network autonomy. The best-performing task is promoted to the status of its loop. The loop is promoted to its domain. The domain is promoted to the whole operator. A capability score is presented as an outcome. Then the dated assessment is repeated after the implementation changes.

Each move removes a boundary. Each makes the claim easier to market and harder to test.

LACNIC’s guest essay is valuable precisely because it begins from a bounded object and a gradual operating change. The region does not need to turn that discipline into another maturity slogan. It needs a record that lets a small ISP, a major carrier, a vendor and a customer state the same claim in comparable terms without pretending their entire organisations are equivalent.

An autonomy level can be useful. It just has to stay attached to the work that earned it.

Sources