2026's Agent Sprawl Data

Ninety-seven percent of organizations say they're exploring agentic AI. Half of them rate their own capability as advanced or expert. Only twelve percent have a centralized platform to actually control what any of it is doing.

That's from a 2026 OutSystems survey of 1,900 IT leaders. A lot of organizations are confident about a category they currently can't govern, which is a strange kind of confidence to have.

The question everyone's asking is already answered (badly)

The question I have been mulling over for some time is a version of: do we let anyone within our company build an agent for their own use case, or do we route everything through one team that can actually keep track of it?

Both of those have already been tried, at scale, and both have a visible failure signature in the data. Flood gates produce agent sprawl and a body of pilots that mostly don't pay for themselves. A small centralized team produces a review queue that can't keep pace with demand, and a shadow-build problem that looks a lot like the one it was meant to prevent. I don't think there's much of a live debate left around either extreme. What's actually unresolved, and what the platform vendors seem to be converging on without quite saying it, is a narrower question: what specifically has to exist for a hybrid model to work, instead of quietly collapsing back into one of the other two.

What happens when you open the flood gates

The mechanics of sprawl are ordinary, which is what makes them easy to miss until the count gets large. A team has a real productivity goal, builds an agent to serve it, and does that in isolation from every other team doing the same thing. Nothing about that first decision is a mistake. The problem shows up in aggregate: agents that don't interoperate can't be audited on a common standard and accumulate access nobody remembers granting.

Gartner's 2026 projections put a number on where that's heading: the average Fortune 500 company running more than 150,000 AI agents by 2028, against a governance picture where only thirteen percent of organizations believe they have adequate controls for what they've already deployed. SAP's own research into this pattern, drawn from its LeanIX survey work, describes the same mechanism from the inside. Agents get built independently, each functional in isolation, until the organization loses the ability to say with confidence what exists or what it touches.

What worries me more than the governance gap itself is what it does to return on investment. MIT's Project NANDA published a widely cited 2025 study finding that ninety-five percent of enterprise generative AI pilots produce no measurable P&L impact, and traced the failure to integration and workflow fit rather than model quality. Read next to the sprawl numbers, I think those are two views of the same failure. An organization that can't see what it's built also can't tell which of those builds are actually earning their keep.

What happens when you gatekeep

I don't have a strong current dataset on the pure-centralized-bottleneck failure mode the way I do for sprawl. Most of what's published in 2026 is either vendor material describing a governance platform, or survey data on the sprawl side of the ledger. What follows is my own inference from that gap, and from a pattern that played out clearly enough a decade ago that it's worth calling out rather than pretending it's a fresh 2026 finding: this looks like citizen development and shadow IT, replayed with agents instead of low-code apps.

The mechanism is straightforward. A small team reviewing every agent request cannot scale its review capacity as fast as demand grows, because review is a human bottleneck and demand is not. Requests queue. Some business units wait. Others don't, and route around the process entirely, building on a personal account, a departmental budget, or whatever tool doesn't require the ticket. The organization ends up with something close to the sprawl and lack of visibility the centralized model was built to prevent, except now it's concentrated in the parts of the business too impatient to wait for approval, which are often the parts under the most competitive pressure to move.

I'd treat this as a well-supported analogy rather than a cited finding. As of now, I can't find a major platform vendor advocating pure centralization in 2026. They're all selling some version of the hybrid instead, which reads to me less like coincidence and more like a response to watching this exact failure mode play out already, once, in the last wave of internal tooling.

What the hybrid model actually requires

"Centralize the important parts, let teams build the rest" sounds like a real answer until you try to implement it, because it doesn't say which parts are the important ones or what "centralize" means in practice. I went looking at how the actual platforms are structured, Google's Gemini Enterprise Agent Platform, Microsoft's Agent Governance Toolkit, SAP's AI Agent Hub, Salesforce's Agentforce Operations, and kept seeing similar things they centralize: agent identity, some kind of registry, and a review gate.

The individual teams still own the agent's logic, prompts, use cases, and most of the actual build. What ends up centralized is the ability to answer four questions consistently across the whole organization: what exists, who owns it, what can it touch, and who signed off on that. I don't think a central AI team needs to approve how every prompt gets written. But somebody has to be able to answer those four questions about every agent in production, and once a dozen teams are each tracking their own answers their own way, "we track our own agents" stops meaning anything different from not tracking them at all.

BCG frames this as a control plane sitting above every platform an organization uses, and claims centralized governance built this way can cut agent deployment time from weeks to a day. That's a consulting firm's number, attached to a framework it's also selling, so I'd treat the specific multiple with some skepticism. The mechanism behind it seems more durable than the number: a golden-path template with the permission boundary, logging, and scope limits already built in removes the part of the review that used to require a person, the reviewer isn't deciding whether this agent's guardrails are adequate from scratch, they're confirming it used the approved template. Whether that's a 2x speedup or a 10x one, the structural logic holds either way.

A framework for deciding where your line actually sits

After going through the vendor architectures and the survey data, I think two variables explain most of the decision: how much regulatory or consequential exposure the agents in question carry, and how mature the organization's existing agent platform already is, meaning whether a registry, identity system, and reusable templates exist at all, not whether the org has "done a lot of AI." A third variable, request volume, doesn't change which quadrant an organization is in, but it changes how urgently the answer matters: high volume turns a bad-fit governance model into a visible bottleneck or a visible sprawl problem within months instead of years.

The failure mode in each quadrant is predictable. Low-maturity organizations that skip straight to self-serve land in the sprawl numbers. SAP's and Gartner's agent-count projections describe exactly this quadrant, chosen by default rather than on purpose. High-exposure organizations that never build past the centralized-bottleneck quadrant end up with the shadow-agent pattern citizen development produced a decade ago, for the same underlying reason: the approved path was slower than the business need.

My read of the OutSystems numbers, 36% claim some governance, only 12% have an actual platform, is that most organizations are sitting in the top-left or bottom-left quadrant and describing themselves as further right than they actually are. Advanced usage and advanced governance aren't the same claim, and the survey seems to be conflating them.

What we don't actually know

Almost everything cited above about what "top companies" are doing is vendor platform material: Google, Microsoft, SAP, and Salesforce each describing the control plane they're selling. That's real evidence of where the market is converging, but it's not the same as a named case study of how an actual company structured decision rights internally: who reports to whom, how a request gets triaged, how cost gets attributed back to a business unit.

Where to start if you're building this from nothing

This isn't a maturity checklist to complete over a year. The first two items are the actual precondition for the other four, nothing else here works without a registry and a tiered gate to attach it to.

Build the registry first. One system of record for what agents exist, who owns each one, what data and systems it touches, and when it was last reviewed. Something queryable. Every other item on this list depends on this existing.

Set a small number of review tiers, scaled to risk, not applied uniformly. Three tiers is usually enough: internal and read-only, internal and able to take action, and anything customer-facing or touching regulated data. Review effort should scale with the tier.

Give every agent its own identity and credentials. No shared API keys or service accounts across agents, even within the same team. This is what makes the registry's ownership field actually mean something, and what makes an incident traceable to one agent instead of an entire shared credential.

Build golden-path templates for the tiers you'll approve most often. A pre-approved starting point with scope limits, logging, and permission boundaries already built in turns the compliant option into the fast option. If the safe path is also the slow one, people find a way around it.

Attribute cost and usage back to the requesting team. Nobody builds a sustainable case for a governance program on stopped incidents alone. Being able to show which business unit is consuming what, and what it's costing, is what keeps the platform funded past the first budget cycle.

Put a decommission date on everything. Permissions accumulate and are almost never revoked on their own. An agent built for a six-month pilot that's still running two years later with its original access is a common way sprawl happens.

Stress-testing the framework: what happened at Replit

Most of what's cited above is vendor material describing a future state, or an inference about a failure mode I haven't seen documented directly. I wanted to test the framework against something concrete, and against an actual agent rather than a scoring algorithm, so I went looking for a real incident where an agent's access, or the lack of a boundary on it, was the entire story.

In July 2025, Jason Lemkin, founder of SaaStr, was running a multi-day trial of Replit's AI coding agent, building a small app using what's become known as "vibe coding." He'd put the project under an explicit code freeze, no changes without permission, part way through. On roughly day nine, the agent ran destructive commands against the live production database anyway, wiping records. Reports put the number somewhere between 1,200 and 2,400 executives and companies affected. When Lemkin asked about rolling it back, the agent told him recovery wasn't possible. That turned out to be false. Replit's CEO, Amjad Masad, later apologized publicly, called the incident unacceptable, restored the data, and the company shipped several fixes within days: separating dev and production databases by default, a planning-only mode, and a harder backup-restore path.

Run it through the framework and the incident maps onto almost every piece of it directly. There was no separate identity or credential scoping the agent's access to production versus a sandbox, so the code freeze existed only as a typed instruction, not as an enforced boundary the agent couldn't cross. There was no review gate on destructive database commands specifically, the kind of tiering this framework argues for would have put an action like that behind a stop, not behind a request to please not do it. And the agent's own account of what happened was wrong, which is its own governance problem: a registry and an audit log are only useful if what gets logged can be trusted, and self-reporting from the thing being audited is a weak source of truth.

The Replit incident is obviously a single case, but the failure mechanism is the part that matters here. An instruction told the agent not to touch production; the system itself didn't prevent it. At enterprise scale, that distinction becomes much harder to monitor, because the same permission problem can exist across thousands of independently built agents, each one relying on an instruction nobody's checking gets enforced.

The 97% number that opened this piece doesn't worry me nearly as much as the 12% number. Organizations are going to keep building agents regardless of how ready their governance is, that part isn't really in question anymore. What's actually in question is whether the infrastructure, identity, a registry, and a review gate that scales with risk gets built early enough that someone can still answer basic questions about what's running once the count moves from dozens to thousands. Centralizing everything doesn't solve that. The organizations that get this right seem to be the ones treating governance as infrastructure a team builds once, not a decision a committee makes every time.