What Level 3 autonomy actually demands of your organisation
The hard part of an autonomous network is not the models. It is agreeing, in advance and in writing, what the system is allowed to do without asking, and building the organisation that can live with that answer.
Most discussions about autonomous networks are really discussions about model capability. That is the tractable part. The part that decides whether the programme succeeds is organisational, and it surfaces the first time a system remediates something on its own at three in the morning.
Open loop is a rehearsal
Open-loop automation, where the system recommends and a human acts, is where every serious programme should start, and it is genuinely useful. But it is not a smaller version of closed loop. It is a rehearsal for a different thing.
In open loop, the human is the safety mechanism, and their judgement quietly absorbs every gap in the model's understanding. Those gaps are invisible precisely because someone is covering them. Closing the loop removes that cover, and everything the human was silently compensating for arrives at once.
The transition is therefore not a switch. It is a period of running closed loop in shadow, comparing what the system would have done against what the operator did, and treating every divergence as a finding rather than a defect.
Network operations, as five jobs
- Detect
- Diagnose
- Decide
- Act
- Verify
Open loop puts a human here. Closing it takes them out
The questions to answer before you close the loop
- Which classes of fault may be remediated without a human, and who owns that list?
- What is the blast radius of a wrong action, and what bounds it? Not in principle, but in code.
- How does the system decide it is out of its depth and stop, and how fast does a human arrive?
- Who is accountable when an autonomous action makes an incident worse? Answer this before it happens, not after.
- What evidence does the system leave behind, and would it satisfy an auditor who does not trust it?
These are not model questions. Not one of them is answered by a better architecture, and every one of them will block deployment if it is still open.
- AI and ML use cases taken from concept to delivery
- MultipleAI and ML use cases taken from concept to delivery
- Autonomy target for network performance
- Level 3Autonomy target for network performance
- Disciplines working to one definition of done
- 3Disciplines working to one definition of done
Why multi-agent, and why it is not a shortcut
A multi-agent model helps because network operations genuinely is several jobs: detect, diagnose, decide, act, verify. Separating them means each can be evaluated, bounded, and improved on its own terms, and a failure in diagnosis does not silently become a failure in action.
It also multiplies the surface you have to reason about. Agents that individually behave well can compose into behaviour nobody specified. The discipline that makes this tractable is boring and non-negotiable: explicit contracts between agents, hard bounds on what each may do, and verification as a first-class step rather than an afterthought.
Level 3 is not a model milestone. It is the point at which your organisation has written down what it is willing to let a machine do alone.
Teams that treat autonomy as a governance programme with a modelling component ship it. Teams that treat it as a modelling programme with a governance appendix build impressive demonstrations that never leave the lab.
Enterprise Technology Executive
Anurag Kumar Mishra
I lead large-scale transformation across telecom and enterprise technology, connecting technology strategy, operating models and capital allocation to measurable business outcomes.
LinkedIn