Running Networks with an AI Coworker

Artificial intelligence is often discussed as if its value begins and ends with the model. In networking, that framing is tempting, but it is also misleading. A model that can explain BGP, summarize a firewall rule or suggest a show command is useful, but it is not yet operating a network. The more interesting question is not whether AI can talk about infrastructure. It is whether AI can participate in the disciplined practice of running infrastructure safely.

That distinction matters because network operations is not merely a matter of knowing commands. It is a practice of judgment, verification, memory and restraint. A good engineer does not begin every problem by logging into a device and poking around. A good engineer asks what the system of record says, what the last known configuration shows, what the reachability model predicts, what the logs reveal and only then whether the live device needs to be touched. Agentic network operations are compelling when it follows that same order. It becomes dangerous when it forgets it.

This is what makes Tim Betz’s approach worth studying. He is not using AI as a chatbot that gives advice while a human does the real work elsewhere. He is using an AI agent as a coworker inside an operating platform. The agent answers questions, troubleshoots, onboards clients, provisions switches, runs assessments and improves parts of the platform it depends on. Prima facie, that sounds like the familiar dream of automation. However, the deeper point is not that the agent can act. The deeper point is that its actions are constrained by rails.

At the top of the system is still the human engineer. Tim chooses the task, reviews the findings, approves anything that changes state and resolves conflicts between the agent and a system of record. This is not autonomy in the careless sense. It is agency under supervision. The agent can read, reason and propose at high speed, but anything consequential still passes through a human gate. That distinction is not cosmetic. It is the difference between AI as an operational colleague and AI as an unsupervised actor in production.

The agent itself runs persistently in an agent harness on Tim’s machine. At the start of a session, it receives a network engineering identity with rules of engagement, troubleshooting methods and operating discipline. In other words, it is not treated as a generic assistant. It is shaped into a particular kind of coworker, one expected to behave like a careful senior engineer. It can also create sub agents for different kinds of work: read only troubleshooting, operational tasks, approved changes and engineering work on the platform itself. Each run in an isolated workspace so that parallel work does not collide.

Still, the agent qua agent is not the central achievement. The central achievement is the structure around it. Below the agent is a set of tools that decide how it touches anything real. It starts with internal Python helpers, then playbooks, then MCP servers that wrap the operational systems. Those systems include Nautobot for source of truth, a git based repository of configuration backups, Batfish for reachability modeling, OpenBao for secrets, log platforms for history and a controlled pipeline for live device access. The agent can call the tools, but the tools enforce scope, privilege and auditability.

The most important rule is simple: tools first, devices last. If the agent needs to understand inventory, ownership, sites or platforms, it asks Nautobot. If it needs configuration state, it reads backups. If it needs to reason about routes, ACL behavior, drift or reachability, it uses Batfish. If it needs to know what happened, it checks logs and telemetry. If it needs credentials, it resolves them through OpenBao by path. Only when those layers cannot answer the question does it reach the live device, and even then, it does so through one approved access path.

This order is not merely procedural. It expresses a philosophy of operations. The live network should not be the first witness called to the stand. It should be the last one, used only when the better records are silent or incomplete. Asking which ports have portfast enabled should not require logging into every switch. Asking whether a site can reach a subnet should not require tracing across half a dozen devices by hand. Those questions should be answered from trusted instruments. When they cannot be, the right answer is not to celebrate the workaround. The right answer is to fix the instrument.

That write back loop is what makes the platform compound. When the agent goes live because something was missing, stale or unmodeled, it does not simply solve the immediate case and move on. It writes the durable fact back into the source of truth. Nautobot improves. Configuration backups pick up the change. Batfish refreshes from those backups. The next time the same kind of question appears, the answer comes from the tool instead of the device. This is operational memory turned into architecture.

For many teams, knowledge still lives in fragile places: a ticket, a spreadsheet, a terminal window, a senior engineer’s memory or a half remembered outage call. Those forms of knowledge are useful, but they are not durable enough. Tim’s model treats every exception as a chance to make the network more knowable. That is a philosophical shift as much as a technical one. The point is not merely to solve the problem in front of you. The point is to make the next similar problem easier to solve.

Security follows the same pattern. The AI does not need to see a password in order to use a credential responsibly. In Tim’s platform, credentials live in OpenBao. The agent can reference a secret by path, but the plaintext value is fetched only inside the approved pipeline that consumes it. A missing secret fails closed. Each role receives only the access it needs. Secret access is logged. Thus, the claim that “AI has production credentials” is true only in a qualified sense. The agent can ask the system to use the right secret for the right device. It cannot read the secret into a chat window.

That qualification matters because many objections to AI in operations are not foolish. They are reasonable reactions to bad architecture. If AI is given broad device access, visible credentials and no hard approval gate, then concern is justified. But if secrets are hidden from the model, customer boundaries are enforced by infrastructure, changes require approval and every action is audited, then the question changes. The risk is not moot, but it becomes governable.

The Cisco Plug and Play server is the clearest example. A factory fresh switch boots with no configuration, finds the provisioning server and communicates through Cisco’s PnP protocol. The server walks the device through discovery, image installation, base configuration and port layout. That is useful automation, but it also creates a sharp threat model. Because the switch has no credential to present, the device facing side must assume that something else on the provisioning network might try to talk to it.

Tim’s platform responds by limiting the device facing endpoints, refusing to send credential bearing payloads over cleartext and binding server initiated work to single use, per device, per work type tokens. In plain terms, the server needs to know whether a device response is real or forged. That control prevents someone on the LAN from pretending to be a switch and triggering unintended work.

The more important story is how the agent hardened that system. It found security bugs, fixed them, wrote regression tests and sent the changes to an adversarial review process. A second model was told to break the first model’s work by looking for regressions, failed assumptions and security gaps. That review caught issues tests missed, including fail open behavior, a race condition and an authorization problem. The human still remained the final judge, but the review process made the human’s judgment better informed.

Then came shadow mode. Before enforcing a new control in production, the platform logged what it would have blocked without actually blocking it. This mattered because real networks contain edge cases that labs miss. In one case, a standalone switch legitimately returned a fault when asked about stacking. The new control would have blocked that response and stalled discovery. Shadow mode caught the issue before enforcement. The agent added the needed exception, validated again and only then turned enforcement on.

That sequence is the responsible shape of agentic operations: find the issue, fix it, review it skeptically, deploy it reversibly, observe real behavior, then enforce. The impressive part is not that AI found a bug. The impressive part is that the surrounding process refused to confuse speed with certainty.

For IT leaders, the lesson is practical. Agentic operations can make troubleshooting faster, onboarding more repeatable and operational knowledge more durable. But the prerequisite is not merely a stronger model. The prerequisite is stronger operational infrastructure: accurate source of truth, searchable configuration backups, reachability modeling, protected secrets, audited pipelines, human approval and reversible change.

Ultimately, agentic network operations are not about replacing engineers. It is about giving engineers a coworker that can move quickly through disciplined systems, document what it learns and strengthen the operating model over time. AI makes the work faster. The rails make it trustworthy. And in production networks, trust is the part that matters most.

At Flagler Technologies, we believe the future of network operations will be shaped not only by what AI can do, but by how responsibly it is deployed. Organizations that invest in accurate data, secure access, disciplined processes and human oversight will be best positioned to turn AI into a trusted operational advantage.

Ready to build a more intelligent, secure and resilient network? Connect with Flagler Technologies at info@flagler.io or call (561) 229-1601 to start the conversation.