What's the real challenge? Automating a test network with three cleanly documented devices isn't hard. A real customer network with equipment from different generations, different procurement cycles, and different vendors (Cisco, Nokia, HP, and whatever else is out there), with workarounds that piled up over the years and several teams making changes at the same time, is a different matter entirely. That's exactly where our conceptual work on neops has focused over the past months. We asked what fundamental principles actually make automation trustworthy in an environment like this.

A concrete example that works even without code. Picture two teams touching the same device at the same time, not unusual when monitoring automation, ticketing workflows, and people are all accessing the same infrastructure in parallel. Team A wants to activate port 1, team B wants to activate port 2. Both read the current state first, then both write their change back.

In practice, this exact scenario is the exception. What does hold true for most networks, though, is that every additional layer of automation raises not just the speed but also the number of actors operating on the network at once. Without a shared safety model, more automation can therefore lead to less control, of all things.

Back to our example: if both scripts write based on the same, by-then outdated state, team A's change can quietly disappear again, overwritten by team B, without anyone seeing an error. The device doesn't report a fault. It simply does something different than both teams assumed. In a network that has grown over years with many actors working at once, that's not some exotic edge case. It's a structural risk, and it gets more likely with every additional layer of automation.

There's another problem: even when an operation technically runs through fine, it's often unclear what actually happened if something did fail. Were changes made to the network, or was it just a status check? Was an aborted workflow rolled back completely? Could it even be rolled back, or was the affected step impossible to undo in the first place? Most homegrown script collections only have one state for "something went wrong," regardless of whether anything was actually changed or not.

The answer to both problems, the one presented in Bern, is this: treat network changes like database transactions. Every change gets a clearly defined scope, exclusive access to the context it touches, and, this is really the key point, a clean distinction between two kinds of failure: a safe failure, where nothing was touched yet or the rollback demonstrably worked and there's nothing left to do, and an unsafe failure, where someone actually has to look at it. For an ops team getting paged at two in the morning, that's the difference between "can wait until tomorrow" and "escalate now," a distinction most homegrown script collections can't make today.

The second part of the story, and honestly the more remarkable one for us. For AutoCon 5 in Munich, Leandro Lerena developed these ideas further into four connected "Paradigms of Trust," explicitly building the bridge to the next big topic: how do you give AI agents controlled, safe access to network infrastructure without "agent" turning into "uncontrolled blind access to production devices"? What's notable is that these Paradigms of Trust apply to any form of future-proof network automation. That this also makes it agent-ready is a welcome side effect (we'll introduce the Paradigms of Trust and the technical deep dive next week).

What made it especially good for us as the neops team was the setting it happened in: this was our very first submission to AutoCon ever, and it was accepted straight into the main program as a lightning talk. AutoCon positions itself explicitly as the counterpoint to vendor marketing, with a lineup that, in the same edition, included speakers from DE-CIX, LINX, and GÉANT, alongside established voices in the field like Ivan Pepelnjak and Eric Chou.

In concrete terms: we take AutoCon accepting the talk into the main program as an encouraging outside signal. It suggests the paradigms we're working on are fairly closely aligned with what the industry is actually dealing with right now.

What this means for our customers

• Less risk on network changes in complex, long-grown environments. Not through more caution, but through a model that classifies failure cases cleanly instead of lumping them together.
• Traceability when it counts: every operation can be reconstructed (who, what, with what intent).
• An architecture where the next step, controlled use of AI agents in automation, doesn't need to be bolted on later. It's carried by the same principles that already secure human and automated changes today.

‍

Videos

• Leandro's talk at AutoCon 5 – Munich (video, YouTube)
• Leandro & Andy's talk at SwiNOG #41 – Bern (video, YouTube)

‍