Thousands of alarms turned into a handful of probable incidents, each with its likely root cause, diagnostics already gathered and a draft incident record. Engineers decide the fix, and no network change happens without change control.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
When a fibre is cut or a router card fails, everything that depends on it raises an alarm: transport links, mobile sites, broadband aggregation, voice. The NOC sees a storm of thousands of alarms from dozens of systems, each with its own format and severity. Engineers suppress what they can, sort the rest by hand, and try to find the one alarm that explains all the others. On a bad night, that takes longer than the fix.
Meanwhile the clock is running on everything else. Customers and the contact centre want to know what's happening. Major incidents may need reporting to Ofcom, and broadband and landline outages can trigger automatic compensation. As landlines move to digital voice, an access outage can also cut off phone calls and telecare alarms for people who rely on them. Incident records written at 3am are often thin, and post-incident reviews have to rebuild the timeline from logs.
The tools that could help are also a risk. Anything that can reach network management systems is a privileged access path into the most sensitive part of the network. The Telecommunications (Security) Act 2021 and its Code of Practice treat the management plane and automation that can affect the network as security critical. So the design has to make diagnosis faster without giving an AI the ability to change the network.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
From the first alarm to an engineer confirming the root cause.
ExampleDown by half on the pilot domain
How many raw alarms the NOC handles per real incident. Too aggressive grouping hides separate faults.
ExampleDown sharply, with missed separate faults tracked
Share of incidents where the top suggestion matched the engineer's confirmed cause.
ExampleAbove 70%, reviewed weekly
Records with timeline, impact, cause and actions filled in by the time the incident closes.
ExampleAbove 95%
Reportable incidents notified within Ofcom's expected timescales, with figures that didn't need correcting later.
ExampleEvery reportable incident
Network changes made during incidents without an approved or retrospectively logged emergency change.
ExampleZero
Cross-sector rules are on the UK regulation map.
Providers must identify and reduce the risks of security compromise, protect the functions that oversee and manage the network, control privileged access, monitor and log activity, and be able to keep running the UK network without relying on people, equipment or data outside the UK. A triage agent that can query network management systems is a new privileged access path. It gets its own read-only identity, goes through a brokered, logged route, and the platform runs in UK regions.
Tier 1 providers (relevant turnover of £1 billion or more) and Tier 2 (£50 million to £1 billion) are measured against it. The first measures applied from March 2024 and March 2025; a further group, including management plane, signalling, supplier contracts and monitoring, is due by 31 March 2027, and new version 1.1 measures follow in 2028 and 2029. Its guidance on automation asks for validated inputs, reviewed changes, checked outputs, a rollback plan and a named owner for every automated process. The design follows that: the agent reads, a person changes.
Providers must tell Ofcom about security compromises with a significant effect, including outages from hardware failure or human error, as soon as reasonably practicable. Ofcom's guidance sets thresholds, for example 100,000 customers affected for any duration, and expects the most serious incidents to be notified quickly, followed by a fuller report, with smaller ones in a monthly bulk report. The agent tracks the figures against the thresholds and drafts the report. The incident manager decides whether to report and submits it.
Providers must take all necessary measures to keep services available during major failures and to keep access to emergency services uninterrupted. Any incident touching 999 and 112 call routing goes to the top of the queue and straight to a person. The model can never rank it lower.
Customers in vulnerable circumstances need extra care during outages. Under the automatic compensation scheme, a residential broadband or landline customer gets £10.34 a day once a total loss of service isn't fixed after two full working days (rates from 1 April 2026), and since 8 April 2026 complaints can go to dispute resolution after six weeks. Accurate start and end times and affected-customer lists in the incident record matter. Customer messages are drafted for a person to approve, and telecare users get a call, not just a text.
As landlines move to digital voice, a broadband or power outage can now cut off phone calls and telecare alarms. The impact assessment includes voice and telecare on affected lines, and uses the priority customer register the charter expects providers to keep.
Alarm and performance data is mostly not personal, but affected-customer lists, customer messages and engineers' actions are. Use customer data for restoring service and keeping people informed, keep outage updates as service messages, not marketing, and do a DPIA before the pilot.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Network and OSS
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Alarm intakeTake alarms from fault management, not from every element. Normalise them once, with a stable ID, so replays don't duplicate. | Amazon MSK, fed by your fault management system's northbound interface | Event Hubs (Kafka endpoint), fed the same way | Apache Kafka |
| Real-time groupingGroup by topology and time window. Keep the rules visible to engineers, and let them split a group the model got wrong. | Amazon Managed Service for Apache Flink | Fabric Real-Time Intelligence (Eventstream, Eventhouse) | Apache Flink on Kubernetes |
| Network topologyA copy of what your inventory system says is connected to what. Inventory stays the master; stale topology is the commonest cause of wrong grouping. | Amazon Neptune | Azure Cosmos DB for Apache Gremlin | PostgreSQL with Apache AGE |
| Root-cause modelTrained on past incidents with confirmed causes. Cause coding in old tickets is often poor, so budget time to clean it. | Amazon SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Runbooks and past incidents (retrieval)Approved runbooks, vendor documentation you're licensed to use and closed incident reviews, so drafts cite their source. | Bedrock Knowledge Bases | Foundry IQ, built on Azure AI Search | OpenSearch, or PostgreSQL with pgvector |
| Reasoning and draftingBoth clouds offer a choice of models, including Claude. The language model drafts and explains; the grouping and ranking come from the ML model. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Diagnostic toolsEach tool is a fixed, read-only query (show commands, counters, recent changes) through your management systems' APIs, never a free-form command line on a device. | AgentCore Gateway in front of read-only APIs | API Management in front of read-only APIs | Kong or your existing API gateway in front of read-only APIs |
| Workflow and events | AWS Step Functions, EventBridge, SQS | Logic Apps or Durable Functions, Event Grid, Service Bus | Temporal; Apache Kafka or RabbitMQ |
| Link to service managementIncidents and draft updates land in your service management tool. Change requests can only be created by a person. | API Gateway, plus your existing integration platform | API Management, plus your existing integration platform | Kong or your existing API gateway, plus your existing integration platform |
| Human reviewEngineers see the group, the suggested cause and the evidence where they already work. | In the NOC's existing incident console and service management tool | In the NOC's existing incident console and service management tool | In the NOC's existing incident console and service management tool |
| Cloud operations agentsThese investigate cloud workloads, not radio, transport or core networks. Amazon DevOps Guru closed to new customers on 29 October 2026. | AWS DevOps Agent, for the platform itself | Azure SRE Agent, for the platform itself | Your existing monitoring |
| Identity, keys, privileged accessThe agent has its own read-only identity, separate from engineers'. Engineers make changes only from privileged access workstations, as the Code of Practice expects. | IAM Identity Center, KMS, Secrets Manager | Entra ID, Key Vault, Privileged Identity Management | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every tool call, every suggestion and every human decision, and feed the logs to your security monitoring. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyNetwork data is security sensitive. Keep it in the UK and make sure the NOC can run without the platform. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
Network elements, element managers, fault management, inventory and every route into the management plane stay in the operator's own network, untouched. So does the change process and anything that can alter configuration.
Uses cloud AI
Alarm grouping, the root-cause model, the runbook index and the triage agent can run in a UK cloud region, or on the operator's own servers with open-weight models. They receive alarms, topology and read-only diagnostic results, never credentials that can change the network.
How they connect
Fault management publishes alarms outbound over AWS Direct Connect or Azure ExpressRoute. Diagnostic queries come back in through one brokered, read-only gateway inside the operator's network, which decides what may be asked and logs every call.
If the link drops
The NOC works exactly as it did before the AI, from fault management and its own runbooks. Alarms queue and are grouped when the link returns, and incident records are completed by hand. Nothing in the network depends on the cloud.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Incident triage agent
Where a person signs offA NOC engineer confirms the cause and decides the fix, and any network change goes through change control, including emergency changes. The incident manager approves customer messages and decides on Ofcom reporting. The agent's permissions are enforced by the platform's identity and policy controls and by the read-only gateway, not by instructions in a prompt.
Alarms come from fault management through its northbound interface onto one event stream. Each alarm keeps its original ID and timestamps, so replays and duplicates are harmless and the grouping can be rebuilt after the event for the post-incident review.
The agent reaches the network only through a read-only diagnostics gateway inside the operator's network. Each tool is a named, fixed query with a fixed scope. The gateway checks the identity, enforces rate limits so diagnostics can't add load during an outage, and logs every call. There is no tool for changes, and no route from the gateway to the write side of any management system.
Service management stays the system of record for incidents, problems and changes. If it's slow or down, drafts wait in a queue. The AI can be switched off without touching the network: the NOC carries on from fault management, as it did before.
Map today's alarm flow and incident process, measure time to cause, check alarm and topology data quality, and agree the read-only boundary with security.
Gate · must be true to passPilot domain chosen, baseline measured, diagnostics gateway design approved by security, DPIA started.
One domain (for example transport or mobile radio), in shadow mode: groups and suggestions go to a small team of engineers and are compared with what actually happened.
Gate · must be true to passRoot-cause hit rate and grouping errors within agreed limits, no write path found in testing, and the NOC manager signs off.
Grouping and drafts go live in the NOC for the pilot domain, with monitoring, support and a rollback plan.
Gate · must be true to passSupport model in place, engineers and incident managers trained, security monitoring receiving the agent's logs.
Add domains one at a time, then cross-domain grouping, then problem management.
Gate · must be true to passEach new domain passes the same pilot gate; each new diagnostic tool passes its own security review.
| Activity | NOC director | Network engineering lead | Incident manager | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | SecurityI can fill this | Regulatory affairs |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Consulted | Informed | Informed | Informed |
| Target architecture and read-only boundary | Informed | Consulted | Informed | Accountable and Responsible | Consulted | Consulted | Consulted | Informed |
| Security review against the Code of Practice | Informed | Consulted | Informed | Consulted | Informed | Consulted | Accountable and Responsible | Consulted |
| Alarm, topology and diagnostics access | Informed | Accountable | Informed | Consulted | Consulted | Responsible | Consulted | Informed |
| Build and integration with service management | Informed | Consulted | Consulted | Accountable | Responsible | Responsible | Consulted | Informed |
| Ofcom reporting and customer comms templates | Informed | Informed | Responsible | Consulted | Informed | Informed | Consulted | Accountable |
| Model testing against past incidents | Informed | Accountable | Consulted | Consulted | Consulted | Responsible | Informed | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Consulted | Responsible | Informed | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Consulted | Responsible | Consulted | Informed |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the alarm pipeline, the read-only diagnostics boundary, the integration with your service management tool and the gates, working closely with your network engineers and security team. I'd report to your programme board.
Option B
If your partner or your own team already has an architect, I'd take on the event pipeline, the agent and its tool gateway, and the service management integration under their lead, and give them a second senior opinion on privileged access and on whether the root-cause suggestions are good enough to trust at 3am.
Goes wrong
The agent is given an engineer's credentials 'just for the pilot', and can change the network.
How the design avoids it
Its own read-only identity, a gateway with fixed queries, and a security test that tries to write before go-live.
Goes wrong
Stale topology groups unrelated faults together, and a second outage is hidden inside the first.
How the design avoids it
Topology refreshed from inventory, engineers able to split groups, and missed separate faults measured.
Goes wrong
Diagnostics pile load onto struggling equipment in the middle of an outage.
How the design avoids it
Rate limits and timeouts at the gateway, and cached results shared between engineers and the agent.
Goes wrong
An emergency-call routing fault is ranked as minor because few alarms fired.
How the design avoids it
A hard rule: anything touching 999 and 112 routing goes to the top and to a person, whatever the model says.
Goes wrong
Customer updates go out with the wrong scope or times, and compensation and complaints follow.
How the design avoids it
Drafts only, approved by the incident manager, with impact taken from service data, not the model's guess.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Build threshold checks as configuration, not code, so they can change when Ofcom publishes its final statement.
Include voice and telecare in every access outage's impact assessment, linked to the priority customer register.
Map the triage platform, its gateway and its suppliers against the measures now, and add them to the security programme.
If any part of the NOC or its tooling is run by a managed service provider, check its new duties and align its incident reporting with yours.
Record the cryptography used on the alarm feed, the gateway and the private links, and choose components where it can be updated.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
