The short answer
The question in most enterprises has moved. It used to be whether to deploy AI agents. It is now how to govern the ones that already exist.
Agents accumulated the way tools always accumulate in large organizations. A team built one because it solved a problem. Another team built something similar without knowing. A purchased platform shipped one inside a module nobody evaluated as an agent. A business unit adopted a tool that lets its own users create them.
Nobody decided to have forty agents. The organization has forty agents.
Sprawl is a consolidation problem before it becomes a governance problem, and the order matters. A policy requiring risk classification, approval paths and monitoring cannot be enforced against a population nobody has enumerated. The first step is finding out what exists, and that step is harder than it sounds because a meaningful share of the estate was never registered anywhere.
Key takeaways
- Sprawl forms through ordinary decentralized adoption, with every individual decision being reasonable.
- The inventory is the prerequisite. Policy applied to an unenumerated estate governs nothing.
- Duplication is the largest finding in most first inventories, and it is invisible from inside any single team.
- Agents embedded in purchased software are the most commonly missing entries.
- Consolidation decisions follow process overlap rather than technical similarity.
- Without an intake path, the inventory starts decaying the day it is finished.
How sprawl forms
Decentralized adoption is usually correct
A team with a problem and a capable platform builds something. That is the behaviour most organizations spent a decade trying to enable, and it produces real value.
The cost appears at the aggregate level, where nobody is looking. Each local decision is sound and the sum is an estate nobody designed.
Similar problems appear in several places
Three functions independently need to summarize incoming documents, route requests or answer internal questions. Each builds for its own context. The overlap is substantial and none of them can see it, because visibility stops at the function boundary.
Embedded agents arrive without a decision
A purchased platform ships an agent inside a module. Nobody evaluated it as an agent deployment, because it arrived as a product feature. It holds access, takes actions, and sits outside whatever governance the organization applies to the things it built itself.
These are the most commonly missing entries in a first inventory, and frequently the most permissive.
Experiments stay running
A pilot runs, produces a mixed result, and nobody explicitly stops it. The agent continues operating with its original scope and its original access long after the team that built it moved on.
Why this goes beyond a security concern
Security risk is the framing that gets attention and it understates the problem. Four costs accumulate in parallel.
Duplicated build and maintenance. Several implementations of a similar capability, each requiring updates, monitoring and eventual migration.
Inconsistent handling of the same case. Two agents applying different logic to the same situation produce outcomes that depend on which path a case happened to take, which is difficult to explain to a customer or an auditor.
Unowned access. Agents built by people who have since changed roles hold permissions nobody reviews.
Governance that cannot be applied. Every month without an inventory is a month during which new agents enter an estate the organization cannot describe.
Building the inventory
The inventory is the work. Everything after it is comparatively straightforward.
What to capture per agent
| Field | Why it matters |
|---|---|
| Name and owner | Many entries will have no current owner, which is itself a finding |
| Business process affected | The basis for consolidation decisions |
| Trigger | Scheduled, user-initiated or event-driven |
| Data accessed | Scope, sensitivity, and whether access is still appropriate |
| Actions it can take | The blast radius if it is wrong |
| Human review point | Where a person approves, if anywhere |
| Volume | Decisions or actions per period |
| Origin | Built internally, embedded in a purchased product, or configured by a user |
| Status | Active, dormant or unknown |
The origin field is the one most inventories omit and the one that surfaces the embedded agents nobody counted.
Where to look
A survey of technical teams produces the agents that were built deliberately. Three other sources are required.
Procurement and software inventory, for capability embedded in purchased products. Platform administration, for agents configured by business users in tools that permit it. And the business itself, by asking teams what automated assistance they use day to day.
The third source turns up the most surprises and requires asking people rather than querying a system.
Agent estate view
What an inventory makes visible
| Dimension | Question it answers | Typical first-inventory finding |
|---|---|---|
| Coverage | Which processes have agents | Concentration in a few functions, gaps elsewhere |
| Duplication | How many agents address the same process | Higher than expected |
| Ownership | Who is accountable for each | A meaningful share have none |
| Access | What each can reach | Broader than the use case requires |
| Autonomy | What each can do without a person | Inconsistent across similar cases |
| Origin | Built, bought or configured | Embedded agents missing entirely |
Every row is unanswerable before the inventory exists, which is why a policy written first governs nothing.
Deciding what to consolidate
Once the inventory exists, sort entries by the business process they affect rather than by their technical characteristics.
Technical similarity misleads. Two agents on the same platform doing different work are not consolidation candidates. Two agents on different platforms doing the same work are.
| Disposition | When | What it involves |
|---|---|---|
| Consolidate | Several agents address the same process step | One implementation, one owner, migrate the rest |
| Retain | The agent addresses a distinct process and works | Bring it under governance, confirm ownership and access |
| Retire | Dormant, superseded or unused | Revoke access, record what it did and why it stopped |
| Rebuild | The process is worth automating and the implementation is unsound | Re-scope against the real process, then build once |
The rebuild disposition deserves separating out. An agent scoped against a documented process, built quickly and never validated may be addressing a real need with a wrong specification. Retiring it without replacing it returns the manual work to a person.
Governing what remains
Retrofitted governance is harder than built-in governance and it is what most organizations now face. Five elements, in order of urgency.
Ownership. Every retained agent gets a named business owner accountable for its behaviour and its access. Entries without an owner are retired or reassigned before anything else proceeds.
Risk tiering. Classify each agent by the consequence of a wrong output and whether that consequence is reversible. The tier determines review depth, monitoring and whether a person approves before action.
Access review. Scope each agent's reach to what the use case requires. Sprawl estates routinely contain agents holding permissions granted for a scope that has since narrowed.
Intake. A path for new agents requiring an owner, a process, a risk tier and an access scope before production. Without this the inventory decays immediately.
Retirement. A defined trigger and procedure for stopping an agent. Estates grow because entries arrive and nothing leaves.
Why duplication stays invisible
Worth naming, because it determines how the inventory has to be built.
Each team knows what it built and why. None of them can see that three other teams built something similar, because no vantage point spans functions.
Asking teams whether they duplicate anything produces honest negative answers. They do not know. Duplication becomes visible only when entries are grouped by business process, by someone looking across the whole estate at once.
That is the same structural problem that produces overlapping initiative portfolios, and it has the same resolution: collect across functions simultaneously and group by cause rather than by reporter.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. It addresses the part of this problem a technical inventory cannot reach: which agents exist that nobody registered, which processes they affect, and where several address the same underlying work.
Discovery Cycles run AI-led interviews across the roles that operate a process, asking what automated assistance they use and how it fits their workflow. That surfaces capability configured by business users, embedded in purchased tools, or built by someone who has since moved on. The Insights Dashboard groups findings by process and cause rather than by who reported them, which is what makes duplication visible across functions. The Process Library maps what exists against the processes it affects, and the Initiatives Dashboard converts consolidation decisions into items with owners.
Mercado Libre faced the same structure at the level of its initiative portfolio, which is the closest published analogue to an agent estate.
Operating in 18 countries with more than 84,000 employees, the company was carrying over 600 initiatives, many overlapping or misaligned, across a fragmented estate spanning SAP, ARIBA, PIC, CLM, Jira, BigQuery, Tableau, Apache and Bypass. Its manual discovery model meant months of interviews covering under 1% of the workforce and more than 100 coordination hours per initiative, which made a consolidated view practically unobtainable.
Horizon interviewed 2,000 employees in four days across five countries, reaching 100% of the targeted functions. Cross-country benchmarking revealed hidden duplications and best practices that were invisible from inside any single market. The portfolio resolved to 24 initiatives with ROI, effort and roadmap attached, producing $2.3M in projected annual savings from 12,000 to 13,000 hours automated and 76 FTE equivalents avoided, with first implementations live in under a week.
The operation that produced that reduction was grouping by underlying process across markets. An agent inventory requires the same move.
That is one engagement under specific conditions rather than a projection for any organization.
Agent sprawl checklist
- Can you produce a list of every agent operating in your organization today?
- Does that list include capability embedded in purchased products?
- Does it include agents configured by business users in platforms that allow it?
- How many entries have no current owner?
- Grouped by business process, how many processes have more than one agent?
- For each agent, do you know what data it accesses and whether that scope is still appropriate?
- For each agent, do you know what actions it can take without a person?
- Is there an intake path requiring an owner and a risk tier before production?
- Is there a retirement trigger and procedure?
- How long would it take you to answer question 1 today?
Question 10 is the fastest diagnostic. Organizations that can answer in hours have an inventory. Organizations that need weeks have sprawl.
Common mistakes
Writing policy before building the inventory. A policy applied to an unenumerated population governs nothing.
Building the inventory from technical sources only. Misses embedded capability, business-configured agents and anything built by someone who left.
Grouping by technology. Technical similarity does not predict consolidation opportunity. Process overlap does.
Retiring without checking what returns. An agent doing real work leaves manual work behind when it stops.
Finishing the inventory without an intake path. The list is accurate on the day it is completed and decays from the next one.
Framing this as a security exercise alone. Security risk is the visible cost. Duplicated maintenance and inconsistent handling are larger and quieter.
FAQ
What is AI agent sprawl?
The accumulation of AI agents across an organization without a coordinated view of what exists, what each does, who owns it and what it can access. It forms through ordinary decentralized adoption: teams build what they need, vendors embed agents in purchased products, and business users configure them in platforms that permit it.
Why is agent sprawl a problem?
Four costs accumulate. Duplicated build and maintenance across several implementations of similar capability. Inconsistent handling, where the outcome depends on which agent a case reached. Unowned access held by agents whose builders have moved on. And governance that cannot be enforced against a population nobody has enumerated.
How do you build an AI agent inventory?
Capture name, owner, affected process, trigger, data accessed, available actions, human review point, volume, origin and status for each entry. Build it from four sources: technical teams, procurement and software inventory, platform administration, and the business itself. The fourth surfaces agents that were never registered anywhere.
How do you decide which agents to consolidate?
Group inventory entries by the business process they affect rather than by technical characteristics. Agents on different platforms doing the same work are consolidation candidates. Agents on the same platform doing different work are not. Four dispositions cover most estates: consolidate, retain, retire or rebuild.
Should you write an AI agent policy before or after the inventory?
After. A policy requiring risk classification, approval paths and monitoring cannot be applied to a population nobody has listed. The inventory also changes what the policy needs to say, since first inventories routinely reveal categories of agent the drafters had not considered.
How do you stop sprawl from returning?
An intake path requiring a named owner, an affected process, a risk tier and an access scope before production, plus a defined retirement trigger. Estates grow because entries arrive continuously and nothing leaves, so both halves are necessary.
Count them before you govern them
Every organization with meaningful AI adoption now has more agents than it can name, and none of them arrived through a bad decision.
The recovery starts with an operation that sounds administrative and turns out to be the whole task: producing a list, grouped by the work each agent affects, complete enough to include the ones nobody registered.
See it. Fix it. Own it.