Why Agent Sprawl Is the Next Script Sprawl

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.

We’ve Seen This Movie Before

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 from turning into a Sunday morning incident.

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:

Agent sprawl is coming. And it’s going to be worse than script sprawl.

Why Agents Amplify the Problem

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 idea of who it’s supposed to listen to.

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.

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.

What a Platform Actually Solves

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 plot.

Reuse. The FlowAgent I built last week shouldn’t have to be rebuilt by the person down the hall. Workflows I’ve already written – deterministic, tested, governed – should be invokable as tools by any agent on the team. That’s the difference between a discipline and a hobby.

This is why I’m at Itential. Not because agents are magic – I build agents every day, I know exactly how much duct tape is in them – but because the agent era needs the same kind of platform layer the script era never got, and the cost of not having one will hit operations teams much faster this time.

What To Do This Week

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 the answers are fuzzy, you’ve got agent sprawl. It’s not a someday problem. It’s a right-now problem, and it’s cheaper to solve it before you have fifty agents than after.

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.

Governed by design. Not by accident.