AI Sprawl Is the Fever, Not the Disease

Posted on July 18, 2026

0


Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™

When analysts reach for the word “sprawl,” it is not a new problem announcing itself. It is a fever — the first visible sign of an old one.

Gartner has named it, and named it well. The firm projects that the average Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025, and it calls the result agent sprawl: an uncontrolled accumulation of agents built by different teams without centralized governance or consistent oversight. Its own analysts report that only 13% of organizations believe they have the right governance in place to manage it. The symptom is real, the read on its scale is accurate, and the warning is warranted.

So let me be clear at the outset: on the symptom, Gartner is right.

But I have seen this fever before — and so has the record.

The word is the tell

In May 2010 I published a post with an odd title: “SaaS Sprawl, One-Stop Shopping and Free 8-Tracks To Boot: A Sad Day in the World of SAP.” SAP, confronting what the industry was then calling SaaS sprawl, had a plan: bring everything back under one architectural umbrella — “orchestration,” they called it. Consolidate the mess into a single suite and the sprawl goes away.

It did not go away. It could not, because sprawl was never the disease.

Look at the sequence the industry has actually lived through: ERP sprawl, SaaS sprawl, cloud sprawl, application sprawl, data sprawl, and now AI and agent sprawl. The technology in front of the word changes every few years. The word does not. When the same symptom attaches itself to every new technology in turn, it is not telling you something about the technology. It is telling you about something underneath all of them.

That is why the word is the tell. The moment the analysts reach for “sprawl” again, the fever has started — and the fever is the early sign of the same failure, wearing new technology.

What the fever is actually a sign of

Here is where I part company with the prevailing account, and the distinction is the whole point.

The reflexive response to sprawl is to treat it as a governance-capacity problem: too many agents, not enough oversight, so govern harder — more policy, more tooling, more centralized control. That is the dominant playbook, and it is treating the fever.

Sprawl is not an oversight gap. It is organizational fragmentation expressed through technology. Agents multiply across teams without coherence for the same reason spreadsheets, SaaS subscriptions, and cloud instances did before them: the operating model underneath was already fragmented, and each new technology simply gave that fragmentation a fresh surface to show up on. The agents are not the cause; they are where the underlying fragmentation becomes visible. Three teams stand up three agents against three readings of the same category, and now there are three conflicting recommendations and no single owner — not because the agents failed, but because the fragmentation they inherited was never resolved.

Govern the agents harder and you have lowered the temperature without touching the cause. The fragmentation is still there — waiting for the next technology to express it.

The treatment that keeps failing

There is a second thing the record shows, and Gartner’s own data confirms it in real time.

In 2010, the treatment for SaaS sprawl was consolidation: pull it back under one umbrella. It failed, because you cannot re-centralize your way out of a problem that was organizational to begin with. The market had already moved to distributed capability, and the snakes were not going back in the playpen.

In 2026 the reflex is the same in a new form: govern the sprawl, restrict the agents, bring them under central control. And here is the part worth sitting with — Gartner found that when organizations respond by blocking agents, employees turn to shadow AI instead. The control-first treatment does not cure the fever. It drives the infection underground, where it is more dangerous and harder to see. By the firm’s own finding, treating the symptom makes the disease worse.

That is the same medicine that failed in 2010, prescribed again — and it will fail again, for the same reason. You cannot govern, consolidate, or tool your way out of a fragmentation you have not addressed.

The cure has not changed either

If the fever is old, so is the cure — and it is not complicated to state, only hard to do, which is why it keeps being skipped.

You address the operating reality before you scale the technology on top of it. You establish whether the operating model is coherent enough to deserve to be extended — by agents, or by anything else — before you extend it. Understand the reality, align the stakeholders and the processes, and introduce the technology last, into a structure that can actually absorb it. Do that, and sprawl largely does not occur, because the technology is following a coherent operating structure rather than being asked to invent one.

That is not a new prescription. The answer I arrived at in 1998 was not developed in response to AI sprawl, or SaaS sprawl, or any of the labels in between. It was developed to address the organizational conditions that make every technology wave susceptible to fragmentation in the first place. The terminology changed over the decades. The underlying implementation problem did not.

Today’s Takeaway

Gartner has correctly taken the organization’s temperature. The number — 150,000 agents against 13% readiness — is a real fever, and companies that wave it off are in for a hard stretch. But the temperature is not the illness, and the treatment on offer is the one that has failed each time it has been tried, because it treats the symptom the technology presents rather than the fragmentation the organization carries.

So when you next hear an analyst say “sprawl,” treat the word exactly as you would a fever. Do not reach first for something that suppresses the symptom. Ask what the body is actually fighting — and whether anyone has been willing to treat that instead.

You can debate whether a model is right. You cannot debate the dated record it was built on.


This analysis draws on the Procurement Insights archive — an independent record, carrying zero vendor sponsorships, that I have published openly since 2007 and that consolidates documented client work, lectures, and writing reaching back to 1998. Every claim in it is held to the Provenance Ledger™: a verify-before-publish discipline that traces each assertion to a primary source and never quietly edits the record once it is posted. That record is the evidence base for two working lenses — Invariant Physics™, the constant that however far the technology advances, the operating logic must be in place first; and Implementation Physics™, its per-engagement application: the discipline of doing the readiness work before the platform, not after. Getting it right, rather than being right.

-30-

Posted in: Commentary