The network AI maturity model for enterprise and MSP networks

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.

The claim worth testing. Anyone selling L4 autonomy for production network change owes you a rollback story. Ask for it. If the answer is hand waving, the product is not at L4, it is a demo. rConfig would rather tell you plainly which rung we stand on than sell you a rung we have not built.

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.

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.

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.