The promise was that agents would collapse your silos. The mechanics say each one arrives carrying a private copy of them.
Why Agent Sprawl Matters Now
The prevailing instinct inside enterprise AI programs right now is throughput: more agents, more employees building them, faster. It is a reasonable instinct — the productivity case is real and the adoption curve is already steep. Gartner’s CIO survey puts 17% of CIOs as having deployed AI agents, with 42% expecting to inside a year. That is not a pilot cohort. That is a market moving from zero to default in four quarters.
What the throughput frame misses is what each agent actually is at the artifact level. An agent is not a thin client onto a shared corporate brain. It is a bundle: its own instruction set, its own copy of whatever org knowledge the builder pasted in, its own connectors, its own credential grants, its own private logic about which system is authoritative. Ship a thousand of those and you have not dissolved the silos that made the org hard to reason about. You have re-encoded them a thousand times, each one privately managed by an employee who has no obligation to tell you it exists.
One framing making the rounds captures it well: every employee becomes the manager of a personal team of agents. Read that as an org chart and it sounds like leverage. Read it as a position sheet and it is a thousand books, each marked to its own model, none of them netted against the others.
| Signal | Figure | Why it matters to the estate |
|---|---|---|
| Organizations reporting an AI agent security incident this year | 88% (Ospiri research) | The incident rate is already near-universal; sprawl compounds an existing loss, not a hypothetical one |
| Average shadow-AI breach cost above the cyber baseline | +$670K (Ospiri research) | Each undocumented agent carries incremental severity, not just incremental frequency |
| Unauthorized agent transactions caused by internal violations through 2028 | At least 80% (Gartner) | Duplication is an insider-risk multiplier — oversharing and misuse, not attackers |
| CIOs deployed / deploying within a year | 17% / 42% (Gartner CIO survey) | The window to build a map before the estate is large is roughly this fiscal year |
The Duplication Is Structural, Not Sloppy
It is tempting to treat this as a hygiene problem — better templates, a wiki, a center of excellence. It isn’t. The duplication is a property of how agents are packaged. Compare the two eras honestly.
| Dimension | Human org, 1990–2020 | Private agent teams, 2026 | Why the difference bites |
|---|---|---|---|
| Unit of work | Team with a shared system of record | Individually owned agent with its own context | No shared substrate to consolidate against |
| Knowledge copy | Reference to a source | Pasted, embedded, or vector-copied at build time | Every copy drifts from the source independently |
| Access grant | Provisioned once, reviewed on a cycle | Re-issued per agent, per connector, per build | The same grant appears five ways with five owners |
| Cost signal | Headcount and license lines | Token draw spread across dozens of service accounts | Duplicate spend is invisible in aggregate |
| Retirement | Offboarding process | Nothing — the agent keeps running | The book only ever grows |
The last row is the one that should bother a CFO. Human silos were expensive but self-limiting: people left, teams reorganized, budgets forced consolidation. An agent estate has no natural offboarding event. Left alone, it accumulates monotonically.
Anatomy of a Duplicated Estate
The pattern is consistent enough to write down. It typically runs like this:
- A workflow gets solved once. Someone in finance builds an agent that reconciles two reports. It works, and it quietly becomes load-bearing.
- The solution isn’t discoverable. There is no place to look, so the next three people who need the same thing don’t find it.
- The workflow gets re-solved. Three more agents appear, each with its own connector into the same two systems, each with its own credential.
- The copies diverge. One embeds a stale mapping table. One got broader scope because the builder hit a permissions error and asked for more. Now the four agents disagree, and nobody knows which is authoritative.
- The exposure compounds silently. Four token meters, four access grants, four blast radii — and one map that would have caught it, which nobody built.
Step 5 is where a productivity story becomes an exposure story. You cannot consolidate an access grant you cannot see re-issued five ways.
Pricing the Duplication Tax
Treat it the way you’d size any repeated position. The cost is not one number, it’s frequency times severity, applied per redundant copy:
Duplication Tax = (Agents per Employee × Redundant Connections per Agent) × (Token Draw + Access Grant Exposure)
| Factor | What to measure | Direction of risk |
|---|---|---|
| Agents per employee | Distinct agents, skills files, and MCP servers attributable to one identity | Linear driver — the multiplier on everything else |
| Redundant connections per agent | Connectors reaching a system already reached by another agent under the same owner | Pure waste; also the cleanest consolidation target |
| Token draw | Per-agent and per-service-account consumption, including off-hours | Duplicate spend, and a usable shadow-agent sensor |
| Access grant exposure | Sensitivity of the data reachable, weighted by reversibility of the action | Severity term — where a small position becomes tail risk |
Two things fall out of writing it this way. First, the redundancy term is the cheapest thing on the list to fix — it is duplicate spend with no offsetting benefit, and cutting it needs no policy fight. Second, severity does not scale with the count of agents; it scales with the worst-permissioned copy in the estate. Ten well-scoped duplicates and one over-scoped one is not a diversified book. It is a single concentrated risk wearing ten disguises.
The Map Has Two Inputs
Every serious answer here reduces to building a map of the estate. The mistake is assuming one input is enough.
| Control question | Declared footprint (watermark / registry) | Endpoint ground truth (kernel) |
|---|---|---|
| What agents exist? | Everything published through a sanctioned path | Everything actually executing, sanctioned or not |
| What data does it touch? | What the builder declared at publish time | What the process opened on disk, with the label attached |
| Is this a duplicate? | Comparable specs, connectors, and skills files | Observed overlap in actual file and network reach |
| Has it drifted? | Frozen at publish | Reconciled continuously against the declaration |
| Can you act on it? | Deprecate, sunset, consolidate in catalog | Contain, sandbox, or block in line at the point of action |
The declared side is what makes the estate legible — owners, intended data sources, reuse candidates. That is genuinely how you retire duplicates and stop teams re-solving solved problems. But a declaration is a self-report frozen at publish time. It is what the builder said the agent would touch, not what it reaches at 2am three sprints later. Endpoint observability is what keeps the catalog honest, because something has to check the declaration against the disk.
These are two layers, not one product. Treat them as substitutes and you get either a tidy catalog describing an estate that no longer exists, or a stream of kernel events with no owner attached to any of them.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Inventory agents, skills files, and MCP servers per identity — zero-install, via identity, egress, and repo signals | Ranked estate map with owners | Hours |
| 2 | Compute redundant connections per owner against the inventory | Consolidation list with duplicate spend attached | Days |
| 3 | Score the worst-permissioned copy of each duplicated workflow, not the average | Severity-ranked shortlist for enforcement | Days |
| 4 | Enforce at the endpoint only where exposure warrants it; reconcile declared vs observed on a cycle | Kernel evidence and a drift report the board can read | Weeks |
Sequence matters more than tooling here. Steps 1 and 2 are cheap and produce a budget conversation. Step 4 is where governance becomes a control rather than a document — and it is much easier to fund once steps 1 through 3 have priced the exposure.
The Bottom Line
A thousand agents is not a thousand times the leverage; it is a thousand private copies of your company, each marked to its own book. The duplication is structural — it comes from how agents are packaged, not from carelessness — which means templates and wikis will not touch it. The estate has no natural offboarding event, so the position only grows until someone builds a map. And the map needs both halves: the declared footprint to make it legible, and endpoint ground truth to keep it honest.
If your team is sizing this for the next fiscal cycle, request a working session. We will walk through your environment, produce a ranked inventory of agents and connectors with duplicate-spend attribution, and scope a deployment. 90 minutes.