Building Agentic Network Diagnostics FlowAgents With NetBox & Itential Platform

Want to catch up on Part 1? Read it here.

The lab that started as two virtual Arista switches connected to Itential Platform just grew up. I brought in NetBox as a real system of record, and built my first two agents on Itential’s FlowAI agent harness. Both changes turned out to be bigger unlocks than I expected.

Put plainly: instead of an agent that just chats about your network from whatever it remembers, you get one that reasons over your actual inventory and takes real, scoped actions against real devices. That distinction is the whole point of this entry.

The Short Version

Two things changed this round, and they compound: NetBox becomes the network’s authoritative record, feeding real device data into Itential Platform, and FlowAI agents get wired to Claude through the Model Registry so they can query that same data and take scoped action, live, against real infrastructure.

Terms Worth Knowing First

• NetBox
  An open source tool for modeling network infrastructure, devices, IP addresses, sites, and how they relate. It’s a common choice for a network’s source of truth, the one system everything else is supposed to match.
• Source of Truth
  The authoritative system of record for what your network is supposed to look like. When something else, a device, a script, an agent, disagrees with it, the source of truth wins.
• FlowAI
  Itential’s agent harness. It lets you build AI agents inside Platform that reason over real data and call real workflows as tools, instead of just chatting about your infrastructure in the abstract.
• Agent Project
  A structured container in Itential Platform that holds one or more agents together with their scope, tools, and model configuration explicit and auditable.
• Model Registry
  The part of Platform that connects an LLM, in this case Claude, to the FlowAI agent framework, so an agent has a model to actually reason with.
• Tool Scoping
  Deliberately limiting which actions an agent can call. An agent can only do what its tools allow, nothing more, regardless of what it’s asked to do.

NetBox Becomes the Source of Truth

Real device data, names, IPs, sites, platforms, now flows from NetBox into Itential Inventory Manager, then into Itential Gateway. Every agent in this post reads from that same pipeline, not a hardcoded device list I typed in by hand. If NetBox says a device exists, Inventory Manager knows about it. If it doesn’t, no agent below can see it either.

Two Agents, Two Different Jobs

Both agents are built on FlowAI, both wired to Claude through the Model Registry, and both live inside a single Agent Project. One reads NetBox. The other operates on live devices, and only ever reads them.

Neither toolset was obvious on the first pass. For each agent I went back and forth with Claude on exactly which tools it actually needed, starting broader than necessary and narrowing until the list matched the job: four NetBox lookups for one agent, is-alive and get-config for the other, a reachability check and a running-config pull, nothing more exotic than that. What wasn’t up for negotiation was whether Arista Device Ops could write to a device. That was decided before a single tool was chosen, not discovered partway through scoping. This agent investigates. It does not change anything. Everything else about these two agents got worked out through iteration. That part didn’t.

Straight From NetBox, No Guessing

The NetBox agent’s toolset is scoped to querying NetBox directly. Every answer is traceable back to a single, real lookup, not a language model guessing from whatever it remembers about network conventions.

One tool call, straight to NetBox, correct answer. No hallucination, it looked it up.

Seven Real Devices, Tracked in One Place

The lab now runs seven devices end to end, but only five of them are meant to live in NetBox: access1, dist1, ceos1, ceos2, and isp1, a small campus-style topology with access, distribution, and edge roles. The other two are plain end hosts sitting on the wire behind access1, useful for generating real traffic, but intentionally left out of that authoritative record since they aren’t network infrastructure themselves. Every agent in this post is reading from the same five-node table NetBox and Inventory Manager actually see.

Reasoning Over a Live Device, In the Open

This is what the Agent Sessions tab is actually for. Every run gets logged start to finish, the exact prompt, every reasoning step, every tool call in order, and the final answer, each with its own timestamp. Below is one real session, unedited: asked to pull the running-config for every device in the inventory.

From there the agent works its way down the confirmed device list the same way every time, an is-alive check paired with a get-config pull, one device at a time, six more tool calls before it writes up a single answer.

It Didn’t Just Answer, It Noticed Something

The moment that actually got me came from a smaller, more targeted prompt against a single device. Not a bulk pull, just a status check.

It didn’t just retrieve data. It noticed a discrepancy between the inventory label and the device’s actual configuration, and proactively explained why that was expected instead of flagging it as an error. That’s the difference between an AI that runs a command and an AI that reasons about a network.

Real Sessions, Run Against Real Infrastructure

Both agents were tested end-to-end with real prompts against real infrastructure, and every run left a full reasoning trace behind, exactly how the agent selected and used its tools, not just the final answer.