Agentic AI in network operations, minus the hand-waving

“AI for networks” currently describes at least four different things, most of which are a language model summarising alerts you were already ignoring. It is worth being precise about what an agent is, because the difference determines whether it shortens an incident or adds a tab to it.

What makes an agent an agent

The distinguishing property is not that it uses a language model. It is that it takes actions in a loop: it forms a hypothesis, gathers evidence to test it, updates, and repeats until it reaches a conclusion or runs out of useful moves.

A summariser receives whatever context you hand it and produces prose. An agent decides what to look at next. During a network incident that distinction is everything, because the sequence of questions is the diagnosis.

What that looks like in an incident

Take a latency alert on a core interface. A summariser tells you there is a latency alert on a core interface. An agent does something closer to this:

• Pulls the underlying time series to see the shape of the deviation and when it began.
• Queries logs for the same device and window, and finds a BGP session flapping.
• Asks what changed on that path recently, and finds a config deploy six minutes before onset.
• Reads the rendered diff, and sees an MTU value dropped from 9214 to 1500.
• Checks intended state in the source of truth, confirming 9214 is correct.
• Searches past incidents, and finds the same template caused this before.
• Proposes restoring the MTU, with a rollback plan and a scoped blast radius.

Seven steps, each one chosen because of what the previous step returned. That is the loop. Nothing in it is beyond a competent engineer; the difference is that it completes in seconds and it happens the same way at two in the morning as at two in the afternoon.

Why the unglamorous infrastructure decides the outcome

Every step above depends on something existing to query. Step one needs retained time series. Step three needs a structured change log. Step five needs intended state recorded separately from running state. Step six needs incident history that is searchable.

This is the part that gets skipped in demonstrations and dominates real deployments. An agent on top of a network with no source of truth, no change telemetry and five-minute SNMP polling will produce confident, plausible, unfounded answers — which is worse than no agent, because people act on them.

The practical order of work is therefore unromantic: source of truth first, then change telemetry, then signal quality, and the agent last. Agent enablement is typically the shortest phase of an engagement.

Where the guardrails go

Three questions decide whether an agent is deployable in a serious environment.

What may it read? Read access should be scoped and explicit. In practice an agent needs the source of truth, the metrics and log stores, and change history — and nothing else. Credentials are per-tool and least-privilege rather than a shared admin account.

What may it change? Our default is nothing, without approval. Actions move up an autonomy ladder — observe, propose, approve-then-act, act-and-report — one action at a time, on evidence. Blast-radius policy caps scope before execution, not after.

What does it record? Every observation, inference, proposal and action, with enough detail to reconstruct the reasoning in a post-incident review. An agent whose decisions cannot be audited will not survive its first bad call, and it should not.

What it is not good at

Worth saying plainly. An agent is weak on genuinely novel faults with no precedent and no recorded intent to compare against. It is weak on judgement calls that are really business decisions — whether to fail over during a trading window is not a technical question. And it is only as good as the data, which means a confident answer from a poorly instrumented network should be treated with more suspicion, not less.

The honest framing is that an agent handles the large, repetitive middle of the incident distribution — the faults with a knowable cause and a known fix — and hands your engineers the tail, with the context already assembled.

A reasonable way to start

Run it in observe-only mode against real incidents for a few weeks. Compare its diagnosis against what your engineers concluded. You will learn two things quickly: how often it is right, and — more usefully — which missing data source is responsible when it is wrong.

That second finding is normally the actual project.

If you want to work out where your environment sits, our readiness consultation covers exactly this ground.