AI Agent Sprawl: thousands of AI agents in a short time

For some time, the discussion about artificial intelligence agents focused on finding where they could be used. Companies tried out use cases, created pilots, and started embedding agents into the platforms they already used. Now, as these experiences move into production, a problem of a different nature appears: the number of agents can grow much faster than the ability to manage them.

Gartner projects a change that is hard to ignore. In an average global Fortune 500 company, the number of agents in use could go from fewer than 15 in 2025 to more than 150,000 in 2028 [1]. It does not mean every company will have 150,000 agents two years from now, but it indicates the scale this population can reach in larger organizations.

An average global Fortune 500 company could go from fewer than 15 AI agents in 2025 to more than 150,000 in 2028. Yet only 13% of organizations believe they have adequate governance for agents today [1].

This growth will not happen only because technology areas decide to develop thousands of agents. They will also arrive embedded in business applications, software-as-a-service platforms, development tools, and solutions bought from different vendors. At the same time, areas of the company itself may build agents to solve specific needs, often without knowing that another team has already created something similar.

It is in this context that the term AI Agent Sprawl appears, which we can translate as uncontrolled proliferation of AI agents. The problem begins when expansion stops being accompanied by a common view of which agents exist, why they were created, who answers for them, which resources they can access, how much they cost, and whether they should still be active.

Creating agents is getting easy. Governing a population of them is not.

The proliferation of technology inside companies is not a new phenomenon. Applications, cloud services, automations, and tools have gone through similar cycles. What makes agents different is the combination of speed of creation, autonomy, and the ability to act directly on corporate systems and data.

An agent can be developed in-house by a team, configured on a low-code platform, enabled inside an application that has already been contracted, or provided by a vendor. In a short time, different areas can start running their own populations of agents, each answering to its own priorities.

Amazon Web Services (AWS) describes a scenario that is already starting to appear in organizations with multiple business units: different teams build similar agents for procurement, scheduling, reporting, or data processing without knowing another area has already solved the same problem. At the same time, customer relationship platforms, service desk, and contact center tools start embedding their own agents [2].

The result is not just duplication. Different agents may act on the same systems, use different credentials, generate costs spread across several budget centers, or even execute conflicting actions without one area having visibility into another [2].

When every area can create its own agents, the problem stops being only technological. The company needs to find out whether it is building a corporate capability or just multiplying isolated solutions.

Deloitte observes that proliferation tends to increase across different programming languages, frameworks, infrastructures, and communication protocols. At the same time, agents built in-house will need to coexist with those acquired through applications and external vendors [3]. This means the environment will hardly be homogeneous.

The answer also cannot be simply to centralize all agent creation in a single team. In large organizations, that model can turn governance into a bottleneck and encourage exactly what you want to avoid: areas looking for alternative paths to keep innovating.

The challenge is to allow distributed creation without losing corporate visibility. To that end, Gartner puts among its first recommendations the creation of a centralized inventory of agents, accompanied by clear rules about who can create them, share them, and connect them to company resources [1].

Inventory, however, should not mean just a list of names. To be operationally useful, it needs to help answer what the purpose of each agent is, who owns it, which systems it uses, which permissions it has, which dependencies it maintains, and at which stage of its lifecycle it is.

The problem starts when nobody knows which agents still make sense

The ease of creating an agent produces another predictable effect: it is much simpler to put a new solution into operation than to periodically review whether it should still exist.

An agent may be born to meet a temporary need, stay active after a project ends, or lose relevance when another solution starts performing the same function. It may also keep permissions granted months earlier, even if its purpose has changed.

This problem tends to accumulate silently. Unlike a large corporate system, whose deployment normally involves a budget, a project, owners, and formal processes, some agents may emerge as small automations inside the very tools teams use.

AWS draws attention precisely to the cost of duplication across business units and recommends a simple principle: before building, check whether that capability already exists. The proposal includes a corporate registry, identification of owners, and periodic lifecycle reviews to retire agents with low usage, outdated logic, or redundant capabilities [2].

This concern becomes even more relevant when we consider that adoption is no longer restricted to experiments. KPMG reports, based on its AI Pulse survey for the first quarter of 2026, that more than half of organizations already have AI agents in production [4].

More than half of organizations already operate AI agents in production, according to KPMG. The challenge starts to shift from the ability to create agents to the ability to operate them as a corporate system [4].

Deloitte found another sign of this transition. In a survey published in August 2026, only 15% of organizations said they had scaled orchestrated, multifunctional adoption of multiple agents, while only 5% considered their business processes highly prepared for AI agents [5].

These numbers help explain why multiplying successful pilots does not automatically produce a corporate architecture of agents. The leap from dozens of local initiatives to a governed population requires different capabilities: inventory, identity, policies, observability, cost attribution, lifecycle management, and mechanisms to identify redundancies and dependencies.

This is also where the previous articles in this series connect. In Shadow AI: do you know which AIs and agents are being used inside your company?, the problem was usage that happens outside the organization’s visibility. In Agent Sprawl, many agents may be legitimate and known to the areas that created them, but the company loses the view of the whole.

Likewise, identifying each agent, as we discussed in Identity for AI agents: why it is essential to know who the agent is and which systems it accesses, becomes even more important when the population grows. You cannot consistently govern thousands of agents if they remain indistinguishable or if nobody can tie them to owners, purposes, and permissions.

Agent Sprawl does not just mean having too many agents. It means losing the ability to understand, as an organization, which agents exist, why they exist, and whether they should still exist.

Scaling AI cannot simply mean multiplying agents

There is a natural temptation to use the number of agents as a sign of maturity. A company with hundreds of agents in production may look more advanced than another with a few dozen. But that metric says little about the value actually produced.

Gartner offers an interesting example in sales. The firm projects that, by 2028, AI agents could outnumber sellers ten to one, while fewer than 40% of sellers are expected to say these agents improved their productivity [6].

In sales, Gartner predicts ten AI agents for every seller in 2028, but fewer than 40% of sellers are expected to perceive a productivity improvement [6]. More agents, therefore, do not automatically mean more results.

This distinction is fundamental. If different areas create agents for similar activities, if capabilities that could be reused are rebuilt repeatedly, or if agents stay active without producing measurable value, expansion increases complexity without necessarily increasing productivity.

KPMG describes this problem as a shift from a capacity challenge to an architecture and control challenge. Instead of treating each agent as an independent use case, the organization needs to start treating them as components of an enterprise system, with shared visibility, identity, permissions, traceability, and responsibilities [4].

This also changes the question managers should ask. Instead of only asking how many agents are in production or how many new use cases have been launched, it becomes necessary to understand which results each agent produces, which capabilities could be shared, where redundancies exist, and which agents should be consolidated or retired.

Lifecycle becomes as important as creation. Every agent should be born with an identifiable purpose and, ideally, with criteria that later allow you to assess whether it is still needed. Without that process, the population grows by accumulation: new agents come in and few leave.

Governing this expansion does not mean preventing areas from experimenting. On the contrary, a well-designed model needs to make the governed path simpler than the informal alternative. AWS proposes exactly this logic by advocating federated models in which corporate standards coexist with business unit autonomy within defined limits [2].

As adoption matures, perhaps one of the most important metrics will stop being how many agents the company managed to create. What will matter more is how many actually generate value, how many reuse existing capabilities, which ones can be reliably operated, and which should already have been shut down.

AI Agent Sprawl is therefore less a problem of quantity than of operational capability. Thousands of agents can be manageable if the organization can identify, govern, observe them, and measure their results. A few dozen can already be a problem if each one operates as an independent silo.

From vision to practice: ARGUS

The proliferation of agents reinforces the need for an operational layer able to offer a common view of how this new population is acting. This is the context in which ARGUS, our Operational and Agentic Intelligence platform, is positioned.

With AgentOps (Agent Operations) and AI Gateway capabilities, ARGUS aims to support the governance and observability of agent activity, relating elements such as identity, policies, permissions, tool calls, decisions, costs, latency, and results.

This view becomes especially relevant in heterogeneous environments. A company’s population of agents will probably not be built on a single platform nor use only one model or framework. Part may come from contracted applications, part from in-house development, and part from different AI providers.

The role of ARGUS is not to prevent this diversity, but to help keep it from turning into new operational silos. By correlating information from multiple sources, the platform aims to build shared operational context, relating agent activity to what happens in applications, infrastructure, services, automations, and human actions.

This perspective also allows governance to move closer to value. As agents multiply, tracking only whether they are technically working will be insufficient. It will be necessary to understand how they are being used, which resources they consume, and which results they produce, creating conditions for decisions about expansion, review, or retirement.

In a company with hundreds or thousands of agents, the ability to see the whole stops being a convenience. It becomes part of the infrastructure needed for Agentic AI to grow without complexity growing even faster.

Learn about ARGUS and see how it works in practice.

About the author

Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.

He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).

In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] Gartner. Gartner Identifies Six Steps to Manage AI Agent Sprawl. Apr. 28, 2026.

[2] Amazon Web Services. Managing AI agent sprawl across business units. Jul. 17, 2026.

[3] Deloitte. Unlocking exponential value with AI agent orchestration. 2026.

[4] KPMG. From Agent Sprawl to Enterprise Outcomes. 2026.

[5] Deloitte. AI Agents are Only the Beginning: Deloitte Survey Examines the AI Readiness Gap and Reveals How Enterprises Can Prepare for Agentic Success. Aug. 12, 2026.

[6] Gartner. Gartner Predicts AI Agents Will Outnumber Sellers 10 to 1 by 2028, Yet Fewer Than 40% of Sellers Will Say Agents Improved Productivity. Jul. 28, 2026.