Agent Sprawl - How to Govern AI Agents Before They Multiply
What is agent sprawl?
Agent sprawl is the uncontrolled growth in the number of AI agents and assistants across an organisation - built by different teams, on different frameworks, with no shared layer for governance, observability, or cost control.
It is not a technology problem in itself. It is the same organisational pattern we watched play out with cloud infrastructure a few years ago - only now it applies to AI agents. If you already know the term cloud sprawl, you will recognise the mechanism immediately: ease of creation + no oversight = uncontrolled growth.
The difference is that agent sprawl carries a higher stake. A forgotten EC2 instance “only” runs up a bigger bill. A forgotten AI agent has access to data, takes actions, and makes decisions - often with no logs, no limits, and no owner.
What agent sprawl looks like in practice
A typical scenario we see at organisations adopting AI faster than the governance around it:
- The product team adds an AI assistant to the application - built on an external model API, wired into the frontend. It runs in production.
- The operations team builds a tool that automates repetitive back-office work. Triggered on demand, on a different framework, with its own integration into internal systems.
- The engineering team stands up its own assistant for developers - in yet another technology, with access to repositories and internal documentation.
Three teams, three systems, three different architectures. Each one makes sense on its own. Together they create the problem: there is no shared way to build, govern, or observe agents. And when a fourth use case comes along, a fourth team builds a fourth system the same way.
That is the moment worth pausing at.
What agent sprawl costs
The costs of agent sprawl are less obvious than with cloud sprawl, because much of it is risk rather than a line on an invoice. But it is real.
| Category | Example | Impact |
|---|---|---|
| Duplicated work | Three teams solve the same problems: authorisation, memory, tool access, logging | The same thing built and maintained several times over |
| Uncontrolled model costs | Every agent calls a model with no shared budget, tagging, or token limits | Inference bill grows with no attribution to a team |
| Security risk | An agent with warehouse access but no least-privilege, no human-in-the-loop on sensitive actions | Data leak or an unwanted action taken autonomously |
| No observability | Nobody knows which agent did what, what it cost, or why it made a given decision | Audit is impossible, debugging is hard, no accountability |
| Identity debt | Each agent has its own way of authenticating and propagating permissions | Growing attack surface, inconsistent access control |
The key observation: inference cost is the smallest of these problems. The real cost is the absence of a shared layer that lets you answer “which agent, with what permissions, at what cost, and to what effect”.
How to spot agent sprawl in your organisation
Answer these questions:
- Can you list every AI agent and assistant running in your organisation? If not - you have sprawl.
- Does every agent have an owner and a documented permission scope? If an agent has access to data and nobody knows exactly which data - that is a risk.
- Is there a shared way to govern them? Does a new agent go through any approval process before it reaches production?
- Can you see the cost of each agent separately? Without tagging and cost attribution - you cannot.
- Do sensitive actions require human approval (human-in-the-loop)? Can an agent take an irreversible action on its own?
- Can agents communicate with each other in a controlled way? Or is each one an island?
If you answered “no” or “not really” to most of these - it is not a crisis yet, but it is the right moment to introduce governance. It is cheaper to do at three agents than at thirty.
Why agent sprawl happens
The same mechanisms as cloud sprawl, in a new form:
1. Democratised agent building
Agent frameworks and managed runtimes mean a working agent takes days to build, not months. That is an advantage - until there are no rules of oversight. Then every team builds its own way.
2. Team silos
The product team picks one provider. The data team self-hosts with local models. The operations team does something in between. Nobody coordinated the decisions, because each was solving its own urgent problem.
3. Pressure to ship AI fast
“We need AI” as a business goal pushes toward fast, isolated deployments. Governance, observability, and cost control get deferred “until later” - exactly like resource tagging during a cloud migration.
4. No platform owner
With cloud sprawl, what is missing is a FinOps owner. With agent sprawl, what is missing is an agent-platform owner - someone accountable for the shared way of building and governing, rather than for a single use case.
How to bring agent sprawl under control - an action plan
The pattern mirrors bringing cloud sprawl under control: see it first, then assign owners, then introduce governance. Start with an inventory, not with rewriting everything.
Step 1: Inventory your agents
You cannot manage what you cannot see. Make a list:
- Every AI agent and assistant (including the “experimental” ones that made it to production)
- The owner of each (which team, who is accountable)
- What data and tools each one can access
- What framework and runtime each runs on
- What each one costs (if that is even known)
Step 2: A shared governance layer
Instead of three ways of authenticating, authorising, and logging - one. A minimum set of shared rules:
| Area | Rule |
|---|---|
| Identity | Consistent permission propagation - the agent acts with the user's identity, not with its own over-broad permissions |
| Least privilege | Each agent has access only to what it needs - not to the whole warehouse "just in case" |
| Human-in-the-loop | Sensitive and irreversible actions require human approval |
| Agent registry | A new agent must be registered and approved before it reaches production |
| Tagging and cost | Every agent tagged with an owner and cost centre - just like cloud resources |
Step 3: Observability and cost control
Once a shared layer exists, you can answer the questions that are impossible under sprawl: which agent burns the most tokens, which takes the most actions, which costs the most, and whether it delivers value. This is the same showback model we apply to cloud FinOps - just applied to agents.
Step 4: Consolidate, don’t build a fourth system
The point is not to throw away three working systems. The point is to bring them onto a shared platform - one way to build, govern, and observe - and stop building every new use case from scratch. A rarely used tool is often worth keeping as a feature on the platform while retiring it as a separate system.
Where this is heading - platforms for governing agents
The market is starting to answer agent sprawl with shared platforms. In July 2026 AWS released Loom in AWS Labs, an open-source reference platform built on Bedrock AgentCore (the managed runtime) and the Strands Agents framework, with an agent registry, consistent identity, and enforced tagging. It is a signal of direction: agent governance as a layer, rather than something each team does its own way.
We will come back to the details of Loom and AgentCore in separate articles - here the conclusion matters more than the specific tool: you need a shared governance layer before the number of agents grows. The choice between an off-the-shelf platform, adapting one, or a lighter home-grown approach is a separate architectural decision.
If you are building the infrastructure underneath agent systems, it is also worth reading about agentic AI infrastructure on Kubernetes and about choosing between Bedrock, SageMaker, and self-hosting.
When it is worth bringing in an external partner
You can introduce agent governance yourself. But in a few scenarios an outside perspective is more valuable:
- Many teams, many frameworks - consolidation needs a neutral party that does not favour any of the existing systems
- Agents with access to production data - designing the identity layer and least-privilege takes cloud-security experience
- No platform owner - nobody inside is accountable for a shared way of building agents
- Regulatory pressure - audit, accountability, and logging of agent decisions ahead of ISO/SOC 2
Consolidating AI agents onto one platform?
We help teams bring order to AI agents on AWS - governance, cost control, and architecture built on Bedrock AgentCore. We start with an assessment of the current state and a target plan. Book a call or Send us a message.
Summary
Agent sprawl is next-generation cloud sprawl: the same organisational mechanism (ease of creation + no oversight), but with a higher stake, because agents have access to data and take actions. The earlier you introduce a shared governance layer, the cheaper it is - at three agents it is tidying up, at thirty it is a remediation project.
The three most important things to do next week:
- List every AI agent running in your organisation - including the “experiments” that made it to production
- For each, establish an owner and the scope of its access to data and tools
- Decide who is accountable for the shared agent platform - before a fourth system gets built the old way
