Why LLM-based Agents Matter for Network Operations and AIOps
A research note on our new arXiv survey on Agentic NetOps and AIOps.
I have recently posted a new survey on arXiv: Large Language Models for Agentic NetOps and AIOps: Architectures, Evaluation, and Safety
Paper: https://arxiv.org/abs/2605.12729
This work studies how large language model based agents are beginning to enter Network Operations (NetOps) and AIOps. The setting is important because operational incidents in modern networks are rarely straightforward. An incident can involve logs, alerts, tickets, dashboards, configuration changes, policy rules, service constraints, and human judgement.
This scenario serves as a relevant test case for current discussions about AI agents. NetOps are procedural, evidence-heavy, time-sensitive, and full of constraints. Some operational actions are safe to suggest but can be unsafe to execute in a given time. This is because suggestions are driven from available evidences, some evidences are fresh and authoritative, but some are stale, incomplete, or simply misleading.
That makes the problem more interesting than asking whether a model can explain an alert. The fundamental question now become whether an agent can operate within the discipline of network operations, which raises several other questions.
Can it gather appropriate evidence and make proposal based on correctly selected evidence?
Can it distinguish a mere correlation from a useful root-cause hypothesis?
Can it use tools safely and appropriately?
Can it operate within the assigned safe permissions?
Can it verify relevant policies before proposing or executing actions?
Can it ask for human approval at the right point?
Can it support rollback when a change does not behave as expected?
These questions motivated the survey.
Caption: A practical LLM-in-ops stack. A useful agent is a model placed inside a wider system of evidence collection, typed tools, verification gates, approval controls, and operational action.
The central argument is that reliability in agentic NetOps and AIOps will depend on the surrounding system: evidence traces, tool boundaries, verification gates, rollback mechanisms, governance, and human oversight.
This is why the next stage of research should move beyond treating LLMs as question-answering assistants for NetOps and AIOps. The more important direction is to study them as constrained operational agents within evidence-to-action workflows.
A chatbot can explain an alert. An operational agent must decide what evidence to collect, which tools to call, what assumptions it is making, what risks are involved, which policies apply, and when to involve a human operator for approval of the next step.
In NetOps, these differentiative roles of agents are significant, because it defines the difference between useful assistance and unsafe automation.
A useful way to frame this is through an autonomy ladder.
Caption: The autonomy ladder shows how agentic NetOps and AIOps systems move from read-only assistance towards write-capable and closed-loop operation. As autonomy rises, the safeguards must become firmer.
At the lower levels, an agent may summarise alerts, retrieve runbook sections, search logs, or help explain a dashboard. This is useful work, and the risk is usually limited because the system is observing rather than acting.
At the next level, the agent begins to recommend diagnostic queries, propose likely causes, and suggest manual procedures. This is more delicate because it can affect the operator’s judgement. The risk is no longer merely theoretical.
At higher levels, the agent may draft configuration changes, generate diffs, run validation tools, or propose staged mitigation. At the highest level, it may take part in a closed operational loop, where actions are repeatedly proposed, checked, and revised. Here the risk becomes serious.
This is where the engineering problem changes. A good answer from the model is no longer enough. Any step from reasoning to action must pass through proper controls.
In this survey, we therefore treat tool boundaries and constraints as part of the main architecture. Read-only tools and write-capable tools should be kept separate. An agent may be allowed to inspect metrics, logs, traces, tickets, and topology. It should not follow from this that the same agent may alter routing policy, change firewall rules, restart services, or push a configuration without further checks. A well-designed system should separate these capabilities. It should also keep an evidence trace. That trace should show which tool calls were made, what evidence was returned, which assumptions were used, and why a proposed action was accepted or rejected.
In operational settings, this helps with debugging. More importantly, it gives the system a memory of responsibility. Without that, automation soon becomes a very confident filing clerk with the keys to the server room.
This also has implications for evaluation.
Caption: Evaluation should become more realistic as autonomy increases. Offline corpora are useful, but write-capable agents need sandbox replay, controlled rollout, canary tests, trace logging, and rollback-aware scoring.
Many current evaluations still focus on static question answering. That is useful, but it is not enough for this domain. An operational agent should be evaluated as part of a workflow. For example, suppose there is a latency incident after a routine deployment. A useful agent should not jump straight to a confident answer. It should retrieve recent changes, check ownership, query metrics and traces, compare the hypotheses, propose a limited mitigation, and send any write-side action through policy checks and rollout controls.
In these kind of setting, the answer is only one part of the output, but:
The trace matters.
The tool calls matter.
The stopped actions matter.
The rollback plan matters.
The agent’s uncertainty matters.
An evaluation that ignores these details may reward the wrong behaviour. A model that gives a confident but poorly grounded explanation can look impressive in a text-only setting. In an operational setting, that confidence may be exactly the danger. The survey therefore argues for workflow-level evaluation: incident timelines, tool-use traces, policy checks, sandbox replay, canary rollouts, and rollback-aware scoring.
There is also a security side to this problem.
Once agents are connected to tools, the documents they read become part of the control surface. A ticket is no longer just a ticket. A runbook is no longer just a runbook. A dashboard note, telemetry string, or chat transcript all of them can influence the agent’s reasoning and may indirectly shape an operational action, and systems future states.
Caption: The threat model makes the trust boundaries explicit. Untrusted operational artefacts can inject instructions or distort evidence, while privileged action must remain behind independent gates.
This is why agentic NetOps and AIOps need a security model from the beginning. The obvious controls are still the right ones: least privilege, tool allow-lists, independent verification, provenance-aware retrieval, policy gates, audit trails, canary deployment, and rollback. The difference lies in their role. Once a model is positioned near the operational control plane, these mechanisms are no longer peripheral safeguards. They become part of the core architecture. Thus, the agent must not be able to bypass the verification wall. It should not be able to convert an untrusted instruction into a privileged action. It should not silently rely on stale runbooks, ambiguous tickets, or manipulated telemetry. It should have a bounded tool budget, a stopping rule, and a clear escalation path.
This is also where human approval remains important. The point of agentic operations is not to remove the operator from every decision. In many cases, the useful goal is to reduce the evidence-gathering burden, improve the quality of the proposed action, and make the approval decision better informed. In other words, the agent should make the human decision easier and safer, not merely faster. This is the direction we tried to set out in the survey.
LLM-based agents for NetOps and AIOps should be judged not only by what they can say, but by how they behave within operational constraints. The model matters, of course. But in real infrastructure, the surrounding system matters more: tools, traces, permissions, verification, rollback, governance, and audit.
Acknowledgement
This survey paper is developed Muhammad Bilal (Lancaster University) Jon Crowcroft (University of Cambridge), Ruizhi Wang (NUIST), Xiaolong Xu (NUIST), and Schahram Dustdar (TU Wien). I am grateful to Hamed Haddadi (Imperial College) for his valuable comments on the manuscript.
I would welcome comments from colleagues working on computer networks, distributed systems, SRE, AIOps, cybersecurity, and network automation.