AI-assisted network operations for a UK telecommunications operator

Context and constraints

Network operations centres at national telecommunications operators sit at the sharp end of a problem that has been building for years: the network estate keeps growing in complexity, but the tooling used to watch it has grown by accretion rather than by design. The operator we worked with had a fixed-line core, a mobile radio access network, a metro and access broadband layer, and a fast-growing set of edge compute and IoT connectivity services, each introduced at a different point in the company's history, each monitored by whichever tooling was fashionable or contractually available at the time. By the point we began the engagement, nine distinct monitoring platforms were feeding alarms into the NOC, and no single person in the organisation could describe with confidence how alarms from one system related to alarms from another.

The scale of the noise was the immediate, visible problem. On an average day the estate produced over forty thousand raw alarm events. A single fibre cut on a core transport link could generate hundreds of downstream alarms as every dependent service and element reported the resulting condition, each arriving as an apparently independent event with no system-level indication that they shared a common cause. Engineers had developed genuine skill at recognising these cascades by eye, a fibre cut had a signature, a power event had a signature, a routing flap had a signature, but that skill lived in individual heads, took years to build, and evaporated whenever an experienced engineer left the team. The operator's attrition data showed exactly this pattern: incident handling quality dipped measurably in the weeks following the departure of any senior NOC engineer, and recovered only once a replacement had absorbed enough tribal knowledge to recognise the same patterns.

The 2026 industry backdrop mattered to how the client framed the brief. AI copilots for alarm correlation had become a visible trend across telecoms operations through the year, with vendors and peer operators describing meaningful gains in detection speed and operator workload. The Head of Network Operations wanted those gains, but had also watched, in the same period, a steady stream of industry commentary about agentic AI systems taking consequential actions without adequate oversight. The brief was explicit from the first conversation: build something that gives engineers AI-generated insight and recommendation, and refuse, as a matter of system design rather than policy statement, to let any model execute a change against the live network without a human confirming it first.

The approach in depth

We began discovery not by cataloguing the monitoring tools in isolation but by shadowing NOC shifts and reconstructing, incident by incident, how an engineer actually moved from an alarm flood to a diagnosis. That exercise was more valuable than the tooling inventory itself, because it surfaced the informal triage logic the team already used and had never written down: which alarm types were reliably symptomatic of a specific upstream fault class, which combinations of signals meant a genuine customer-impacting outage rather than a self-healing transient, and which escalation paths engineers trusted for which fault types. That tacit knowledge became the seed training signal for the correlation model, validated and extended with several years of historical incident tickets that let us test candidate correlation rules against outcomes the NOC had already confirmed.

The normalisation layer had to solve a genuinely hard integration problem before any AI component could add value. Each of the nine source systems used its own alarm schema, its own severity scale, and its own partial view of network topology. We built a canonical topology model spanning core, access, radio, and edge domains, and an ingestion pipeline that mapped every source alarm onto that model in near real time. Only once alarms had a shared topological context could the correlation engine group them meaningfully, recognising, for example, that forty alarms from four different monitoring tools all traced back to the same access node and were symptoms of one underlying condition rather than forty separate problems.

The triage layer built on top of that correlated view combined a rules-based severity and impact model, tuned against the operator's actual customer-impact history, with a machine-learned ranking component that improved its prioritisation as engineers confirmed or corrected its suggestions over time. Deliberately, we kept the model's role advisory throughout: it proposed a probable root cause, cited the evidence supporting that hypothesis, suggested a next diagnostic step, and where a remediation was well-understood and low-risk, proposed the specific action an engineer could take. It did not, at any point in the design, have a path to execute that action itself.

Human-in-the-loop by design, not by policy

The operator's leadership was clear that a policy telling engineers "always review before acting" was not the same thing as a system that structurally required review, and we agreed. Every suggested action in the triage interface, whether a diagnostic command against a network element or a proposed configuration remediation, was rendered as a proposal with a single explicit approval control, and the underlying execution pathway had no credential or interface that allowed the AI layer to invoke it directly. The system could draft the change, show the engineer exactly what it would do and why, and queue it for execution, but the actual command only reached the network once a named engineer had approved it, and that approval was logged against their identity in the same audit trail used for every other operational change.

We tiered this control by consequence rather than applying a single blanket rule. Read-only diagnostic queries, pulling additional telemetry or historical context to support a hypothesis, could run automatically, since they carried no risk to live service. Anything that touched configuration state, however minor, sat behind the approval gate without exception. For higher-risk classes of change, a rollback of a recent configuration push, or an action on an element supporting critical national infrastructure services, we added a second-engineer confirmation requirement on top of the standard gate, reflecting the operator's own change-management policy for those services rather than inventing a separate standard.

This design had a secondary benefit the operator valued as much as the safety case: it gave engineers confidence to trust the system's suggestions precisely because they retained control. Several senior engineers told us during the rollout that they would have resisted a system that acted autonomously, however good its suggestions, simply because it removed their professional judgement from the loop. A system that did the correlation and analysis heavy lifting but left the decision with them was one they were willing to rely on and, over time, to actively prefer over their previous manual process.

Integration with ticketing and ITSM

An AI triage layer that lives in a separate interface from the tools engineers use daily tends to be ignored under pressure, however good its output. We integrated the correlation and triage engine directly into the operator's existing ITSM platform, so that a correlated incident, its ranked severity, the supporting evidence, and any pending or completed approvals appeared as native fields and comments on the incident ticket rather than in a parallel system engineers had to context-switch into. Ticket creation itself was automated for correlated incidents above a configurable impact threshold, with the ticket pre-populated with the topology context, the affected services, and the suggested next steps, removing a manual data-entry step that had previously consumed several minutes at the start of every incident.

We paid particular attention to the shift handover problem, which the NOC had identified during discovery as a chronic source of dropped context. Historically, handover relied on a verbal briefing and informal notes, and incidents that spanned a shift boundary frequently lost detail in the transition, occasionally leading to duplicated diagnostic work or, worse, an approved remediation being repeated because the incoming engineer did not know it had already been tried. The integration generated a structured handover record automatically from the incident timeline, correlated alarms, diagnostic steps taken, and approvals granted, giving the incoming shift a complete, searchable history rather than a verbal summary. This became one of the most valued outputs of the entire programme independent of the AI correlation itself, and the operator has retained it as a standing process even in scenarios where the AI layer's confidence is low and a ticket is handled manually end to end.

We also built explicit escalation logic into the ITSM integration so that incidents the model flagged as low-confidence or out of pattern, meaning conditions the correlation engine had not seen a reliable signature for, were routed to senior engineers with that uncertainty stated plainly, rather than being force-ranked alongside high-confidence incidents. Making the model's uncertainty visible, rather than hiding it behind a single confidence score, was a deliberate choice that the NOC leadership specifically asked for after reviewing an early prototype that had understated how often the model was genuinely unsure.

Rollout and change management

We ran the triage layer in shadow mode for the first six weeks of live operation, generating correlation and priority suggestions alongside the existing manual process without engineers relying on its output for any live decision. This gave us a clean measurement of the model's accuracy against real incidents before asking anyone to trust it operationally, and it gave the NOC leadership concrete evidence to bring to the wider engineering organisation, some of whom were understandably sceptical of AI-generated recommendations in a live network environment. Shadow-mode accuracy on root-cause hypothesis matched engineer-confirmed root cause in the substantial majority of correlated incidents, and where it did not match, the reasons were almost always traceable to a genuinely novel fault pattern the model had not yet encountered rather than a systemic flaw in the approach.

We then moved to a phased live rollout, starting with the day shift on the highest-volume service domain and expanding to the full NOC roster over a further ten weeks. Each phase included structured feedback sessions where engineers could flag suggestions they disagreed with, and those disagreements were reviewed and, where they represented a genuine gap in the model's training signal, fed back into the correlation logic. This feedback loop was as important to the eventual accuracy of the system as the initial training data, since it captured edge cases and judgement calls that historical tickets alone did not fully represent.

Training was structured around the same human-in-the-loop principle as the system design. Rather than a one-off classroom session, we ran the AI layer's suggestions as a co-pilot exercise during live shifts for several weeks, with engineers actively querying why the model had proposed a given root cause and challenging suggestions they found unconvincing. That habit of interrogating the model's reasoning rather than accepting its output passively became a cultural norm the NOC leadership was keen to preserve well beyond the rollout period, and it was written into the standing operating procedure for the triage tool rather than treated as a one-time training exercise.

Measurable outcomes and what they meant operationally

The reduction in raw alarm volume presented to engineers was the most immediately visible change, cutting the noise engineers had to wade through by more than seventy per cent through correlation and deduplication alone, before any triage ranking was applied. Critically, this was achieved without suppressing any alarm class outright; every alarm was still ingested and assessed by the correlation engine, and the reduction came from grouping genuinely related events into a single incident context rather than discarding information. NOC leadership was firm on this point during design, having seen naive alarm-suppression approaches elsewhere quietly hide genuine faults that happened to correlate with noisy conditions.

Mean-time-to-detect for service-affecting incidents fell from an average of twenty-six minutes to under seven, driven almost entirely by the correlation engine surfacing the genuinely actionable incident inside the noise far faster than manual triage could. Mean-time-to-resolution for priority-one and priority-two incidents improved by approximately forty-four per cent over the first two full quarters of live running, a combination of faster detection, faster root-cause hypothesis, and engineers spending less time manually gathering supporting evidence before deciding on a next step. False-positive escalations to second-line and field engineering teams, historically a source of friction between the NOC and specialist teams who were frequently called out for conditions that turned out to be self-healing transients, fell by over half.

The engineer satisfaction improvement was, in the Head of Network Operations' own assessment, the result that mattered most for the long-term sustainability of the change. Alarm fatigue had been a genuine retention risk for the NOC before the programme, and the internal shift survey conducted after the full rollout showed a marked improvement in engineers' reported sense of control over their workload, with reduced alert fatigue and clearer incident context cited most frequently as the reasons. That result reinforced the design choice to keep engineers as decision-makers rather than positioning the AI layer as a replacement for their judgement.

Lessons learned

The most important lesson from this engagement was that the human-in-the-loop requirement, which could have been treated as a constraint that limited the value of the AI layer, was in practice what made adoption possible at all. Engineers who might have resisted or worked around a fully autonomous system engaged readily with one that respected their professional judgement and gave them better information to exercise it. Building the approval gate as a structural property of the system, with no execution path that bypassed it, rather than as a configurable policy setting, also gave the operator's own risk and assurance functions a much easier case to sign off, since the control could be demonstrated in the architecture rather than asserted in a document.

The shadow-mode period, though it delayed measurable operational benefit by six weeks, was worth the delay many times over. It converted a sceptical engineering culture into an evidence-led one, and it gave us a clean baseline to demonstrate improvement against rather than relying on anecdote. Teams tempted to skip this step under delivery pressure should weigh that trade-off carefully; the credibility earned during shadow running compounded through every subsequent phase of the rollout.

Finally, the handover record turned out to be a durable process improvement independent of the AI layer's ongoing accuracy. Even in the hypothetical case where the correlation model's performance degraded over time as the network estate evolved, the operator would retain a structured, auditable shift handover process that did not exist before the programme. Building components of an AI-enabled programme that deliver standalone value, rather than making every benefit contingent on the model continuing to perform, is a discipline we now apply as a matter of course on similar engagements.

If you are looking at AI-assisted operations for a complex network or infrastructure estate and want a partner who will build automation with genuine human control rather than automation for its own sake, we would be glad to discuss what a programme like this might look like for your organisation. Email sales@halfteck.com.