Agent count is becoming a new technology vanity metric.
A company builds a research agent, a sales agent, a marketing agent, a finance agent, and a customer-support agent. Individual employees create more inside the tools they already use. Software vendors add assistants inside the CRM, project tool, accounting system, and email platform.
Soon the company can say that it operates thirty AI agents.
That number reveals very little. Some agents may complete valuable work every day. Others duplicate each other, run once a month, or produce drafts that still need extensive correction. Nobody knows the total cost, which credentials they use, or whether two agents can update the same customer record.
Small companies need measurable workflows. They do not need an AI headcount competition.
This is Part 3 of After the Chatbot, following Part 2 on computer-use agents and legacy software .
What is AI agent sprawl?
AI agent sprawl is the uncontrolled growth of agents across teams, tools, and business processes without shared ownership or governance.
AWS describes several common consequences: duplicated capabilities, conflicting actions on shared systems, hidden aggregate costs, shadow agents, and fragmented compliance. Gartner has published a six-step management approach .
Large enterprises encounter the problem across business units. A ten-person company can create a smaller version when one employee works across several functions and holds broad access.
How sprawl starts in a small company
The first agent often works well. It prepares a useful morning brief or follows up with new leads. That success encourages the company to create another.
Agent growth then follows four paths.
Every function gets its own agent
Sales, marketing, finance, operations, and management each create separate assistants. Their work overlaps because real business processes cross departmental lines.
Every tool adds an agent
The CRM, project tool, website platform, accounting system, and email provider all introduce AI features. Each agent sees one part of the company and optimizes for its own product.
Every employee experiments privately
An employee creates a scheduled task or custom agent under an individual account. The workflow may be useful, but the company has no inventory or recovery plan if that employee leaves.
Failed agents remain deployed
An experiment stops producing value but keeps its credentials, schedules, logs, and subscriptions. Nobody is clearly responsible for retiring it.
None of these decisions looks reckless by itself. The combined system becomes difficult to reason about.
Agent count measures deployment, not value
A board would not judge a sales operation by counting browser tabs. It should not judge AI adoption by counting agents.
Better measures include:
- recurring workflows completed end to end
- human hours recovered
- percentage of cases requiring manual intervention
- error and rework rate
- cost per completed outcome
- time from input to approved result
- number of customer or financial actions stopped for review
- incidents and near misses
A single agent that reliably prepares every proposal, checks the source material, routes exceptions, and produces an approval-ready draft may create more value than ten specialised agents that constantly hand work to one another.
Distinguish agents from
Some sprawl comes from giving every capability its own identity.
Terminology differs between platforms, but a useful operating distinction is this: an agent owns a workflow goal, tools, permissions, and actions, while a skill is a reusable capability within that workflow, such as checking a contract, querying a CRM, or preparing a spreadsheet. OpenAI describes a similar relationship , with skills defining how work should be done and agents applying them inside a workflow.
This distinction makes consolidation easier. The company may not need separate agents for research, formatting, source checking, and email drafting. It may need one proposal workflow that uses those four skills.
The architecture becomes easier to understand:
- one workflow owner
- one agent identity
- a defined set of reusable skills
- one action log
- one review path
Separate agents remain useful when responsibilities, data boundaries, or risk levels genuinely differ.
Create a minimum viable agent registry
Every production agent should appear in a simple registry. A spreadsheet is enough to begin.
Record:
- agent name and purpose
- business owner
- technical owner
- systems and data it can access
- actions it can take
- customer-facing or internal status
- model and platform
- schedule or trigger
- review and approval requirements
- monthly cost
- last successful run
- last review date
- shutdown method
The registry creates visibility before the company needs a dedicated management platform.
It also exposes uncomfortable questions. An agent without an owner is already a problem. An agent with access to customer records and no action log is a larger one.
Use a consolidation test
Review the portfolio every quarter and ask five questions.
Does another agent already perform most of this work?
If yes, combine the capability or share a skill.
Does this agent complete a business outcome?
Draft production can be useful, but somebody should know which downstream result it supports.
Can a person understand its permissions?
Broad or inherited access should be reduced.
Does usage justify maintenance?
An agent that saves twenty minutes each quarter may not justify a separate system.
Would the company rebuild it today?
If nobody would approve the current design, retire it.
Consolidation should not create one all-powerful agent with access to everything. It should reduce duplication while preserving useful boundaries.
Keep financial and customer actions supervised
Agent sprawl becomes dangerous when several systems can send messages, change shared records, approve spending, or trigger external work.
Use approval gates for:
- sending customer or prospect communication
- changing prices or commercial terms
- approving invoices or payments
- signing or accepting agreements
- deleting records
- changing employee information
- publishing public content
Agents can prepare these actions and collect the evidence. A named person remains accountable for the final decision.
Frequently asked questions
How many AI agents should a small business have?
There is no useful universal number. Start with one well-defined workflow. Add another agent only when the new responsibility, permissions, or risk boundary cannot be handled cleanly by the existing system.
Is a multi-agent system always a bad idea?
No. Multi-agent systems can separate roles, parallelize work, and improve review. They need a clear reason for each agent and a controlled handoff between them.
Who should own an AI agent?
The business owner of the workflow should own the outcome. A technical owner can maintain the implementation, but technical ownership does not replace operational accountability.
What should be shut down first?
Retire agents with no owner, no recent successful use, duplicated capability, unnecessary permissions, or outputs that create more review work than they save.
Build around finished work
A small company gets leverage when recurring work closes with less delay and fewer errors. The number of characters in the agent roster has no independent value.
Start with a painful workflow. Define the outcome, permissions, review points, and owner. Add reusable skills as the process matures. Split the system only when a real operational boundary demands it.
XYZ’s Small Autonomous Organization offer is for functions that genuinely need separated roles, permissions, quality checks, and handoffs. It starts with the smallest governed set needed to close the workflow. A Security Officer can help review permissions, logs, and operating controls as the portfolio grows.