Building Continuous Compliance Checks With NetBox & Itential Platform

Two agents into this lab, I had one that could answer questions about the network and one that could poke at live devices when asked. Neither one was watching anything. If NetBox and a device quietly drifted apart, nothing would tell me until something else broke first. This round builds the piece that actually closes that gap, and I broke two switches on purpose to make sure it would notice.

Put simply: NetBox declares what a device should look like, Itential Gateway pulls what it’s actually running, and an Itential workflow compares the two, fact by fact, then reports where they disagree. Nothing external stitched together to make that happen. It’s built entirely from pieces already inside Itential Platform.

Terms Worth Knowing First

• Drift
  The gap between what a source of truth says a device should look like and what that device is actually running. Drift is the reason “it worked during the last audit” stops being good enough.
• Intent-Based Networking
  Declaring the desired state of the network once, in a system of record, then continuously verifying the live network still matches it, instead of trusting that a change made months ago is still in place.
• Design Studio
  Itential’s visual workflow builder, the same canvas from Part 1’s backup pipeline, used here to wire the NetBox lookup, the live config pull, and the comparison logic into one workflow an agent can call as a single tool.
• Task-to-Task Variable Binding
  Passing the output of one workflow task directly into another, so a live device response can be compared against a NetBox API response without either one touching custom glue code.
• JSON Forms
  The part of Design Studio’s evaluation engine that expresses comparison logic, does field X equal field Y, declaratively, as data, instead of as a script.

A Third Agent Joins the Project

Network compliance lands in the same Agent Project as NetBox Source of Truth and Arista Device Ops, not a new system to stand up, just another row in a table. Its description, in the platform’s own words: “Checks whether real Arista EOS device configuration matches NetBox’s declared intent across the fleet.”

Declared Intent Meets Live Reality

The fleet this agent watches is the same five devices established back in Part 2: access1 and dist1 and isp1 in supporting roles, plus ceos1 and ceos2 carrying the Core role in NetBox. The two end hosts NetBox also tracks as generic servers, useful for IP bookkeeping, sit outside this fleet entirely, they were never part of the network compliance check to begin with.

The agent’s entire toolset is one workflow, and its prompt is specific about what that workflow checks and what it must never do:

Breaking Two Switches on Purpose

A compliance agent that has never actually caught anything isn’t proof of much. So before running it, I logged into ceos1 and ceos2, the lab’s two core switches, and manually changed their configured hostnames so they no longer matched what NetBox had on record. Every other fact, on every other device, stayed untouched. Then I ran the check against the full fleet.

Inside the Workflow, Task by Task

This is what task-to-task variable binding actually looks like once you open the workflow up. One task in the comparison, “Config contains NetBox primary IP?”, takes two inputs: the real running-config text Itential Gateway just pulled off the device, and the raw JSON NetBox returned for that same device from its own API. No custom code sits between them, Studio passes one task’s output straight into the next task’s input.

That single task is one of several stacked into the same workflow, one comparison per fact, per device. When every comparison for a device comes back true, it’s compliant. When even one doesn’t, it’s drift.

Compliant, Drift, & One Honest Caveat

The workflow’s raw output is blunt: a status per device, nothing more.

Exactly the two devices I’d touched, flagged. Nothing else. Zero false positives across the rest of the fleet.

What happened next is the part I actually wanted to see. Asked to summarize the run, the agent didn’t just repeat the table, it told me what it couldn’t tell me:

It would have been easy for the agent to fill that gap with a plausible-sounding guess, ceos1’s hostname is probably wrong, given what Part 2 already found. It didn’t. It named the limit of its own tool and offered to dig further instead of inventing an answer. That’s the same design instinct behind making Arista Device Ops read-only: an agent should be honest about what it doesn’t know, not confident about something it made up.

Declaring desired state once means nothing if nothing ever checks it again. This agent is that check.

One Log, Three Agents

Every run against any of the three agents lands in the same place. This is the actual session list, sorted by start time, not a curated highlight reel: three different agents, seven runs, all completed, none failed.

What’s Actually Doing the Work

Where the Lab Goes Next

Three agents in, and each one does something the last one couldn’t: answer a question, investigate a live device, now continuously verify that intent and reality still agree. What none of them do is tell you what to actually do about a problem once one shows up. That’s next: an agent that starts from a real trouble ticket, reasons through the symptom, and proposes a fix instead of just reporting that something’s wrong. It only ever proposes. Touching a device stays a permission this lab hasn’t earned yet, on purpose.

Want to follow along with me? Connect with me on LinkedIn.