AI Agents for Production Networks

AI agents are starting to move from simple chatbots into operational systems.

In network operations, that means the work is no longer just about answering questions. An agent has to understand the intent, decide what information is needed, collect that information safely, and explain what can and cannot be concluded. That is a very different problem from a general-purpose chatbot and part of an emerging category called agentic NetOps.

In network troubleshooting, the process usually starts with uncertainty.

Something breaks, slows down, flaps, disappears, or triggers an alert. A user may report packet loss. A device may reboot overnight. A BGP session may drop. An interface may show errors. A circuit may go down. A MAC address may need to be traced across the network.

At that moment, the operator rarely has one clean answer. They have fragments. An alert from one system. Logs from another. Telemetry somewhere else. Device state from the CLI. A topology diagram that may or may not be current. A ticket with partial context. A memory of how the network is supposed to behave.

The job of the network engineer is to turn those fragments into an answer. That is the problem Nanites is built to solve.

Nanites is an AI network engineer for production networks. It helps infrastructure teams investigate network issues using data from live devices, telemetry, alerts, logs, topology, and other infrastructure systems.

The goal is not to replace every engineer or pretend that AI magically understands the network. The goal is to help teams find the needle in the haystack faster, understand what is happening, and move from alert to root cause with less manual work.

An AI agent for network operations has to be more than a chatbot. A chatbot can answer general questions, but it does not know what is happening inside a network unless it can collect and verify evidence.

It also has to be more than monitoring. Monitoring can tell a team that something may be wrong, but the operator still has to investigate why.

And it has to be more than an SSH assistant. Running commands is only one small part of troubleshooting. The harder part is knowing which devices to check, which commands matter, how the results relate to each other, and whether the evidence is strong enough to support a conclusion.

The simplest way to describe the role is this: monitoring tells you something may be wrong; an investigation agent helps determine why.

For example, a monitoring tool might report high interface errors. That alert is useful, but it is not the full answer. A network engineer still needs to know where the errors are, whether they are increasing now or only accumulated from the past, whether the interface is still up, whether the peer side is also showing errors, whether routing sessions are affected, and whether there is actual service impact.

A weak AI tool might jump straight to a conclusion and say, “This is a bad cable.” That is not good enough for production operations.

A better answer would be more careful: “Interface ether2 has RX errors, but this is a single snapshot, not a rate. The interface is still up, and the routing sessions remain established. Current service impact is not proven from this evidence. The next step is to re-sample counters and check the peer-side interface.”

That is the kind of behavior production network agents need. They should separate what is verified from what is only suspected. They should explain what evidence was checked. They should be honest about what is still unknown. Most importantly, they should not invent certainty.

A typical investigation starts with an operator question or an alert. The question might be narrow, such as “Where is this MAC address?” It might be operational, such as “Are all optical ports healthy?” It might be incident-driven, such as “Why did this circuit go down?” Or it might be broad, such as “Give me a current health summary for the managed MikroTik and OcNOS devices.”

The agent then has to decide what kind of evidence is needed. Some questions require live device state. Others require telemetry. Others require logs, flow data, topology, alerts, or a combination of sources. That distinction matters.

If someone asks whether a BGP session is currently down, live device state may be the right source. If someone asks about peak bandwidth utilization last night, telemetry is probably the right source. If someone asks about top outbound ASN over the last week, that requires flow data and enrichment. If someone asks where a MAC address is connected, the answer may require MAC tables, ARP, EVPN/VXLAN state, neighbor data, and topology.

This is why network agents cannot be just “LLM plus tools.” Network troubleshooting is not one generic task. Each question requires the system to understand what kind of evidence is appropriate. At production scale, this becomes even more important. The system cannot blindly scan every device or send raw output from hundreds of devices into a model. It has to route each question to the right evidence path. A fleet health question may require telemetry, cached state, or exception-first summaries. A historical bandwidth question should go to a time-series database. A traffic question may require flow data. A topology or MAC-location question may require source-of-truth data, live device state, and indexed observations. The hard part is not giving an AI agent tools. The hard part is deciding which source is authoritative for the question, collecting only what is needed, and reducing that evidence into something reliable enough to reason over.

Heterogeneous networks make this even harder. They have many devices, vendors, operating systems, firmware versions, sites, alerts, logs, and monitoring systems. Cisco, Juniper, Arista, Aruba, SONiC, MikroTik, OcNOS, and other platforms may expose similar information in different ways. Even within a single vendor stack, behavior can vary between versions.

A human engineer learns these differences through experience or uses vendor documentation to help. They know that one counter may be cumulative while another may represent a rate. They know that some log messages are urgent and others are normal noise. They know that an alert may be a symptom, not the root cause.

The challenge is bringing more of that discipline into software.

The AI model helps with planning, reasoning, interpretation, and explanation. But the model is not the whole product. The value comes from the system around the model: deterministic routing, safe device access, approved commands, topology awareness, telemetry integrations, alert normalization, structured evidence, raw evidence preservation, evaluation testing, run history, and rules for uncertainty.

In other words, the goal is not “an LLM for networks.” The goal is a network operations system that uses a validated AI model path to perform evidence-backed troubleshooting.

That distinction is important because production networks require trust. An AI system cannot simply sound confident. It has to be safe, controlled, and auditable. It should be read-only by default. It should not run unrestricted commands. It should not overwhelm devices. It should not make configuration changes without approval. It should preserve the evidence behind its conclusions.

A good network investigation agent should feel like a careful engineer was involved. It should say what was checked, what was found, what appears healthy, what looks degraded, what is suspicious, and what is not proven yet. It should also suggest the next logical check when the evidence is incomplete.

For example, instead of giving a vague answer like “the network looks unhealthy,” it should explain the specific finding: “The device is reachable, interfaces are up, OSPF neighbors are Full, and BGP sessions are established. The only abnormal finding is increasing RX errors on EDGE-A ethernet1. This may indicate a physical-layer issue, but current impact is not proven yet. Re-sampling counters and checking the peer interface would confirm whether the errors are active.”

That is useful because it gives the operator something grounded. It does not just summarize. It investigates.

The long-term idea is simple: infrastructure teams should not have to manually stitch together alerts, logs, telemetry, CLI output, topology, and tribal knowledge every time something breaks.

AI agents can help collect the right evidence, connect the dots, and produce a clear investigation record.

Monitoring tells teams that something may be wrong. The next layer investigates what is actually happening.