Skip to main content

Aviz Networks details how Network Copilot automates network triage

Aviz Networks says its Network Copilot Troubleshooting Agent automates datacenter network triage by running device commands, collecting evidence, classifying the failure domain, and assigning confidence scores, aiming to cut troubleshooting time from 15–20 minutes to about 2 minutes per incident.

Research Overview

The blog describes a repeatable network incident workflow in which engineers SSH to devices, execute a checklist of commands, correlate CLI outputs, and determine the failure layer by hand, often taking 15 to 20 minutes per ticket.

It argues that variability between engineers and manual evidence correlation drive delays, and presents the agent as a replacement for the manual command-and-correlation cycle in datacenter troubleshooting.

Key Findings

The blog states that the agent automates the workflow of command execution, parsing, evidence collection, failure-domain classification, and confidence scoring, with a reported reduction to roughly 2 minutes for structured diagnoses.

It also states the agent avoids a chatbot approach for command selection by executing the checks, parsing the results into structured outputs, and then producing a diagnosis that includes a confidence score and next actions.

Technical Breakdown

The architecture is described as separated into layers where the AI layer determines mode and returns structured output, while an SSH transport layer handles connectivity and a workflow layer handles triage logic.

According to the blog, tools return a consistent schema that includes success status, device, command, parsed data, and raw output, with parsing normalized via a parser layer that converts vendor-formatted CLI output into JSON.

Workflow behavior and reliability rules

The blog says the workflow collects evidence from multiple checks before classifying the failure domain, rather than stopping at the first detected failure.

It states the classifier distinguishes timeout conditions from missing entries by storing failed checks with error information, returns UNKNOWN with low confidence if three or more commands fail, and reports only items that are confirmed in device output.

Operational Impact

The blog presents a nine-step automated workflow that starts with reachability (ping) and proceeds through interface health, Layer 2 forwarding checks, SVI/gateway state verification, ARP, routing, BGP, log parsing, and ACL hit checks.

It lists failure domains the agent can output, including L1_PHYSICAL, L2_VLAN, L2_TRUNK, L2_MAC_LEARNING, L3_ARP, L3_ROUTING, CONTROL_PLANE_BGP, AGGREGATION_PORT_CHANNEL, POLICY_ACL, SYSTEM_EVENT, and UNKNOWN, and provides an example diagnosis report with a confidence level, probable cause, evidence items, and next actions.

The blog also states multi-tenant support via an optional vrf= parameter for certain checks such as ARP, routes, and interface briefs, and describes transport support for NX-OS, Catalyst, Arista, and SONiC.

Blog Signals brief is a fact-based summary of the vendor blog.