Shared AI Agents: How to Prevent Agent Sprawl
7 min read

Shared AI Agents: How to Prevent Agent Sprawl

Why the number of agents you run is the wrong measure, and what to consolidate instead.
Shared AI agents: how to prevent agent sprawl - AI Partners

Gartner expects the average Fortune 500 company to be running more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. Most of the advice that follows that number is about counting them: build an inventory, assign identities, track what exists.

Counting is necessary. It is also the easy half. The harder question is how many agents a company should have in the first place, and the answer is usually far fewer than it ends up with.

What is AI agent sprawl?

AI agent sprawl is the uncontrolled accumulation of agents built by different teams without shared ownership or oversight. It happens because building an agent now takes minutes, while agreeing on who owns it takes weeks.

The scale of the shift is what makes it new. Going from fewer than 15 agents to six figures in three years is not a bigger version of software asset management, because nobody approved most of those agents and no procurement process saw them.

Gartner's framing is risk-led: an ungoverned population of agents exposes a company to misinformation, oversharing and data loss, and only 13% of organisations believe they have the right governance in place. The cost and value problem sits alongside that one, and gets less attention.

What causes AI agent sprawl?

Three things, and none of them is carelessness.

The first is that the cost of building collapsed while the cost of agreeing did not. A competent person can produce a working agent in an afternoon. Getting a named owner, a data access review and a maintenance plan agreed often takes weeks. People do the first and skip the second, rationally.

The second is that agents arrive through several doors at once. Your platform vendor ships them, your CRM adds them at a higher tier, individual teams build their own, and none of those three routes goes through the same approval. An organisation can acquire hundreds of agents without a single procurement decision.

The third is that nothing retires them. An agent built for a campaign that ended, by someone who has since changed role, keeps its permissions and its data access until somebody removes them. Software gets decommissioned because somebody pays for a licence. Agents often cost nothing visible to leave running.

Why counting your agents measures the wrong thing

Plenty of companies report their AI progress as a number of agents created. That number goes up on its own, and it says nothing about whether anyone uses them or whether they produce anything.

A thousand agents can mean a thousand people each solved their own problem once and moved on. Ten agents can mean ten processes genuinely changed. The count does not distinguish between the two, so it rewards the version that looks busiest.

What to track instead: how much of your agent usage and spend sits on the handful of agents you would defend in a meeting. That ratio tells you whether you have a capability or a pile, and it moves in the right direction when you consolidate rather than when you build.

How shared agents prevent sprawl

A shared agent is configured once, owned by a team, and used by everyone who needs that job done. A personal agent is configured by one person for one situation, and it is invisible the moment they stop using it.

The practical difference shows up in four places.

  • You can see who uses what. Usage concentrated on named agents tells you which use cases matter. Usage scattered across hundreds of private agents tells you nothing.
  • Changes happen once. Moving a use case to a cheaper or better model is one configuration change on a shared agent, against dozens of edits nobody will make.
  • Good practice spreads. Companies have spent years standardising how work gets done. Agents built privately undo that quietly, because each person encodes their own version of how to qualify a lead or run a review.
  • Teams can borrow each other's expertise. A sales team calling the data team's agent gets the data team's definitions. A sales team writing its own queries gets its own mistakes.

Concentration is what makes the rest of the governance work possible. Four or five agents carrying most of the value can be reviewed properly. Four hundred cannot, however good the policy says they are.

What does Gartner recommend to manage AI agent sprawl?

Gartner's guidance runs in six steps, and it is worth knowing before you design anything of your own.

  • Establish agent governance and policies. Set clear rules for when and how agents are built, who can create and share them, and which connectors are permitted.
  • Build a centralised agent inventory. Discover and categorise agents across applications, whether they come from sanctioned tools or from shadow AI, then apply controls in proportion to the risk each agent presents.
  • Define agent identity, permissions and life cycle. Manage each agent's identity and access controls, and keep reviewing and retiring redundant agents.
  • Develop AI information governance. Control what information agents can reach, keep that data current, manage permissions to prevent oversharing, and archive what is obsolete.
  • Monitor and remediate agent behaviour. Keep ongoing visibility into usage, check policy compliance, detect anomalous behaviour and correct agents that exceed their intended scope.
  • Foster a culture of responsible AI usage through training programmes and a community of practice.

Gartner is also clear about what not to do. Blocking or restricting agents is not a long-term solution, because employees without sanctioned tools tend to go around the controls and turn to shadow AI, meaning tools used outside what the company has approved, which carries far greater risks.

Step three already includes retiring redundant agents. The practical question it leaves open is which ones to keep, and a well-run inventory of four hundred near-identical agents is still four hundred agents. So treat discovery as the start of a consolidation exercise: for each entry, ask whether the work belongs on a shared agent someone already maintains.

How to decide which agents to keep

Three tests, applied to the list the inventory produces.

Does more than one person use it? An agent with a single user is a personal tool. That is fine, and it should not sit in the same category as the agents a function depends on, nor carry the same review burden.

Does it duplicate something that exists? Near-duplicates are an easy win to look for first. Merging them removes work rather than adding governance, which is the only move in this whole exercise that makes the list shorter.

Would anyone notice if it stopped? Agents outlive the person who built them and the reason they were built. Pausing one for a fortnight, with its users warned, and seeing who objects is faster than any assessment.

The exercise can also surface agents nobody approved, such as a personal project running on company access and company budget. Usage visibility is what makes those findable.

How to stop sprawl before it starts

Decide who may build and share agents, and on what platform, before the next wave of tools arrives. That is Gartner's first step, and in our view the only one that prevents work rather than cleaning it up.

Give teams a default place to look before they build. When someone can find an existing agent for their job in thirty seconds, most people use it. When they cannot, they build, and the registry gains another entry.

And treat this as a training problem alongside a governance one. Gartner's sixth step is a culture of responsible use, built through training and a community of practice. People who know what a good agent looks like are less likely to build redundant ones, and rules that only restrict push people towards shadow AI, as Gartner itself notes.

Frequently asked questions

How many AI agents should a company have?
Fewer than it will end up with by default. The useful measure is what share of usage sits on agents a team owns and maintains, rather than the total count.

Is agent sprawl the same as shadow AI?
They overlap. Shadow AI is use of tools outside sanctioned channels. Sprawl includes agents built on approved platforms by approved people, which is why an approved-tools policy alone does not prevent it.

Who should own the agent inventory?
IT or security should run the discovery, and the business should own the decisions about what to keep. Discovery is a technical job, consolidation is not.

Does consolidating agents slow teams down?
Only if consolidation means blocking or approval queues, which Gartner warns pushes people towards shadow AI. Giving teams a maintained agent that already does the job is faster than letting them build their own.

Most companies discover their sprawl at the worst moment, in a security review or a budget overrun. Mapping what you run and consolidating it onto agents worth maintaining is part of our AI Factory work. Book 30 minutes to talk through what you have.