Autonomous Network Operations: How Agents Earn the Right to Act

What Is Autonomous Network Operations?

Autonomous network operations means AI agents and automated workflows handling a problem from alert to verified fix. It takes the alert, gathers context, works out the likely cause, chooses a fix, runs it, checks that it worked, and records what happened. A person is involved only where a decision needs one.

Here is an example. An interface on a core router starts flapping, and monitoring raises an alert. In a traditional operation, an engineer picks up the ticket, logs in, checks counters and logs, decides what to do, makes the change, and confirms the link is stable. In an autonomous operation, an AI agent does the investigation. It pulls the counters, logs, and recent changes, and finds the likely cause. It then chooses a fix from the actions it is allowed to use. A workflow runs that fix, checks the interface again, and updates the ticket. The engineer sees a closed ticket with the evidence attached.

The agent and the workflow do different jobs. The agent reasons: it reads the situation and chooses. The workflow acts: it runs the same tested steps every time, including pre-checks, the change itself, and post-checks. Reasoning chooses, and workflows act. That split keeps the changes predictable.

This approach is known as Agentic NetOps. AI agents work alongside governed automation, meaning automation with access controls, approvals, and an audit trail. In Itential’s definition, an agent is not a chatbot or a single-purpose script. It takes an operational goal, plans the steps, runs them under governance, checks the result, and keeps going until the goal is met.

Autonomous operations build on tools you already have. Monitoring and AIOps find and rank problems. Network automation runs a fixed procedure when someone starts it. Autonomous operations connect the two. They take the signal from monitoring, decide what to do about it, and run the automation, without waiting for a person to start each step.

Autonomy is also not all or nothing. Each action a network can take has its own setting. Some actions only observe. Some recommend. Some run after a person approves. Some run on their own, within a written policy. One network uses all four at once. The Autonomy Paradox in Network Operations describes these four permission states:

The action is the unit. Reading interface counters and rerouting production traffic carry very different risk, so they sit at different settings even when the same agent can do both. An action moves up a setting when its results justify it. This is why a label for the whole network, such as “Level 3”, says little. It does not tell you which tasks run on their own.

How Do Autonomous Network Operations Work?

Every incident moves through the same loop: detect, diagnose, decide, act, verify, and record. Three layers do the work. AI reasoning decides what to do. Deterministic execution does it. Deterministic means the same input always gives the same result. Infrastructure systems supply live data and carry the change to devices.

Reasoning Layer

Agents interpret the goal, weigh the evidence, make a plan, and trigger actions. They never act on devices directly. This layer handles diagnosis, correlation, and cases that no script anticipated. It chooses only from capabilities it has been authorized to use.

Deterministic Execution Layer

This layer runs what the agent chose. It checks inputs against a schema, enforces role-based access control and policy, and runs approval workflows where an action needs one. It runs pre-checks, makes the change, runs post-checks, handles failure, and keeps an audit record. AI reasoning can extend a workflow but cannot bypass it.

Infrastructure Instrumentation Layer

This layer includes telemetry, controllers, automation tools, ITSM, and the adapters that connect to devices and systems. Itential Gateway, including its FlowMCP Gateway, extends it to MCP servers. Monitoring and AIOps supply the alert signal. Inventory and source-of-truth data supply the facts. Existing scripts and workflows become tools that an agent can call. Nothing needs to be replaced.

Lumen’s reference architecture shows how the pieces fit. Each product has a defined role. Selector is the brain, Itential is the hands, and ServiceNow is the front door. The loop closes in four steps. Selector detects the problem. Itential fixes it. The ServiceNow ticket is updated. Confirmation flows back to Selector.

Operators can watch agents work. Agent Sessions show a time-ordered view of an agent’s reasoning and tool calls. They link to the workflows the agent started. An operator can step in during a session. The same controls apply whether a person, a schedule, an event, or an agent starts the work.

What Benefits Can Autonomous Network Operations Deliver?

The main benefit is capacity. The team can turn more alerts into fixes that are justified, completed, and verified, and specialists no longer assemble each step by hand. The bottleneck was never seeing the problem. It is getting from an alert to a verified fix.

Cisco and Omdia put numbers on the gap. The average organization handles about 4,100 alerts and events a day. Clearing the network share of those by hand takes about 100 specialists. 45% of investigation time goes to false positives. Incident resolution takes 12.5 hours at the median but 88 hours on average. The gap between the two means a few incidents run very long.

These published results show what the groundwork delivers:

None of these is an autonomy result. Each is a result of governed automation, which autonomy builds on. Keeping that distinction keeps the evidence honest.

Look at how the results were produced, not only the headline number. Lumen cut the alerts first. It then built 350+ live workflows to act on the alerts that remained. It also tracks two numbers separately: OpEx saved, and value created. The result is a cognitive NOC, where machines handle routine work and engineers focus on innovation.

Where Do Autonomous Network Operations Stand Today?

Autonomous network operations are in production today, but only in narrow use cases. Gartner projects that by 2030, AI agents will be the most common way to execute network runtime activities. In early 2026 they were under 1%. Gartner’s May 2026 Market Guide lists five use cases already proven in telecom, financial services, and utilities: incident triage, pre-flight change validation, fault remediation, firewall policy automation, and compliance evidence collection. Itential validated these use cases through its FlowAI Innovation Program with six enterprise customers.

Surveys show what leaders intend, not what their networks have proven. Cisco and Omdia found that 82% of leaders are comfortable letting some production changes run without prior approval. They also found that 84% expect an AI-led operating model within 12 months. Treat the 84% as intent. It does not say which actions are safe, what evidence supports them, or how reliably they perform.

Telco data shows the same gap. Capgemini reports that 84% of telcos are still at Level 1 or 2. One level per network hides the real picture. A single network can run one autonomous task next to many tasks that still need approval.

Lumen, a carrier with a mixed-vendor network, shows what it looks like to count tasks instead of networks. Lumen has 350+ live workflows. It has identified 1,000+ automation opportunities, and about 700 are on the path to autonomous execution. Its goal is 80% machine-to-machine operations. Lumen also built a proof of concept in which several agents use 90+ tools through the Model Context Protocol (MCP), a standard that lets agents call external tools. That proof of concept stays out of production for now. Lumen wants stronger guardrails first, so that the agents behave predictably and pass QA.

Lumen also shows how one task earns the right to run alone. For one remediation, an engineer approved every run. That happened more than 100 times. The runs showed zero defects. Lumen then turned the task on without the approval. The pattern has four steps: start small, keep a person in the loop, build the task from composable parts, then remove the approval.

Organizational roadmaps describe the same path in five phases, from personal discovery to autonomous operations, and warn against skipping ahead.

What Prevents Autonomous Network Operations From Reaching Production?

Teams stall when they pick an AI model before they build a dependable path from alert to verified fix. Each barrier below has a practical answer.

• Noisy Alerts
  An agent cannot decide well when most of its input is duplicate alerts and false positives. Cut the noise first. Lumen treats the cut from 1B+ raw alerts to 57K actionable incidents as a prerequisite for closed-loop operations, where the system detects the problem, fixes it, and verifies the fix without a person.
• Unclear Data
  An agent needs data that means one thing. Lumen says API quality and source-of-truth data must improve first. No execution platform can make up for a remediation procedure that was never tested.
• A Fragile Starting Point
  Most teams start with one-off scripts, uneven adoption, and slow change-approval steps outside the operations team’s control. Lumen describes this starting point. Begin with one workflow and build from there.
• Incidents Cross Domains
  Cisco and Omdia found that 92% of respondents say performance issues commonly span several domains. These teams use nearly ten separate tools for visibility. Use orchestration that works across all of them.
• Approvals No One Can Evaluate
  “Human in the loop” can mean a person approving a recommendation they cannot see into. Show the reviewer the evidence, the proposed action, and the expected result. Approval fatigue makes the problem worse, because reviewers start approving everything without reading.
• Weak Failure Handling
  A successful API response does not prove the service recovered. Give each action post-change checks, clear stop conditions, escalation steps, and rollback where rollback applies.
• Coordination
  Several agents can act on the same environment and collide. Lumen is formalizing agent-to-agent governance. Itential sits underneath as the single set of governed hands that carries out their actions.
• People & Program Risk
  Operators lose skills when they stop doing the work, so rotation programs act as insurance. One high-profile incident can also roll back a whole program.
• Cost
  Token pricing that looks fine in a pilot can become expensive once agents succeed and usage grows. Model the cost at real usage. Keep known, high-volume tasks on fixed workflows that run the same way every time.

How Should Teams Start Building Autonomous Network Operations?

Start with one recurring incident that has a recognizable signal and a known response. An interface alarm that your team always fixes the same way is a good candidate. Then work through five steps. Give the agent read-only access to the context it needs. Have it gather evidence and recommend a specific action. Connect that recommendation to an existing workflow that includes human approval, pre-checks, execution, and post-checks. Measure the whole loop. Finally, decide whether the action can run without prior approval under a narrower policy.

Write Down What Each Action Needs

Before an agent recommends or runs a production action, write down seven things about that action. Together they form its production contract:

1. Scope: Which systems, environments, devices, and operations may the agent touch?
2. Evidence: Which current signals and state must support the decision?
3. Authority: Does a policy approve the action in advance, or must a person approve it each time?
4. Execution: Which prerequisites, steps, and constraints must always run?
5. Verification: Which post-change checks show the intended outcome?
6. Failure: When does the action stop, escalate, or roll back?
7. Record: Which trigger, evidence, decision, approval, action, and result must be kept on file?

A written contract lets a reviewer see what they are approving. It also gives the team a consistent test for deciding whether the action can later run without approval.

Measure the Complete Operational Loop

Measure the whole loop, not just the recommendation. Track time from alert to diagnosis, time to resolution, effort spent on false positives, approval delays, failed changes, recovery events, and whether the record of the action is complete. If these numbers improve and stay good, the action has earned more permission.

Widen Permission for One Defined Case

Remove approval only for the specific action and conditions that the results support. Define those conditions by device family, environment, time window, signal quality, failure history, and recovery path. Lumen’s playbook has two steps. First, prove the action is reliable in one context, such as one device family, region, and time window. Second, remove human approval for that context. Audit and rollback stay in place.

The permission belongs to that action in that context. It does not carry over to another device class, a wider change window, or a different failure condition. For example, an action proven on one router model during a maintenance window has no standing on a different model at midday.

Build From Small, Tested Parts

Lumen credits four building blocks:

• Small Actions
  Such as ping, trace, and interface checks, combined into reusable runbooks. Each runbook has pre-checks, post-checks, error handling, and rollback validation.
• Orchestrations
  Built on the assumption that no human will be present.
• Review Gates
  Design-document review (PDD to SDD), peer governance, naming checks, adapter validation, and AAA-scoped permissions.
• CI/CD Discipline
  In 2023, Lumen’s maintenance windows took three hours of manual work. It now deploys with zero downtime.

Adopt Build Agents Before Operate Agents

The Build Agents vs. Operate Agents guide recommends a sequence. A build agent turns an approved specification into a workflow, script, or test. It does not touch production, and the result goes through your existing review and change process. An operate agent reasons about live conditions while it runs, so it needs governance at runtime. Operate agents start with read-only work: triage, diagnostics, and documentation. They move to bounded changes only when scoped tools, policies, approvals, validation, recovery, and audit are in place. Keep the common path deterministic and use reasoning for exceptions. A task that runs 10,000 times a day should follow a fixed workflow.

Chris Wade covered the distinction between build and operate agents, and how organizations should move towards autonomous network operations in his keynote at AutoCon 5. You can watch the full video of his session below: