The Agent Sprawl Problem Is Already Here

Agent sprawl rarely begins as a big architectural failure.

It starts with a team solving a real problem.

One group builds an agent to triage support tickets. Another experiments with a finance close workflow. A third connects a tool to a knowledge base. Someone in operations automates a recurring report. Each one is useful. Each one has a reasonable business case. Each one probably feels small enough to manage locally.

Then the questions start.

Who owns the agent after the demo?

What systems can it touch?

Where are the credentials stored?

Can it change records or only recommend changes?

What happens when it gets stuck in a loop?

Can security reconstruct what happened?

Who has the authority to shut it off?

If the answer to those questions is different for every deployment, you do not have an agent strategy. You have a collection of local automations with enterprise expectations attached to them.

That is how agent sprawl becomes a shadow operating model.

For the last two years, enterprise AI has mostly been framed as a model race. GPT versus Claude. Gemini versus open source. Better reasoning. Longer context. Lower cost. Faster inference. All of that still matters, but I think the framing is starting to age.

The next enterprise AI fight is not only about which model gives the best answer. It is about who controls the environment where agents act.

That is the part that should have every CIO's attention.

VentureBeat published a useful piece this week arguing that Claude's next enterprise battle may not be the model layer at all. It may be the agent control plane: the layer where agents plan, call tools, access data, run workflows, and prove to security teams that they did not do something they were not supposed to do.

That line of thinking lands with me because it matches what I keep seeing in the real world. Organizations are not short on agent ideas. They are short on the operating model that lets those agents become useful without creating a mess.

A Model Is Easier To Swap Than A Runtime

One of the most important points in the VentureBeat piece is easy to miss: a model is relatively easy to swap. An agent runtime is not.

In theory, a company can route one workload to Claude, another to GPT, another to Gemini, and another to a smaller specialized model. That does not mean the work is trivial, but the model call is only one layer of the system.

The runtime is different.

Once workflows, tool permissions, memory, logs, credentials, sandboxes, approvals, and monitoring live inside a provider's environment, switching becomes much harder. You are no longer changing the brain. You are changing the room the brain works in, the tools it can pick up, the doors it can open, and the logbook that explains what happened.

That is infrastructure.

This is why I think CIOs should be careful about treating agent platforms as just another product decision. The more an agent can do, the more the surrounding environment matters. Convenience is valuable, but convenience can also become dependency if the enterprise does not understand where the control boundaries are.

Security Is Becoming The Buying Criterion

The numbers in the VentureBeat article were telling. Its VB Pulse tracker showed security and permissions as the top selection criterion for agent orchestration platforms in January and February. Control over agent execution rose, while flexibility across models and tools declined.

That shift makes sense.

When AI was mostly answering questions, leaders could afford to over-index on capability. Which model writes better? Which model reasons better? Which model handles longer context?

When AI starts taking action, the buying criteria change.

An agent that can send email, modify a ticket, query a database, generate code, update a customer record, or trigger a workflow has a very different blast radius than a chatbot. The question is not just whether it is smart enough. The question is whether the organization can govern what it does.

That requires identity. It requires permissions. It requires audit trails. It requires observability. It requires revocation. It requires a plain-English understanding of who is accountable when the agent does something unexpected.

Most organizations are comfortable talking about "guardrails." Fewer have translated that word into actual operating mechanisms.

Guardrails are not a slide. They are the approval step, the access policy, the escalation path, the log, the test harness, the monitoring rule, and the kill switch.

MCP Helps, But It Does Not Solve Control

The rise of the Model Context Protocol, or MCP, is part of why this conversation matters. Anthropic introduced MCP as an open standard for connecting AI applications to external systems, and that is a big deal. Open standards reduce integration friction and make it easier for agents to reach the systems where work actually happens.

That is the opportunity.

It is also the risk.

The easier it becomes to connect agents to tools, the more important it becomes to govern what those agents are allowed to do once they get there.

An open protocol can help with interoperability. It does not automatically solve identity, policy, approval, logging, runtime behavior, or organizational accountability. An enterprise can use open standards and still end up locked into a managed runtime if that is where the sessions, sandboxes, logs, credentials, and workflow state live.

This is the distinction I think leaders need to get clear on: openness at the connection layer is not the same thing as control at the operating layer.

Both matter.

The CIO Problem Is Not Picking A Winner

It is tempting to turn this into a vendor horse race. Microsoft has the distribution advantage. OpenAI has strong developer momentum. Anthropic is clearly moving beyond the model into managed agents. Other platforms will keep emerging.

Those dynamics matter, but the CIO's job is not to pick a winner in May 2026 and hope the architecture ages well.

The CIO's problem is building an environment where the organization can use multiple models, tools, and agent frameworks without fragmenting governance every time a team tries something new.

That means the practical work underneath the vendor conversation matters more than the vendor conversation itself: identity, permissions, approvals, logging, testing, monitoring, escalation, and revocation.

Those are not theoretical concerns. They are the difference between agent adoption and agent sprawl.

Start Where The Work Is Already Real

I do not think the answer is a grand agent strategy deck, and I do not think the answer is pretending every team has to stop experimenting until the enterprise architecture is perfect. Useful technology rarely arrives that neatly. Most of the time, the first signs of agent sprawl show up because a capable team found a real problem, moved quickly, and filled in the gaps the organization had not solved yet.

That is why I would start with the workflow that is already closest to real work, especially if you would be uncomfortable explaining its control model out loud. Not because someone did something wrong. Usually it is the opposite. That workflow is valuable because it is close enough to operations to expose where the operating model is thin.

Then trace it like an incident review before the incident. What does the agent read? What can it change? Whose credentials does it use? What happens when it is uncertain? What log would you trust three months later? Who gets the phone call if it goes sideways?

The value of that exercise is not the spreadsheet. It is the moment when everyone realizes how much of the control model is still living in people's heads.

That is the part to fix: not by shutting everything down, but by turning the implicit decisions into explicit operating rules and reusing those rules the next time a team wants to build something useful. The fifth agent should not require the same governance debate as the first one, but it should benefit from what the first one taught you.

That is why the control plane matters.

Not because CIOs need another platform to manage. Because without a shared way to govern agent execution, every successful pilot creates the conditions for the next operational mess.

The model race is not over. But for enterprise leaders, the more important question may be the one underneath it: who controls the work when AI stops just talking and starts doing?

---

Jared Mabry is SVP and CIO at D4C Dental Brands and co-founder of ClearPoint Logic. He writes about the intersection of technology leadership, enterprise AI, and operating model design.