The network AI maturity model for enterprise and MSP networks

01 · The premise

The real question is not whether the AI is clever

For thirty years, network change has been a human discipline. An engineer reads a config, reasons about it, makes a change, and lives with the consequences. AI now promises to take some of that on. The question every network team is right to ask is not whether the AI is clever, but how much it is allowed to do, and whether you can see what it is doing before it does it.

That single question, how much autonomy and how much visibility, is the one this paper answers. It is also the question the wider field has already built a vocabulary for. Rather than invent our own, we adopt the one network teams already use, and we are honest about exactly where we sit on it.

02 · Why we anchor to a recognised scale

We adopt the TM Forum autonomous network levels, not a scale of our own

The autonomous networking field already has a canonical way to talk about this. The TM Forum defines a scale from fully manual operation through to fully autonomous, self managing networks, modelled directly on the levels of autonomous driving. It runs from L0 to L5, and it is the language you will hear at every industry event, AutoCon included. Inventing a parallel rConfig scale would only collide with terms our buyers already know cold, so we adopt the TM Forum scale as the backdrop and position rConfig against it.

Adopting a shared scale forces an honest answer to a simple question: what level are you actually operating at? Most network operators sit at L2 or below today, with only a small fraction running meaningful autonomy. The gap between what is sold and what is safely in production is wide.

Written for carriers, grounded for you

The TM Forum scale was written for large carrier networks: RAN, OSS, service orchestration. rConfig translates it into the world our customers actually live in, enterprise and MSP network configuration management. For us, autonomous does not mean self healing radio. It means governed configuration operations across the managed estate, with the engineer always able to see what the AI knows and what it would do before it does it.

03 · The model

Four stages, mapped to the scale your field already uses

rConfig translates the TM Forum autonomy scale into the world network configuration teams actually live in. The standard was written for large carrier networks. We ground it in enterprise and MSP estates, where autonomous does not mean self healing radio, it means governed configuration operations across the devices you manage, with the engineer always in view.

04 · The stages, in plain terms

What each rung actually means for your team

05 · Why staged, why now

The first wrong answer is the one that matters

Network engineers are, rightly, the most conservative buyers in software. You manage infrastructure where a bad change at 2am is an outage, an audit finding, or worse. An AI that is confidently wrong once will never be trusted again, and it should not be. If you want the longer argument for why caution is the right default here, our writing on whether AI is safe for network change makes the case in full.

That is precisely why a staged model is not a limitation but a discipline. Each stage is fully useful on its own. Each one earns the right to the next. And at every stage you can see what the AI knows before you rely on what it says. The curated domain knowledge is viewable. The reasoning is grounded. The boundary between reading and writing is explicit and, until you choose otherwise, closed.

An assistant that reads and explains, grounded in real network knowledge, is worth more than an autonomous agent you cannot trust.

There is a second discipline beneath the first. rConfig does not host AI models or send your configurations to a platform you do not control. You bring your own model, including a local LLM running entirely inside your own environment. For air-gapped and security-conscious teams, the AI works without your data ever leaving the building. The intelligence comes to your network, not the other way around.

06 · Stage 1, available now

What an honest Level 1 looks like

This is not a roadmap promise. It is what the AI does today, read-only and grounded. These read-only capabilities are part of rConfig's AI config analysis.

• Explain any configuration in plain language, wherever you are working, in the config viewer, the diff view, the compliance screens.
• Understand differences between configurations and explain what changed and why it matters.
• Detect and narrate drift from a golden baseline, in words, not just red and green lines.
• Reason about compliance against benchmarks like CIS and NIST, and help you author the policy definitions themselves.
• Guide optimisation of your rConfig instance through a doc grounded assistant that knows the product.
• Run on your terms, your model, your keys, or your own local LLM, with nothing hosted by us.

And for teams that build their own automation, the same intelligence is available the other way around. rConfig exposes itself to external AI tools and agents through an MCP server and a downloadable rConfig Skill, so your copilots and agents can understand and work with rConfig directly.

07 · The invitation

Start at the bottom. Climb when you are ready.

You do not have to believe in autonomous networks to get value from network AI today. You have to start somewhere safe, prove it, and climb deliberately. That is the whole idea. rConfig is at Stage 1 now, building toward the next, and we will tell you exactly where we are on the ladder at every step, because the engineers we build for would accept nothing less. You can follow that climb on our rConfig AI roadmap.