The growth of enterprise AI agent platforms has made it much easier for employees to build and deploy agents to support their own work.
But as agent creation becomes more decentralized, enterprises face a new management problem: how to keep track of what agents have been built across the organization. Without that visibility, teams can struggle to find and reuse existing agents, while access to enterprise data and systems can become harder to govern. When this proliferation of agents becomes too difficult to manage, it becomes agent sprawl.
In this article, we’ll explain why proliferation isn’t inherently bad, explore how enterprises tend to manage agent sprawl, and consider an alternative approach that allows variant agents to compete.
Build reusable agents and automations and share them across the enterprise with North 2: our secure, agentic AI platform that runs where your data lives.
Why agent proliferation isn’t necessarily a bad thing
The same tools that create the potential for agent sprawl also make experimentation much easier. Employees no longer need to rely exclusively on a central AI or engineering team every time they identify a task that could benefit from an agent. Instead, they can build and test agents themselves, tailored to the specifics of the work they’re trying to augment.
This kind of decentralized experimentation is valuable. First, those closest to a workflow are often best placed to determine how it could be streamlined by an agent. Second, when useful agents can be shared and reused, a solution initially developed for one team can be adopted by other teams facing a similar problem. So at an organizational level, proliferation can be a sign that employees are actively testing new ideas and discovering useful applications for agents.
This raises the question of whether having a growing number of agents always creates more overhead. After all, more agents don’t necessarily mean higher inference costs — an agent that isn’t being used doesn’t consume tokens simply because it exists. Instead, the management burden appears when the process for managing agents fails to keep pace with their growing numbers. That’s when agent proliferation is better described as agent sprawl.
Proliferation can be a sign that employees are actively testing new ideas and discovering useful applications for agents.
How enterprises currently manage agent sprawl
Enterprises today typically manage growing agent estates with one of the following approaches:
- Centralized delivery: A central AI or engineering team builds and governs agents for the rest of the organization. This can offer tighter control, but can limit the pace of innovation.
- Federated delivery: Business units or individual teams own agent development and operation, while central functions provide shared infrastructure, standards, and governance patterns.
- Hybrid delivery: Central and business teams share responsibility for building and operating agents under common standards and governance patterns.
Across these operating models, enterprises are increasingly using agent registries to maintain a shared view of their agent estates. A registry helps an organization keep track of agent ownership, usage, and access permissions, while helping employees discover agents that already exist. This setup reinforces a common preference for avoiding duplication. Teams should default to reusing existing solutions before building something new.
Of course, there are good reasons to limit unnecessary duplication. It’s an obvious way to reduce sprawl: employees have fewer overlapping options to sift through, while the enterprise has fewer agents to monitor and govern.
But treating duplication as something to avoid in every case can also suppress innovation. If the mere existence of a workable agent means no alternatives should be built, organizations forfeit the opportunity to discover solutions that are cheaper, more reliable, or better suited to the task.
Treating duplication as something to avoid in every case can suppress innovation.
An alternative approach: Allow agent variants to compete
How can enterprises make room for useful duplication without letting it develop into agent sprawl?
One way is to treat duplication as provisional rather than permanent. If a team has a credible reason to believe it can improve on an “incumbent” agent, it should be permitted to build a “challenger” variant. However, the continued use of the challenger should depend on whether it demonstrates a meaningful advantage over the incumbent.
This competitive model requires a time-bounded, evidence-based comparison between the incumbent and challenger. Specific metrics will depend on the use case, but could include measures such as reliability, token use, and latency, as well as task performance.
Once enough evidence has been collected to make a meaningful comparison, the organization can decide whether the challenger should replace the incumbent or be retired. If the challenger proves better suited to a part of the incumbent’s workload, both agents might remain as distinct alternatives.
For example, consider a bank’s commercial lending division, where a central team has built a finance agent that drafts credit memos for relationship managers. A lending team that handles routine annual reviews believes it can do better, so it builds a challenger designed for the same range of tasks using a smaller, cheaper model and an additional step that cross-checks financial figures against supporting documents.
For 30 days, both agents draft memos for a representative set of cases, from routine annual reviews to more complex financing cases. The bank compares them on four measures: how many figures trace correctly to their source documents, how heavily credit officers edit each draft, token cost per memo, and time to first draft.
If the challenger delivers comparable quality across the different types of work at a substantially lower cost, it replaces the incumbent. If it falls short without offering any meaningful advantage, it’s retired. And if it wins on routine annual reviews but struggles with complex new financings, both agents stay — each assigned to the work it handles best.
It’s therefore necessary to tolerate some duplication for this approach to work, but only insofar as that duplication creates useful competition. Once testing reveals that one competing agent offers no advantage over the other, there’s no reason for both to remain.
Final thoughts
Avoiding agent sprawl does not require eliminating duplication altogether.
Some duplication — or variation — is necessary if enterprises want to compare competing approaches.
The key is to pair variation with selection pressure. By making agent creation easy but persistence conditional, enterprises can preserve the benefits of continuous experimentation without sliding into sprawl.
