I sent a text message from my phone that read, roughly, “can you configure a new vlan 101 named voip on switch c9200-demo, then apply that vlan to gig1/0/2 and gig1/0/3.” Shorthand and all, the way I’d text a colleague. An earlier run of the same thing went through with an actual typo in it, and worked.
About a minute later my phone buzzed with an approval request: what was changing, which device, how big the diff was, the risk level, and how it would roll back. I replied Loop YES 6j5fm. The change went onto a real Cisco Catalyst 9200 with a five minute auto-revert timer armed, seven checks passed, the timer was cancelled, and the documentation updated itself.
Here is the whole thing, start to finish:
That’s a real run against real hardware. The long waits are compressed, and captions and narration are laid over the top, but nothing in either pane is a mockup.
What the loop actually does
You give it an intent in ordinary language. The AI reads the current state of the network from the source-of-truth system, which in my case is NetBox, and drafts a minimal plan. Then it stops and asks a person. It does read the live device before that point, to check its own plan against reality, but nothing is written to a device without a human reply.
Once approved, the change deploys with an automatic rollback timer. If a check fails, the change comes straight back out, either because the loop reverts it or because the timer on the device does it anyway. Post-checks verify both the thing that changed and the things that were supposed to stay the same, including whether I can still reach the switch at all. Finally the results are written back to documentation with an audit trail: what changed, when, who asked, who approved, and what proved it worked.
Being honest about “validation”
I want to be precise here, because this is where a lot of automation writing gets vague.
On some platforms you get a genuine dry run. My lab routers run SR Linux, which will load a candidate config and tell you whether it’s valid before you commit anything. If the device rejects it, the loop stops and no change is ever attempted.
Cisco IOS-XE has no CLI equivalent. There’s no exec-level “validate this config but don’t apply it.” It can expose a NETCONF candidate datastore that would give you something close, but that’s switched off on this switch, and I’d rather build the loop so it doesn’t depend on a feature I’d have to go turn on.
So on the Catalyst the loop does something different, and I think it matters not to blur the two. Every generated line is checked against an allowlist of permitted change types, which is default deny: a line nobody anticipated is refused because it was never allowed, not because someone remembered to ban it. Then against a denylist of things it must never touch, the management VLAN and the uplink and authentication and the rollback mechanism itself. Then against live read-only queries to the switch confirming the VLAN really is free and the interfaces really do exist.
What the approval text itself carries is the intent, the devices, the size of the diff, the risk, and the rollback plan. Not the config. I cap that message at 450 characters and a diff doesn’t fit in one, so the literal lines live in the audit record instead.
Different platforms give you different guarantees, and pretending otherwise is how people get surprised at 2 AM.
The part I’m most proud of is the failures
The first end-to-end runs in the lab did not go cleanly, and that turned out to be the most useful thing that happened. One run deployed, failed a post-check, and rolled itself back automatically. Another got rejected before it touched a device at all. A third passed everything and landed.
Later I had an AI agent deliberately sabotage a post-check on the real Catalyst to prove the rollback wasn’t theoretical. The change came straight back out, the resulting config was byte-for-byte identical to what it had been before, and a ping running through the whole exercise didn’t lose a packet. Worth being exact about which mechanism did that: the loop reverts immediately when a check fails, and the timer on the switch is the layer underneath, there to revert anyway if the loop itself dies mid-change.
The most useful thing in any of those records is something I wasn’t looking for. The lab run that reverted itself had re-encapsulated the link between the two devices, so I’d written a check to prove the existing point-to-point link across it kept forwarding. It passed while the change was live. After the revert, it failed. Maybe the link just needed longer to come back, maybe the revert left it down; the record doesn’t say, and that’s exactly the point. Putting the configuration back is not the same as knowing the network is back, and I’d much rather have found that in an audit file on a bench.
An automation system that can only show you its successes is a demo. One that fails safely, on purpose, in ways you can read about afterward in the audit trail, is something you can start to trust.
Approving changes from my phone
The approval gate runs over text message, which means the deploy button is my thumb, wherever I happen to be.
Everything that isn’t a clean yes is a no. A reply with the wrong change ID is ignored. A message from a number that isn’t mine is ignored. No reply inside the window and the change simply doesn’t ship. It respects quiet hours, so it won’t wake me up for something that can wait until morning. If it can’t even send the approval request, that counts as a denial rather than an excuse to proceed.
The gate fails closed in every direction I could think of, and then an AI critic went looking for the directions I hadn’t thought of.
An AI that gets audited, not one that grades itself
Every substantial build here now gets a second AI agent whose only job is to break the first one’s work: run it, probe the edges, attack the happy path.
On this build the critic earned its keep immediately. It found that two approval requests running at the same time could interfere with each other, which is now a documented constraint rather than a surprise. It also caught a subtler one: the text you receive claimed the config had been “validated in a dry run” even on the Cisco path, where, as above, the loop doesn’t do one. That’s exactly the kind of small dishonest phrase that erodes trust in a tool, and it came from the machine, not from me.
An AI that grades its own homework is not the same thing as one that gets audited.
Why I’m building this
Most network outages don’t come from hardware. They come from changes: rushed ones, undocumented ones, changes where the plan in someone’s head didn’t match the actual state of the network.
The goal isn’t to take the human out of the loop. It’s to shrink the human’s job down to the part a human is genuinely needed for, the judgment call, and to wrap that decision in validation, rollback timers, post-checks, and an audit trail that writes itself.
Two more things worth stating plainly. This runs in my lab and against one real switch on my bench, not across a production estate. And the planning step calls a cloud model today, which means the device and prefix inventory for the site goes out with the request, management addressing included. I have a local model prototyped and measured for that job precisely because not everyone will want the first answer, but prototyped is not shipped, and which one you’d want is your call rather than a default I get to pick for you.
Nothing about the pattern is lab-specific, though. Plan, prove, ask, deploy with a net, verify, document. That shape works for network changes, and it works just as well for plenty of business workflows that have nothing to do with networking.
Curious what this could look like for you?
If this sounds like the kind of automation you’ve wished existed for your own network or operations, careful, safety-first, and honest about its failures, I’d be glad to talk. You can see more of this work on the Loop, or get in touch and tell me what you’re trying to automate.
Corrections, added after publication. Five claims were wrong: four in the version I first posted, and one I introduced while fixing those. I found them by pointing a second AI agent at my own post with instructions to refute it against the actual run records, which is the same builder-and-critic pattern the post describes. In a piece arguing that automation should be honest about what it can prove, listing them seems like the minimum.
- I wrote that IOS-XE has no way to validate a config without applying it. It has one, a NETCONF candidate datastore, which happens to be switched off on this switch and which the loop doesn’t use. That is a narrower claim and the section above now makes it. The code comment that led me into this was wrong too, and is fixed.
- I wrote that the approval text shows the literal commands. It shows a summary and a line count. The literal lines are in the audit record.
- I then wrote that those lines are printed to the console. Under the text-approval gate they aren’t, only counts are. Audit record only.
- I wrote that nothing reaches a device without a human reply. The loop does read the live device before the gate, to check its plan against reality. Nothing is written without a reply, which is the claim I should have made.
- I wrote that the switch reverted itself on the timer during the sabotage test. The loop commanded the revert as soon as the check failed; the timer is the layer underneath it, for the case where the loop itself dies.