Platforms

Capabilities

Company

Resources

Platforms

Capabilities

Company

Resources

Networks

Networks

—

Agentic AI in NetOps: What to Automate and What to Keep Under Human Control

Netcon Logo
Hamburger
Networks

Agentic AI in NetOps: What to Automate and What to Keep Under Human Control

By

Mahadevan V

—

8

min read

Network teams are being asked to keep more services running across more locations. They also need to manage cloud applications, connected devices and new AI workloads. Yet many teams still spend hours sorting alerts and repeating routine fixes.

That workload has renewed interest in agentic AI in network operations. The idea is simple: software investigates a network issue, selects a response and carries it out within rules set by the organisation.

The decision needs more care than a software demonstration can show. A tool that restarts one access point is different from a tool that changes routing across several sites. Both may be described as autonomous. Their risks are not the same.

Cisco and Omdia surveyed 1,000 IT and network operations leaders in September 2026. Their research found that 51% of respondents already ran agentic AI that acts in production NetOps. The same research found that 84% expected an AI-led operating model within 12 months. Cisco also reported that 95% felt their existing AIOps tools could not keep up with operational needs. Read the Cisco and Omdia findings.

These are survey findings, not a measure of every enterprise network. They do show that network leaders are evaluating greater automation. The useful question is where to begin, and what safeguards must come first.

What agentic AI in NetOps actually does

Traditional network monitoring tells a team that something has happened. A monitoring system may report packet loss, an overloaded link or an access point failure. AIOps tools can correlate events, spot patterns and recommend a response.

Scripts and runbooks take the next step, but they follow instructions written in advance. A script might restart a service after a specific alert. It does not usually decide whether that action is suitable for a new situation.

Agentic AI adds a decision layer. It can gather evidence from several tools, assess the likely cause, choose from approved actions and check the result. A person defines the permitted actions and the conditions for using them.

That does not mean an agent should receive unrestricted access to the network. Its role should be limited to specific tasks, devices, sites and change types. The organisation should also be able to review every action.

Three levels of control

A useful way to assess agentic NetOps is to separate it into three operating levels.

Level

What happens

Suitable starting point

Main control

Recommend

Software investigates and suggests a fix. An engineer decides whether to apply it.

Fault diagnosis and evidence gathering.

Engineers review the recommendation.

Act with approval

Software prepares the change and waits for an authorised person.

Repeat incidents with a known response.

Approval is required before execution.

Act within limits

Software applies a pre-approved action and reports the outcome.

Low-risk tasks proven through earlier stages.

Scope, rollback and monitoring are defined in advance.

 

Most organisations should spend time in the first two levels. They need evidence that the recommendations are accurate. They also need to understand how the software behaves during unusual conditions.

Autonomy should be granted to individual tasks, not to the network as a whole. A team may approve automated port recovery while retaining human approval for routing or firewall changes.

The network must be ready before software can act

An agent can only make a sound decision when it has reliable information. It needs an accurate device inventory, current network diagrams and access to useful telemetry. It must also understand the relationships between users, applications, devices and sites.

A fragmented network makes this difficult. Engineers may have to log into separate devices to check configurations. Important dependencies may exist only in spreadsheets or in the experience of individual team members. Several monitoring tools may show different parts of the same incident.

A central management layer helps bring these views together. Software-defined networking can also make policies more consistent and changes easier to test. It gives operations teams a clearer view of network state and approved control points.

Arche's Networks practice covers network modernisation, campus and branch connectivity, network observability, infrastructure automation and AI-ready networks. The existing Arche articles on software-defined network architecture and legacy campus migration provide useful background before an automation programme begins.

The airport network programme at Bangalore International Airport offers a practical example of the groundwork. Arche's case study describes a phased move to software-defined networking across more than 50 systems. The resulting environment supports more than 50,000 IP endpoints across over 50 airport subsystems. The case study shows the value of central control, segmentation and planned migration. It should not be read as a claim that the airport runs autonomous agentic NetOps.

Which network tasks should you automate first?

Start with tasks that are frequent, predictable and easy to reverse. A good first use case has a clear success condition. It should also have limited impact if the action fails.

Examples include:

·       Collecting logs, device status and configuration details before an engineer investigates an incident.

·       Grouping duplicate alerts that point to one underlying fault.

·       Checking whether a configuration backup completed successfully.

·       Restarting a known service or access port after a specific fault, where the device and service owner approve it.

·       Moving a branch to a backup connection when defined health checks fail and the failback process is tested.

·       Opening or updating a ticket with the evidence collected during diagnosis.

These jobs reduce repetitive work without handing over broad control. They also create a record of how well the software performs.

Some work should remain human-led until the organisation has strong evidence. This includes changes to core routing, firewall policy, production segmentation and network paths used by safety-critical systems. Large changes across several sites also need careful review.

For airports, hospitals and factories, the impact of a wrong change can extend beyond IT. It may affect passenger services, patient care or production lines. In these environments, human approval should remain part of the process for high-impact decisions.

What to ask before buying an agentic NetOps platform

A product demonstration should show more than a fault being fixed. Ask the vendor to show how the system receives authority, explains its actions and recovers from a mistake.

Use this checklist during evaluation:

1.          Visibility: Can the tool show the evidence it used, the devices it checked and the current network state?

2.          Permissions: Can access be limited by site, device, task and change type? Does it use named identities and role-based permissions?

3.          Approval: Can high-risk actions wait for approval from the right engineer or service owner?

4.          Audit trail: Does every action include a timestamp, input, decision, change and outcome?

5.          Rollback: Can the team restore the previous configuration quickly? Has that process been tested?

6.          Scope limits: Can the organisation set maintenance windows, rate limits and affected-device limits?

7.          Testing: Can the workflow run in simulation or read-only mode before it reaches production?

8.          Ownership: Is there a named person responsible for each automated workflow?

9.          Emergency stop: Who can suspend the agent during an incident, and how is that decision communicated?

10. Data handling: Where are telemetry, logs and configuration data stored? Who can access them?

The vendor should demonstrate these controls in the actual product. Ask for them in writing as well. A general promise of safe automation is not enough.

How to run a 60-day agentic NetOps pilot

Keep the first pilot narrow. Select one site, one workflow and a small group of devices. Choose a task that already has a documented response.

Weeks 1 and 2: observe. Run the tool in read-only mode. Compare its diagnosis with the decisions made by experienced engineers. Record correct findings, missed findings and unnecessary recommendations.

Weeks 3 to 6: request approval. Allow the software to prepare the change. Require an authorised engineer to approve or reject each action. Record how often the recommendation is accepted, edited or rejected.

Weeks 7 and 8: automate one low-risk task. Move one proven workflow into limited production use. Keep the action scope small and maintain a tested rollback path. Do not increase autonomy if the earlier stages show repeated errors.

Measure performance against a baseline. Useful measures include:

·       Time from alert to diagnosis.

·       Time from diagnosis to service restoration.

·       Percentage of recommendations accepted without changes.

·       Number of incorrect or unnecessary actions.

·       Engineer hours spent on routine incident work.

·       Repeat incidents after the automated action.

Agree on pass and fail conditions before the pilot begins. For customer-facing or safety-related services, the acceptable number of harmful automated changes should be zero.

When should you wait?

A pilot should wait if the device inventory is unreliable or configuration changes are poorly documented. It should also wait when teams cannot identify an owner for each workflow. These gaps make it difficult to judge whether the software acted correctly.

Do not use automation to compensate for unclear network design. First establish visibility, ownership, change control and recovery procedures. Then automate tasks that already work well by hand.

Frequently asked questions

Is agentic NetOps the same as AIOps?

No. AIOps usually helps teams analyse events and recommend responses. Agentic NetOps can also carry out approved actions. The distinction depends on the product and the level of authority granted.

Does agentic AI replace network engineers?

It should reduce repetitive investigation and routine work. Engineers still need to design networks, assess risk and handle unusual incidents. They should also define and review the software's operating limits.

Can agentic AI make changes to a live network?

Some platforms can make production changes. Start with read-only analysis and approval-based workflows. Allow independent action only for low-risk tasks with tested controls.

What should an organisation assess first?

Review network visibility, device inventory, configuration consistency, telemetry, permissions and change management. These determine whether automation can work safely.

Build the operating foundation first

Agentic AI can help network teams deal with recurring work. Its value depends on the quality of the network and the rules around each action.

Start with a clear view of the environment. Identify the tasks that are safe to automate. Test them with human review before granting more control.

Explore Arche's network capabilities or speak with the Arche team about your network modernisation priorities.

Share artilce:

linkedin
linkedin
twitter
twitter

Written by

Mahadevan V

Director (Professional Services)

Linkedin
Linkedin
Netcon Logo
Hamburger

BLOG

Agentic AI in NetOps: What to Automate and What to Keep Under Human Control

BY

Mahadevan V

—

8

min read

Network teams are being asked to keep more services running across more locations. They also need to manage cloud applications, connected devices and new AI workloads. Yet many teams still spend hours sorting alerts and repeating routine fixes.

That workload has renewed interest in agentic AI in network operations. The idea is simple: software investigates a network issue, selects a response and carries it out within rules set by the organisation.

The decision needs more care than a software demonstration can show. A tool that restarts one access point is different from a tool that changes routing across several sites. Both may be described as autonomous. Their risks are not the same.

Cisco and Omdia surveyed 1,000 IT and network operations leaders in September 2026. Their research found that 51% of respondents already ran agentic AI that acts in production NetOps. The same research found that 84% expected an AI-led operating model within 12 months. Cisco also reported that 95% felt their existing AIOps tools could not keep up with operational needs. Read the Cisco and Omdia findings.

These are survey findings, not a measure of every enterprise network. They do show that network leaders are evaluating greater automation. The useful question is where to begin, and what safeguards must come first.

What agentic AI in NetOps actually does

Traditional network monitoring tells a team that something has happened. A monitoring system may report packet loss, an overloaded link or an access point failure. AIOps tools can correlate events, spot patterns and recommend a response.

Scripts and runbooks take the next step, but they follow instructions written in advance. A script might restart a service after a specific alert. It does not usually decide whether that action is suitable for a new situation.

Agentic AI adds a decision layer. It can gather evidence from several tools, assess the likely cause, choose from approved actions and check the result. A person defines the permitted actions and the conditions for using them.

That does not mean an agent should receive unrestricted access to the network. Its role should be limited to specific tasks, devices, sites and change types. The organisation should also be able to review every action.

Three levels of control

A useful way to assess agentic NetOps is to separate it into three operating levels.

Level

What happens

Suitable starting point

Main control

Recommend

Software investigates and suggests a fix. An engineer decides whether to apply it.

Fault diagnosis and evidence gathering.

Engineers review the recommendation.

Act with approval

Software prepares the change and waits for an authorised person.

Repeat incidents with a known response.

Approval is required before execution.

Act within limits

Software applies a pre-approved action and reports the outcome.

Low-risk tasks proven through earlier stages.

Scope, rollback and monitoring are defined in advance.

 

Most organisations should spend time in the first two levels. They need evidence that the recommendations are accurate. They also need to understand how the software behaves during unusual conditions.

Autonomy should be granted to individual tasks, not to the network as a whole. A team may approve automated port recovery while retaining human approval for routing or firewall changes.

The network must be ready before software can act

An agent can only make a sound decision when it has reliable information. It needs an accurate device inventory, current network diagrams and access to useful telemetry. It must also understand the relationships between users, applications, devices and sites.

A fragmented network makes this difficult. Engineers may have to log into separate devices to check configurations. Important dependencies may exist only in spreadsheets or in the experience of individual team members. Several monitoring tools may show different parts of the same incident.

A central management layer helps bring these views together. Software-defined networking can also make policies more consistent and changes easier to test. It gives operations teams a clearer view of network state and approved control points.

Arche's Networks practice covers network modernisation, campus and branch connectivity, network observability, infrastructure automation and AI-ready networks. The existing Arche articles on software-defined network architecture and legacy campus migration provide useful background before an automation programme begins.

The airport network programme at Bangalore International Airport offers a practical example of the groundwork. Arche's case study describes a phased move to software-defined networking across more than 50 systems. The resulting environment supports more than 50,000 IP endpoints across over 50 airport subsystems. The case study shows the value of central control, segmentation and planned migration. It should not be read as a claim that the airport runs autonomous agentic NetOps.

Which network tasks should you automate first?

Start with tasks that are frequent, predictable and easy to reverse. A good first use case has a clear success condition. It should also have limited impact if the action fails.

Examples include:

·       Collecting logs, device status and configuration details before an engineer investigates an incident.

·       Grouping duplicate alerts that point to one underlying fault.

·       Checking whether a configuration backup completed successfully.

·       Restarting a known service or access port after a specific fault, where the device and service owner approve it.

·       Moving a branch to a backup connection when defined health checks fail and the failback process is tested.

·       Opening or updating a ticket with the evidence collected during diagnosis.

These jobs reduce repetitive work without handing over broad control. They also create a record of how well the software performs.

Some work should remain human-led until the organisation has strong evidence. This includes changes to core routing, firewall policy, production segmentation and network paths used by safety-critical systems. Large changes across several sites also need careful review.

For airports, hospitals and factories, the impact of a wrong change can extend beyond IT. It may affect passenger services, patient care or production lines. In these environments, human approval should remain part of the process for high-impact decisions.

What to ask before buying an agentic NetOps platform

A product demonstration should show more than a fault being fixed. Ask the vendor to show how the system receives authority, explains its actions and recovers from a mistake.

Use this checklist during evaluation:

1.          Visibility: Can the tool show the evidence it used, the devices it checked and the current network state?

2.          Permissions: Can access be limited by site, device, task and change type? Does it use named identities and role-based permissions?

3.          Approval: Can high-risk actions wait for approval from the right engineer or service owner?

4.          Audit trail: Does every action include a timestamp, input, decision, change and outcome?

5.          Rollback: Can the team restore the previous configuration quickly? Has that process been tested?

6.          Scope limits: Can the organisation set maintenance windows, rate limits and affected-device limits?

7.          Testing: Can the workflow run in simulation or read-only mode before it reaches production?

8.          Ownership: Is there a named person responsible for each automated workflow?

9.          Emergency stop: Who can suspend the agent during an incident, and how is that decision communicated?

10. Data handling: Where are telemetry, logs and configuration data stored? Who can access them?

The vendor should demonstrate these controls in the actual product. Ask for them in writing as well. A general promise of safe automation is not enough.

How to run a 60-day agentic NetOps pilot

Keep the first pilot narrow. Select one site, one workflow and a small group of devices. Choose a task that already has a documented response.

Weeks 1 and 2: observe. Run the tool in read-only mode. Compare its diagnosis with the decisions made by experienced engineers. Record correct findings, missed findings and unnecessary recommendations.

Weeks 3 to 6: request approval. Allow the software to prepare the change. Require an authorised engineer to approve or reject each action. Record how often the recommendation is accepted, edited or rejected.

Weeks 7 and 8: automate one low-risk task. Move one proven workflow into limited production use. Keep the action scope small and maintain a tested rollback path. Do not increase autonomy if the earlier stages show repeated errors.

Measure performance against a baseline. Useful measures include:

·       Time from alert to diagnosis.

·       Time from diagnosis to service restoration.

·       Percentage of recommendations accepted without changes.

·       Number of incorrect or unnecessary actions.

·       Engineer hours spent on routine incident work.

·       Repeat incidents after the automated action.

Agree on pass and fail conditions before the pilot begins. For customer-facing or safety-related services, the acceptable number of harmful automated changes should be zero.

When should you wait?

A pilot should wait if the device inventory is unreliable or configuration changes are poorly documented. It should also wait when teams cannot identify an owner for each workflow. These gaps make it difficult to judge whether the software acted correctly.

Do not use automation to compensate for unclear network design. First establish visibility, ownership, change control and recovery procedures. Then automate tasks that already work well by hand.

Frequently asked questions

Is agentic NetOps the same as AIOps?

No. AIOps usually helps teams analyse events and recommend responses. Agentic NetOps can also carry out approved actions. The distinction depends on the product and the level of authority granted.

Does agentic AI replace network engineers?

It should reduce repetitive investigation and routine work. Engineers still need to design networks, assess risk and handle unusual incidents. They should also define and review the software's operating limits.

Can agentic AI make changes to a live network?

Some platforms can make production changes. Start with read-only analysis and approval-based workflows. Allow independent action only for low-risk tasks with tested controls.

What should an organisation assess first?

Review network visibility, device inventory, configuration consistency, telemetry, permissions and change management. These determine whether automation can work safely.

Build the operating foundation first

Agentic AI can help network teams deal with recurring work. Its value depends on the quality of the network and the rules around each action.

Start with a clear view of the environment. Identify the tasks that are safe to automate. Test them with human review before granting more control.

Explore Arche's network capabilities or speak with the Arche team about your network modernisation priorities.

Linkedin

Written by

Mahadevan V

Director (Professional Services)

Share artilce:

linkedin
twitter

Partner with us

Unlock your business potential with our committed team driving your success.

Networks