Skip to content

CONCEPT Cited by 1 source

Tool sprawl

Definition

Tool sprawl is the named application-layer failure mode of an enterprise running AI agents at non-trivial scale without a centralised inventory of the tools those agents can call: tools are built ad-hoc by individual teams, undocumented, ungoverned, and invisible to the rest of the organization.

"In most large organizations, these tools are built by individual teams in an ad hoc fashion: undocumented, ungoverned, and invisible to the rest of the organization. … Teams rebuild what already exists elsewhere, security reviews miss tools that were never registered, and when something breaks, no one has a complete picture of what is running or why." — Source: sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries

Why it's structural, not a discipline problem

The 2026-05-11 MongoDB post frames tool sprawl as the predictable outcome of asking teams to solve an infrastructure problem at the application layer:

"Fragmented tool development is not a consequence of poor engineering practice. Rather, it is the predictable outcome of asking teams to solve an infrastructure problem at the application layer."

The historical analog is the pre-package-manager era of software development. Before npm / PyPI / Maven, every team rebuilt utility libraries from scratch — not because teams were undisciplined, but because the default path for sharing code across teams was friction-heavy enough that "reimplement" won over "discover, depend, and govern." Centralised package managers solved this by making the friction-favorable direction inverted at the infrastructure layer: it became easier to publish + consume than to reimplement. AI agent tools sit in the same place today.

Three compounding costs

Tool sprawl produces three costs that compound with adoption:

  1. Duplicated engineering effort. Teams rebuild what already exists elsewhere because "it is easier to generate a tool than to find one that already exists." Duplication is redundancy + technical debt + diverging behavior across instances of nominally-the-same capability.
  2. Security exposure. Security reviews miss tools that were never registered; without a registry, "discovery is manual, incomplete, and stale." The 2026 Gravitee survey: only 14.4% of teams with agents past planning have full security approval; 88% of organisations had an agent-related security incident this year.
  3. Operational opacity. When an agent misbehaves, "no one has a complete picture of what is running or why." The substrate to ask "which tool did the agent call?" doesn't exist; debugging falls back on log archaeology per-team.

Sub-shapes

  • AI-tool sprawl — the shape this concept captures: parallel implementations of the tools agents call (MCP servers, REST APIs, code-execution sandboxes, data accessors).
  • Coding-agent sprawl — the sibling concept at the client layer: parallel coding clients (Cursor, Claude Code, Codex CLI, Gemini CLI). Same governance / cost / visibility framing; different layer.

The two compose: an organisation with both N coding-agent clients and M ungoverned tools has an N×M surface — each client can call any tool, and neither the clients nor the tools have a shared registry to mediate.

The structural fix

Per the 2026-05-11 MongoDB post, the structural fix is the enterprise AI tool registry — an organisation-internal inventory + four-function (discovery + versioning + certification metadata + access control) substrate that makes governance possible without itself being a governance layer.

The key architectural property: the registry is infrastructure, not application logic. It moves the friction-favorable direction from "reimplement" to "discover and adopt" the same way package managers did for shared code.

  • vs concepts/coding-agent-sprawl: tool sprawl is about the tools agents call; coding-agent sprawl is about the clients that drive the agents. Both motivate centralised governance, but at different layers.
  • vs concepts/configuration-bloat: configuration bloat is when a single product accumulates internal configuration artifacts faster than the team can prune; tool sprawl is when an organisation accumulates tool implementations across teams without a coordination point.
  • vs shadow IT: shadow IT is humans using unsanctioned software directly; tool sprawl is a governance gap in the layer agents call into — distinct from end-user shadow IT by the involvement of agent identities and machine-speed invocation patterns.

Seen in

Last updated · 542 distilled / 1,571 read