I just did a podcast with Pete Pizzatello over on The Broadband Bunch where we got into a bunch of stuff – the Lumen closed-loop story, NetClaw, spec-driven development, why I think there are no more excuses left for network engineers who haven’t touched AI yet. One moment from that conversation has been bouncing around in my head since we hit stop, and I want to extend it here because I don’t think I pushed it far enough on the mic.

The moment was about script sprawl.

If you did network automation anywhere between 2015 and 2023, you know the folder. Every team has it. It’s got John scripts. Pete scripts. A script_final.py. A script_final_v2.py. A script_final_REAL_FINAL.py. Most of them half-work. One of them is the only thing keeping a critical change window on the rails, and the person who wrote it left the company in 2021.

That’s DIY script sprawl. It happened because Python and Ansible made it just easy enough for every engineer to build their own thing – and just hard enough that nobody built a way to govern the sum of it.

On the podcast I said DIY is about to explode again. I stand by that. What I want to add – and what I didn’t say directly to Pete – is this:

A script does what you wrote it to do. That’s the limit. If it breaks, it breaks predictably.

An agent reasons. It picks a tool. It decides which device to log into, which workflow to call, which MCP to hit. The surface area of “what could go wrong” isn’t a function of the code anymore – it’s a function of what the agent decides to do in a moment you weren’t in the room for.

Now imagine that times ten engineers on your team. Each of them spinning up agents in Claude Code or Cursor or whatever IDE they opened this morning. Each of those agents has its own constitution (or no constitution). Its own set of MCPs plugged in. Its own idea of what “safe” means. Its own tribal knowledge that lives in one person’s head.

I already see this in the community. People are building remarkable agents. And when I ask how they’re governing them – who has access, what the guardrails are, what happens when the builder leaves – I mostly get a pause.

That pause is the problem.

Three things. Same three we needed in the script era. They just matter more now.

Governance. Someone has to be able to answer “what is this agent allowed to do, and who said so?” – in writing, with an audit trail. A soul file or a constitution on one engineer’s laptop isn’t governance. It’s a nice gesture.

RBAC. Your agent should inherit the same access controls your humans do. The junior engineer doesn’t get enable mode on day one. Neither should their agent. If you’re handing an LLM the keys because “it’s just calling our scripts,” you’ve already lost the thread.

Reuse. The FlowAgent I built last week shouldn’t have to be rebuilt by the person down the hall. Workflows I’ve already written – tested, approved, running in production – should be callable tools any agent on the team can reach. That’s not a productivity nice-to-have. That’s how you stop ten engineers from building ten slightly-different versions of the same agent.

If you’re a network engineer or automation lead reading this and thinking yeah, my team is probably already doing this – one ask:

Go find out. Ask your team how many agents they’ve built in the last 90 days. Ask where they live. Ask who else can run them. Ask what happens if that person is out sick.

If you want the full conversation with Pete – the Lumen story, how we’re thinking about guardrails, why I think the flow state matters – give the podcast a listen here or below. And come find me in the VibeOps Forum if you want to talk about what your team is running into. This is the kind of problem the community is better at solving together than anyone is alone.

Governed by design. Not by accident.