The Autonomous Carrier
Powering the lights-out NOC — transitioning from network janitors to architects.
Most operational improvement programmes in telecom are attempts to run the same model more efficiently. Better dashboards. Tighter runbooks. A monitoring platform that consolidates two of the six you already have. They produce real but bounded gains, and then the curve flattens — because the constraint was never the tooling.
This paper argues the constraint is the operating model itself, and that it is now a financial problem rather than an operational one.
Why is this a CFO problem and not a NOC problem?
Because of where the two curves are going. The cost of keeping an existing network running compounds — more devices, more vendors, more generations of technology in service simultaneously, each one adding maintenance obligation that never depreciates to zero. Service revenue does not compound at the same rate. Connectivity is a commodity and revenue per bit has been falling for two decades.
When the cost line rises faster than the revenue line, the gap has to be closed somewhere. Historically it has been closed by deferring modernisation — which lowers cost this year and raises it every year after, because the deferred infrastructure ages into requiring more maintenance, not less. That is not a cycle you improve your way out of. It is one you have to break structurally.
Didn’t automation already solve this?
Automation solved the parts of it that could be written down in advance.
Scripts and static playbooks handle known conditions with known responses. They are genuinely valuable and most operators have invested heavily in them. But they share a structural ceiling: someone has to anticipate the case, write the rule, and maintain it every time the network changes. The rule handles what it was written for and nothing else. In a network spanning four to six technology generations across a dozen vendors, the space of situations nobody anticipated is larger than the space of situations somebody did — and it grows every time you add equipment.
So the human stays in the loop, not as a decision-maker but as the fallback for everything unanticipated. That is the bottleneck, and it is why operational cost stays coupled to network size no matter how much scripting you do.
What does “agentic” actually change?
An agent is not a bigger script. It holds a defined operational mandate, works from the documented procedures your organisation already has, and acts inside that mandate without waiting for a rule that anticipated the exact case. When it reaches the edge of what it is authorised or confident enough to do, it hands off to a human with the context already assembled.
The practical consequence is that work stops being serialised through people. Correlation, customer notification, Tier 1 support response, and the supervisor’s operational picture all happen concurrently rather than in a queue behind whoever is on shift. The agent model is here; the platform it runs on is here.
What this does not mean is unsupervised machinery making consequential changes to your network. Grounding matters more than autonomy: every decision anchors to retrieved documentation with a confidence score, you set the thresholds, and decisions carrying billing or paging consequences stay with a person.
What changes for the customer?
In the legacy model the customer is a sensor. They are frequently the first to tell you the network is down, and their experience of an outage is defined by how long they spend explaining it to someone who does not yet know it is happening.
When a fault is correlated into a service event the moment it occurs, the affected customers are known before any of them calls. Notification goes out from that event rather than from a person remembering to send it. The support contact that does arrive is answered from documented procedure in seconds rather than queued. The experience shifts from friction to absence of friction, which is the only version of network operations a subscriber ever notices favourably.
What changes for the operations executive?
The morning stops beginning with reconstruction. Instead of a red dashboard and a bridge call assembling what happened overnight, the operational picture already exists: what is open, what changed, what needs a human decision, and what has been handled.
The more consequential shift is where attention goes. An operations organisation that spends most of its capacity on Tier 1 and Tier 2 work has no capacity for the fibre overbuild, the consolidation, or the densification programme — and those are the things that determine whether a regional operator thrives or gets acquired. Reclaiming that capacity is the actual return, and it is worth more than the headcount line.
What changes for the CFO?
The relationship between network growth and operational cost. Under the manual model they are coupled: doubling the footprint means something close to doubling the operations organisation, which is why growth is expensive in a way that does not appear in the capital plan.
Decoupling them changes what the operator can credibly promise. It is the difference between a company describing itself as a utility with a depreciating asset base and one describing itself as a platform that scales. That is a valuation story as much as a cost story.
Where does this get oversold?
Worth stating plainly, because most material on this subject does not.
The labour savings do not arrive on the software’s timeline. Reassigning an operations organisation is a multi-year change involving roles, skills, and people’s careers — any model showing headcount reduction landing in the same quarter as the deployment is a model to distrust, including one from a vendor. Autonomy has a blast radius, and an agent that can execute a change can execute a bad one, which is a legitimate reason to phase adoption rather than a reason to avoid it. And the whole approach depends on your topology and documentation being accurate enough to reason against; if they are not, that is a prerequisite project rather than a footnote.
What should leadership actually do?
Three things, none of which require choosing a vendor first.
Measure where the time goes. Instrument how many operator-hours per week are spent on correlation, triage, and status communication. Most operators are surprised by the answer, and the number is the business case. Challenge each manual step. For every recurring task ask what specifically requires a human — judgment, authority, or habit. The third category is larger than it looks. Fix topology first. Automation amplifies data quality in both directions, and inventory accuracy is the prerequisite for everything else.
Get the white paper
The full paper works through the economics in detail, the operating-model transition, and what the shift looks like from each stakeholder’s seat — written for CTO, COO, CFO, and VP of Operations rather than for the NOC floor.
About Rapax
Rapax is an AI-native network service assurance and automation platform for telecom operators, bringing fault, performance, topology, and service management into one system worked by six AI agents. It deploys on Kubernetes in cloud or on-premise environments, including local model inference. Rapax is a business unit of Citus Technologies, LLC.
Shawn Ennis is the Founder & CEO of Citus Technologies and the founder of Rapax. He spent 25 years in telecom operations, holds 12 patents in network management and service assurance, and previously founded Assure1 — acquired by Oracle in 2021.
Not ready to download? Book fifteen minutes — no prep, no deck. cal.com/shawn-ennis · sales@rapax.app · More white papers