Having spent the last year playing around with a variety of AI tools, I have come to realize their potential — particularly for those of us in the non-profit sectors — to drastically improve how we work and our organizations operate.
In this blog series, I will explain what agentic AI is, how it processes and computes prompts, and provide some hands-on examples of how agentic AI can be used for network operations, including parsing NOC mailing lists, rewriting network utilities, and analyzing router configurations. I’ll also be looking at the benefits of self-hosted, open-weight models for maintaining data sovereignty and avoiding vendor lock-in.
The overarching goal of this brain dump of information is to inspire network and systems administrators – or anyone in the digital network space – to start playing around with these tools. AI has the potential to influence virtually every aspect of your role and your organization’s operations. I strongly encourage anyone with even a passing interest in these tools to explore them, as it presents a great opportunity to creatively improve your daily work environment.
Agentic AI is more than a chatbox
If you’ve spent any time on the internet over the last few years, you’ve likely interacted with a Large Language Model (LLM). You type a prompt into a text box, hit enter, and wait for the AI to return with a food recipe, draft email, or block of code.
For many of us, this “chatbot” model defines how we understand artificial intelligence: a highly articulate (and often verbose!) search engine wrapped in a Q&A interface. But AI is beginning to move beyond conversation and into action. We are entering the era of agentic AI, where systems can pursue goals, use tools, and act on the information they encounter. For those of us responsible for the infrastructure that keeps research and education networks running, this is a shift we need to understand.
The AI services we already use
Most people first encounter AI through a general-purpose assistant, such as ChatGPT, Claude, or Gemini. These services package an AI model inside a polished web or mobile application. Office products such as Microsoft 365 Copilot add access to organizational email, documents, meetings, and calendars. Coding tools go a step further: products such as GitHub Copilot, Codex, and Claude Code can inspect a software project, edit files, and run development tools.
Underneath these products are several distinct layers:
- Model: the mathematical system that interprets input and generates a response.
- Inference service: provides the computing infrastructure that runs the model. This might be a public commercial service, a service dedicated to one organization, or a model running on infrastructure you operate yourself.
- Interface: is where a person interacts with the service, such as a chat window, an editor, or a terminal.
- Agent harness: coordinates the model, its instructions, its tools, and the information it collects while working on a task.
These layers can be mixed and matched. The same terminal-based agent might use a commercial model one day and a locally hosted open model the next. Similarly, a familiar chat interface can become much more capable when it is connected to organizational data and given tools with which it can act.
This distinction matters. A model can generate text, but the surrounding software determines what information it sees, what actions it can take, and where the resulting data goes.
What is an Agent?
To put it simply, an AI agent isn’t only waiting for you to ask it a question. An agent is given a goal, equipped with a set of tools, and sets forth in an environment to figure out how to achieve that goal.
Imagine you hire a junior network engineer. You don’t stand over their shoulder and dictate exactly which keys to press on their keyboard. You tell them, “We need to figure out why latency spiked to the Calgary node last night. Please investigate and write up a report.”
That junior engineer should know how to SSH into a router, run a “traceroute”, check the log files, and write a summary. They act autonomously, using their tools to achieve the goal you set.
An AI agent operates on the same principles. Instead of just generating text, an agent can execute shell commands, read files on a hard drive, query APIs, and, crucially, look at the output of those actions and decide what to do next.
In practice, an agent works in a loop:
- It receives a goal and a set of instructions.
- It reviews the information and tools available to it.
- It chooses an action, such as reading a file or querying a monitoring system.
- It examines the result and updates its understanding of the problem.
- It repeats this process until it reaches the goal, runs into a limit, or needs a person to make a decision.
This does not mean every agent should be given permission to change production systems. Autonomy exists on a spectrum. A read-only agent might collect evidence and draft a report. Another might prepare a configuration change but require an engineer to approve it. A highly autonomous agent might be permitted to make certain decisions on its own.
The important difference is not whether a human clicks every button. It is whether the software can choose and perform intermediate steps in pursuit of a goal.
Context is Everything
So, how does an agent know what to do? It all comes down to context.
An AI model does not automatically know about your network topology, your specific firewall rules, or the fact that your core router is running an outdated firmware version. It can only work with information learned during its training and information provided to it for the current interaction.
That information is called context. Context can include your prompt, the agent’s operating instructions, earlier messages in the conversation, files it has read, results returned by tools, and any reference material retrieved from another system. The model receives this material inside a context window: a limited working area used to produce its next response or decide on its next action.
The context window is not the same thing as long-term memory. When a troubleshooting session ends, the model does not retain everything it learned about your network. If an agent needs information from an earlier session, it must store that information and supply it to the model again later.
When you give an agent a task like “troubleshoot this BGP flap,” the agent harness can help build context. The harness might allow the agent to read relevant configuration files, pull current routing tables, and inspect recent log entries. The agent can then compare those observations, identify a possible anomaly, gather more evidence, and propose a fix.
Modern models can accept very large context windows, sometimes enough text to fill several books. But a larger window does not mean the model will use every detail equally well. Irrelevant logs can bury the important event. Old data can conflict with current data. A misleading instruction inside a document can send the agent in the wrong direction. Every additional piece of context requires computing resources to process.
This creates a new engineering discipline sometimes called context engineering: deciding what information an agent should receive, when it should retrieve it, how its source should be identified, and what should be left out. Good context is not simply more data. It is the right data, from trustworthy sources, delivered at the right point in the task.
This is also where the security implications become clear. If an agent can read a router configuration, that sensitive configuration may be sent to whichever inference service is running the model. If it can execute commands, its credentials and permissions determine how much damage a mistake or malicious instruction could cause. Context, access, and authority therefore need to be taken into account together.
Moving past the hype
It’s easy to read vendor marketing and assume these agents are magic. They aren’t. They are software systems using probabilistic models to choose and invoke tools. They make mistakes. They can confidently misinterpret incomplete context, get stuck in loops, or take an action that technically succeeds but does not achieve the intended goal. And, as we’ll explore later in this series, they introduce entirely new security and cost paradigms.
But the capability is real. The shift from “tell me how to fix this” to “go investigate this and bring me the proposed fix” is profound.
Over the next few weeks, we’re going to look under the hood. We’ll explore how these inference engines actually work, the role open models can play in data sovereignty, and I’ll walk you through exactly what it looks like to have an AI agent live-rewrite core network utilities on our infrastructure.