Using an AI Agent for Network and Systems Operations

In the last few posts¹, we talked about the theory behind agentic AI: what agents are, the hardware required to run them, and why National Research and Education Networks (NRENs) should care about data sovereignty and open-weight models.

Theory is great, but let’s see some examples in action.

In this post, we’re going to look at the tools available to interact with these models. We will configure one to talk to a local AI endpoint, and use it to analyze a real-world network configuration.

The tooling landscape

The model and the agent harness are separate layers. As we discussed earlier in this series, the model provides the intelligence, while the harness gives it instructions, context, and tools. If you want to build an agent around an open-weight model, you have several choices for harnesses:

1. Editor extensions: Tools such as Continue and Cline run inside a code editor. They are useful when the work centres on a software project and you want to review changes alongside the agent.
2. Desktop and web applications: Graphical agent clients can provide file access, tool integrations, and a visual record of the agent’s work. These can be more approachable for people who do not spend most of their day in a terminal.
3. Terminal-native harnesses: Command-line tools fit naturally into network and systems operations. They can run on a workstation or headless server, work with existing shell tools, and operate directly alongside configuration files and source code.

Note: The AI landscape has settled on using the word “harness”, but you can think of it as another word for “tool”, “utility”, “plugin”, “extension”, etc.

For these exercises, I’m going to use pi. It’s a lightweight, terminal-native agent harness that allows us to bridge the gap between our local shell environment and our LLM of choice. There is a wonderful set of documentation available on pi’s homepage.

Setting up the local agent

This assumes you are familiar with working on the command line and have Node.js and npm available.

First, we need to install pi. It’s a quick install via your package manager:

$ npm install -g --ignore-scripts @earendil-works/pi-coding-agent

pi can interact with commercial AI services and with custom endpoints that provide access to open-weight models. The agent workflow stays largely the same even when the model and inference provider change.

Cybera has a small internal on-prem inference service running a Qwen 3.6 open model. I’ll be using that for the examples in the next few articles.

Recall from the previous posts that the practical benefit of an on-premises model is that prompts, files, and responses can remain on infrastructure you control. Running the service takes effort, but it provides an appropriate environment in which to explore sensitive operational data.

The easiest way to configure pi for the local inference service is to create this configuration file in ~/.pi/agent/models.json:

{
  "providers": {
    "local-cluster": {
      "name": "Cybera AI Cluster",
      "api": "openai-completions",
      "baseUrl": "https://example.com/v1",
      "apiKey": "AI_API_KEY",
      "models": [
        {
          "id": "qwen-reasoning",
          "name": "Qwen 3.6 Reasoning",
          "reasoning": true,
          "contextWindow": 131072,
          "maxTokens": 32768
        }
      ]
    }
  }
}

Next, start pi in a terminal:

$ pi

This is the chat interface that you’ll use to interact with the local agent. To confirm the agent is functional, you can type anything you want: “hello”, “who are you?”, or “ping”.

I now have an agent sitting in our terminal, backed by an open-weight model running on Cybera’s infrastructure.

Starting with a read-only task

An agent that can run shell commands is powerful, but that does not mean it should begin with access to production routers.

For this exercise, I exported a copy of our router configuration. The analysis did not require the agent to connect to the router or make any changes. The exported file gave it enough context to perform useful work without requiring live-device access.

This is a good starting pattern for operational AI: provide the minimum information and permissions required for the task. Read-only investigation, offline copies, redacted data, and human review allow us to learn what an agent can do before considering more consequential access.

Agent exploration

Let’s see what the agent can do. I placed a copy of Cybera’s Calgary router configuration file in the same directory as my pi session. I was curious how well the agent could read and understand it.

Prompt: This directory contains ./calgary-router.conf, which is a copy of our Calgary router’s Juniper configuration. Please review it and explain how it’s configured for NetFlow.

After approximately 60 seconds, the agent provided a result (below). I have redacted some sensitive areas for publication.

Calgary Router NetFlow (iPFIX) — Summary

Device: MX10003 (CGY-MX10K3-RE0) | Junos: 23.4R2-S3.9

### Protocol & Sampling

- Uses Juniper's inline JFlow with iPFIX (Information Export Protocol)
- Sampling rate: 1 in 500 packets (defined globally and per-instance)
- Single sampling instance CYBERA-CGY-01 applied to both FPC 0 and FPC 1

### Collector (flow-server)

┌─────────────────┬─────────────────────────────────────────────┐
│ Parameter       │ Value                                       │
├─────────────────┼─────────────────────────────────────────────┤
│ Destination     │ 1.2.3.4:4739 (standard NetFlow port)        │
├─────────────────┼─────────────────────────────────────────────┤
│ Source IP       │ 1.2.3.5                                     │
├─────────────────┼─────────────────────────────────────────────┤
│ Export interval │ Every 10 seconds                            │
└─────────────────┴─────────────────────────────────────────────┘

The source IP sits on a Frame Relay tunnel (lt-0/0/0 unit 201) whose description explicitly states it is "in order for NetFlow to RAC to work" — meaning the collector is reached across a research access tunnel.

### iPFIX Templates

- IPv4 template (CYBERA-CGY-01-v4): 60s active / 45s inactive timeout, 10s template refresh, 10s option refresh
- IPv6 template (CYBERA-CGY-01-v6): 60s active / 45s inactive timeout, 20s template refresh, 30s option refresh

Both families export to the same collector.

### How Sampling Is Triggered

Firewall filters are applied per-interface on each FPC. Three patterns are used:

1. samplev4_accept / samplev6_accept — simplest form; every matched packet is sampled then accepted. Applied to the majority of interfaces.
2. samplev4_noaccept / samplev6_noaccept — samples but continues to the next filter term (used where additional filtering is needed).
3. SAMPLE-ALL-v4 / SAMPLE-ALL-v6 — complex filters with ~15+ terms that count/discard attack patterns (NTP DDoS, martian sources, SSH attempts, BGP spoofing, etc.) before a final term 100 that samples and accepts all remaining legitimate traffic. Applied on both input and output directions.

### Port Mirroring (Separate from NetFlow)

Two mirror instances exist (fullrate-mirroring-input at 100%, partialrate-mirroring-input at 1/100) plus a fastnetmon-mirroring-output that forwards to a separate destination — these are independent from the iPFIX export.

### Key Takeaway

Every production interface triggers sampling via an inline firewall filter. Sampled packets are processed into flow records using the iPFIX templates and exported every 10 seconds to a single collector reachable over a Frame Relay research tunnel. The SAMPLE-ALL variant filters add DDoS/abuse protection as a side effect of the sampling pipeline.

Always check the work

The answer above was clean and didn’t have errors, but that’s not always the case. I’ve seen examples where the agent has typos and makes up the meaning of acronyms (such as thinking the acronym RAC meant Regional Access College network, rather than Rapid Access Cloud). An agent can provide an answer in a fraction of the time that it would have taken you to do it manually. Spend some of that saved time reviewing its work and checking for errors.

The useful part is the investigation

I encourage you to try using an agent to explore and “interview” copies of your network and systems configurations. Start with read-only data, limit the agent’s permissions, and double-check its conclusions against the source material.

The need for verification and review is not a reason to dismiss the technology. Engineers already review proposed configurations, vendor recommendations, scripts, and each other’s work. The agent belongs inside that same process, not outside it. Its value is in quickly navigating a large configuration, finding relevant sections, and giving the operator a useful starting point for investigation.

Working with an agent also improves the questions we ask. If the result is vague or unsupported, we can refine the prompt, provide better context, and require stronger evidence. “Garbage in, garbage out” still applies, but so does another familiar engineering principle: trust, but verify.

In the next post, we’re going to turn the dial up and ask the agent to do something much harder: rewrite a piece of classic network software from scratch.

---

Missed the previous blogs in this series?
Pt. 1: A primer on agentic AI for network administrators
Pt. 2: Inference Services
Pt. 3: Vendor lock-in, open models, and architectural choice

1. See above ↩︎