Agent Sprawl

Problem

Building agents is fast and decentralised; governing them — assigning an owner, defining what success looks like, monitoring behaviour, and retiring them when they stop earning their keep — stays slow and centralised, and the gap compounds. Agents accumulate faster than anyone catalogues them, so no one can say how many are in production or what systems they reach. Most run unwatched: there is no owner to notice when one degrades, no success metric to judge it against, and no decommissioning path, so a half-finished agent keeps making autonomous decisions on sensitive systems long after the team that shipped it has moved on. The fleet becomes legacy debt that nobody fully understands and nobody is accountable for, and a single misbehaving agent can act for weeks before anyone notices.

Solution

Govern the agent fleet at the rate it grows. Make it a deployment gate that every production agent declares an owner, the business outcome it is accountable for, and the conditions under which it is paused or retired, and register it in a central inventory that can be reconciled against what is actually running. The order matters: the business case and an accountable owner come first and the technical platform second, because a governance tool layered onto an already-sprawling fleet only inventories the mess. Mitigation patterns: tool-agent-registry for a reconciled inventory of agents and their owners, and kill-switch for the pause-and-decommission path each agent must carry. This is the organisational, fleet-scale lifecycle failure that those per-agent controls do not by themselves prevent.

When to use

• Multiple teams deploy their own production agents with no central inventory of what exists or who owns each one.
• Agents reach production without a named owner, a success metric, or a defined way to pause or retire them.
• An audit cannot say how many agents are running, what systems they touch, or which are still earning their keep.