Last recorded run, real Catalyst 9200: 7 of 7 checks passed
A network change starts as a text message in plain English. An AI plans it against your source of truth, vets every line it wrote, and then stops and asks you. Nothing is changed on a device without a human reply.
AI does the work. Engineers approve every change.
A request typed on a phone, planned by an AI, approved by a thumb, applied to a Cisco Catalyst 9200 with a rollback timer armed. One real run, with the long waits compressed and captions and narration laid over the top.
Left is the loop and the switch console. Right is the phone: the request going out, the approval coming back, the reply that deploys it. Nothing in either pane is a mockup.
The order is the whole design. Prove it before you ask, ask before you touch anything, arm the net before you commit, and check the things nobody thinks to check.
The request arrives in ordinary language. The agent reads current state from the source of truth first, which here is NetBox: what devices exist, which VLANs are taken, which prefixes are allocated. Then it drafts the smallest change that satisfies the request.
Output: a config diffEvery generated line is checked before a human is ever asked to look at it. What that check can promise depends on the platform, which is worth being precise about, so it has its own section below.
Output: pass or abortThe change stops here and texts a person. The message carries the intent, the devices, the size of the diff, the risk, and the rollback plan. A reply of Loop YES plus the change id is the only thing that lets it continue. Reading the device happens before this point, but nothing is written to it until that reply lands.
Output: a human decisionThe device takes a snapshot of itself, then applies the change with an auto-revert timer already armed. On the Catalyst that is a five minute absolute timer; on SR Linux it is a confirmed commit. If the next stage does not explicitly confirm, the device puts itself back with nobody watching.
Output: change applied, net armedPost-checks confirm both the thing that changed and the things that were supposed to stay the same. That second half matters more: the management plane is re-tested every time, because an automation that locks you out of the switch has failed even if its change was correct. Only then is the revert timer cancelled.
Output: pass list, timer cancelledThe source of truth is updated to match reality, and the audit trail is written: what was asked, who asked it, who approved it, when, and which checks proved it worked. The documentation is a product of the change rather than a chore that follows it.
Output: updated docs, audit recordThis is where automation writing usually goes vague. Different equipment gives you genuinely different guarantees, and blurring them is how people get surprised at two in the morning.
SR Linux will load a candidate config and validate it without committing. If the platform rejects the change, the loop stops and no change is ever attempted. That is a guarantee from the device, not from us.
IOS-XE has no CLI equivalent of commit validate. It can expose a NETCONF candidate datastore that would validate before committing, but that is switched off on this switch and the loop is built not to depend on it. So on the Catalyst it earns its confidence a different way, and says so rather than borrowing the word validated from the other platform.
An AI critic reviewing this build caught the approval text calling the Cisco path "validated in a dry run", copied from the platform where the loop actually does one. Small dishonest phrases are how a tool loses the benefit of the doubt, so it was corrected and written down. The same critic, pointed at this page before it went up, killed five claims on it outright and forced a rewording of a dozen more, nearly all of them against a record sitting in this repository.
The gate runs over text message, so the deploy button is a thumb, wherever that thumb happens to be. It was built to fail closed in every direction, and then a second AI agent went looking for the directions that had been missed.
Brody: change 6j5fm needs your approval. Intent: 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 Devices: C9200-DEMO. Diff: C9200-DEMO 40 lines. Risk: low. Config vetted against live state. Deploys with a 5 minute auto-revert timer unless 7 post-checks pass. Reply "Loop YES 6j5fm" to deploy or "Loop NO 6j5fm" to reject. Window 15 min.Brody
Loop YES 6j5fmDelivered
The first live run went out while nobody was near a phone. The window expired and the change did not ship, which is exactly the intended behaviour and better proof than a successful run.
On another run the reply came back with a typo. It was refused before it ever reached the gate, rather than being guessed at, and the loop waited for a clean one.
The early runs did not go cleanly, and that turned out to be the most useful thing that happened. Rollback that has never actually fired is a claim, not a feature.
An early lab run deployed, failed one of its own post-checks, and immediately reverted both devices with no human involved. Nobody planned that beat. It also left the most uncomfortable finding on this page. That change re-encapsulated the link between the two devices, and a check written specifically to prove the existing point-to-point link across it kept forwarding passed while the change was live. The same check failed after the revert. Whether the link simply needed longer to come back or the revert left it down, the record does not say, and that ambiguity is the finding: putting the configuration back is not the same as knowing the network is back.
Another run was killed at validation, before the approval request was even composed. The cheapest failure is the one that happens before a human is asked to make a decision about it.
An AI agent was told to sabotage a post-check on the live Catalyst so the rollback had to fire. The change came straight back out, the resulting config was byte-for-byte what it had been before, and a continuous ping through the whole exercise lost nothing. Two layers do that work: the loop reverts the moment a check fails, and the timer on the switch reverts anyway if the loop itself dies mid-change.
Working against live state instead of against a diagram means drift is sitting there to be seen. Two VLANs were active on the switch and absent from the source of truth. Nobody had gone looking for them, and reconciling that is its own piece of work rather than something the loop quietly fixes.
Every figure below comes off the recorded run or the runs that preceded it. Where there is not an honest number yet, there is no number.
Worth saying plainly, because the gap between a demo and an estate is where this category earns its scepticism.
The permitted set started as layer two: VLAN and switchport configuration, interface descriptions, port-level spanning-tree protection, and taking a port up or down. It has since grown two classes, each shipped the same way, with its own guardrails, its own checks, and its own adversarial review that tried to break it before it shipped. VLAN provisioning now runs end to end on the real switch with NetBox handing out the prefix, and it brings tightly scoped addressing with it: an SVI address and a DHCP scope that are legal only inside that class, with a hard refusal on anything that could reach the home network the bench sits on. A BGP-in-VRF class exists too, and it is honest to say it has only run against virtual lab targets so far, not the bench switch. Everything outside the permitted set is still refused because the allowlist is default deny, and one early looseness has been closed: spanning-tree was originally permitted as a whole family, wide enough to admit a priority change that moves a root bridge, and it is now narrowed to the port-level protections only.
This runs in a lab and against one real switch on a bench, not across a production estate. The pattern does not care about scale, but that claim has not been earned yet and will not be made here until it has.
One text-gated change at a time. Two approval requests in flight together could be confused for each other, so that is a documented constraint rather than something discovered later by a customer.
The step that turns a request into a config plan calls a cloud model today, and the device and prefix inventory for the site in question goes out with that request, management addressing included. Running the planner entirely on your own hardware has been prototyped and measured rather than shipped, so which of the two you want is a decision that belongs to you, not a default we picked. Nothing about the approval gate, the guardrails, or the rollback changes either way.
The goal is not to remove the human. It is to shrink the human's job to the part a human is genuinely needed for, and to wrap that decision in validation, a rollback timer, post-checks, and an audit trail that writes itself.
Thirty minutes on your network: which changes are repetitive enough to be worth a loop, which ones should never be automated, and what it would take to run the first one safely.