Agent Sprawl: How an Enterprise Ends Up With 850 Agents and a Dozen in Use

Agent Sprawl: How an Enterprise Ends Up With 850 Agents and a Dozen in Use

An IT leader at a large enterprise described building roughly 850 agents. The number was offered as an achievement, then immediately qualified: hardly any of them are being used.

That second half is the part worth studying, because it is not a story about wasted effort. Every one of those agents was built by someone solving a real problem. The failure happened afterwards, in the space between building an agent and running one, and almost nobody plans for that space because until recently it didn't exist.

Sprawl is usually described as a volume problem. It isn't. An enterprise can run thousands of agents perfectly well if it knows what they are. The problem is orphans.

Four mechanics that produce sprawl

None of these involves anyone behaving badly, which is why the pattern repeats across organisations with very different cultures.

The builder is not the owner. Someone in finance builds an agent to solve their own weekly annoyance. It works, so a colleague starts using it too. At no point does anyone decide that this person is now responsible for a piece of production software, and at no point do they agree to be. The agent has a creator and a user base, and no owner.

Creation is cheap and deletion is expensive. Building takes an afternoon. Switching something off requires knowing what depends on it, which requires records nobody kept. So agents accumulate the way browser tabs do — each one individually justified, collectively unmanageable.

The metric is agents built. When a programme reports progress as the number of agents deployed, it will produce agents. It will not produce adoption, because adoption isn't what is being counted.

Nobody can see the whole. Agents get built in a productivity platform, a system of record, a data tool and someone's engineering stack. Each environment has its own admin view. None of them has the others'. The absence of a single register isn't a gap in tooling so much as a gap in whose job it is.

Recent security research puts numbers to the consequence: among large-enterprise security leaders surveyed, the overwhelming majority reported lacking full visibility into their AI identities, while a large share confirmed those systems could reach core platforms like ERP, CRM and finance. Reach is high, visibility is low, and those two facts are what makes sprawl a risk rather than an untidiness.

Why most of them go unused

Sprawl explains why agents accumulate. It doesn't explain why they sit idle, and the reasons are different.

Most unused agents are one-step helpers. They summarise a document, draft a reply, look something up. Useful, but they don't remove a process, so nobody's day changes and the habit never forms. An agent that saves ninety seconds competes with the effort of remembering it exists.

Some are undiscoverable. Built in one team's environment, mentioned in one Teams channel, never surfaced anywhere a colleague would look. The agent works perfectly and has an audience of four.

Some failed once. Agents get a single chance with most users. Answer confidently and wrongly on a Tuesday and that person will not return in March, regardless of how much better the agent got in between.

And many have rotted quietly. The agent is fine; the content beneath it aged. A policy changed, a document moved, an owner left. Nobody was watching quality because nobody was watching anything, and the agent kept answering from a source that stopped being true.

Finding what is already running

Before deciding anything, produce the list. This takes a week or two and is almost always the most surprising exercise a programme runs.

Start with the admin surfaces you already have. Each platform where agents can be built has a view of what exists in it — environments, publishers, connectors used. Pull all of them and stop treating each as its own universe.

Then work from identity. Every agent that touches a system holds credentials, so your IAM and service-account records contain evidence of agents even when the agent itself isn't catalogued anywhere. Non-human identities that authenticate on a schedule and were created in the last two years are a good place to start looking.

Then follow the money. Consumption charges, API keys and departmental spend all leave marks. An agent nobody remembers building still shows up on a bill.

Then ask people, which finds the ones the first three methods miss. Not "have you built any agents", which gets a no, but "is there anything automated that you rely on, that you'd be annoyed to lose". That question finds shadow work.

For each thing you find, capture five fields and no more: what it does, who built it, who uses it, what it can reach, and whether anyone is responsible for it. A short register that exists beats a comprehensive one that doesn't.

Triage what you find

Four buckets, and the goal is to empty two of them.

In use, owned, scoped. Leave alone. Confirm the owner is still in the role.

In use, no owner. The dangerous bucket, because these are load-bearing. Assign an owner before touching anything else, and check what credentials it is using — this is where inherited permissions from departed employees turn up.

Built, not used. Retire. This will be the largest bucket by a wide margin, and clearing it is the fastest risk reduction available to you. Expect resistance, because someone built each one. The reasonable compromise is a defined dormancy period rather than a permanent maybe.

Unknown scope. Quarantine until someone can say what it reaches. An agent whose permissions nobody can describe is not a candidate for a decision yet.

Deleting agents is progress, and it is worth saying that out loud in a programme that has been rewarded for creating them.

Everyone is rewarded for building. Nobody is rewarded for stopping.

It is worth being clear about why the "built, not used" bucket gets so large, because it isn't carelessness.

Creating an agent is rewarding for every party involved. The person who builds one has something to show for their week. The platform team gets an adoption figure. The vendor gets consumption. The sponsor gets a slide with a number on it that goes up. Retiring an agent rewards nobody: it makes a number smaller, and whoever switches it off inherits the risk of having broken something nobody documented.

An organisation where creation is celebrated and retirement is unowned isn't having an accident. It is running a machine that works exactly as built.

The counterweight has started arriving from an unexpected direction. CFOs are asking what AI spend is producing — what is being spent, where, by whom, and what changed as a result. That is the first incentive in this story pointing the other way, and it is more useful to an agent programme than it first appears.

Idle agents are not free. They draw execution credits or tokens whenever they run at all, they occupy licensed environments, they store context and logs, and they absorb review time every time a security question comes round. None of it is dramatic. All of it recurs.

Attribution is the harder half. If you cannot say which agent produced which outcome, you cannot separate the ones earning their keep from the ones idling — and neither can the CFO. What follows is predictable: the budget gets trimmed horizontally instead of pruned selectively, and the agents that were working take the same cut as the ones nobody opened. Programmes of this kind rarely die of failure. They die of being illegible at budget time.

What stops it happening again

The recurrence problem is a governance problem rather than a cleanup problem, and it comes down to a single rule applied at creation: nothing runs without a named owner. Everything else — identity, monitoring, evidence — follows from having someone accountable in the first place.

The other change is what you report, because the incentive only flips when the scoreboard does. Swap agent count for two numbers: how many agents are in active use, and what process each one removed. Both are harder to produce than a count. That is the point. A programme that can answer them has a portfolio, and can defend it to a CFO. One that can only produce a count has an inventory, and inventories don't generate value.

None of this gets smaller

One caution against reading any of this as an argument for fewer agents.

The number is going up. An organisation with fifty genuinely useful agents today will plausibly be running several hundred next year, and nobody should claim to know what 2028 looks like. That growth is real, it is coming, and it is the right direction: the agents worth having are the ones that remove work, and there is a great deal of work left to remove.

Which is precisely the argument for doing this now. At fifty agents, a disorganised estate is a fortnight of catching up. At four hundred, effort no longer solves it, because the rate of creation outruns the rate at which anyone can investigate what already exists. Ownership, identity and a register are cheap to install while the number is small and expensive to impose afterwards — and the number is only small once.

The test

Ask for a list of every agent running in your organisation, with an owner against each one, by the end of the week.

The list you get back is your actual agent programme. Whatever isn't on it has been running without anyone's attention — and the reason to find it now is that the alternative is finding out during an incident, when the question comes from someone who is not asking out of curiosity.