We’re continuing our series on what really breaks when AI agents move from demos to production.
Part 1: Communcation Failure: Why Agent-to-Agent Communication Fails
Part 2: Contract Failure: Why AI Agent Handoffs Fails
Part 3: Context Failure: Your Agent Isn’t Hallucinating…
Part 4: Evaluation Failure: Evaluating AI Agent Handoffs
Today in we explore Agent Sprawl - why using too many agents become a nightmare.
👉 Request: I'd love to hear from you. Take the short survey at the bottom of this article and tell me what you'd like to learn more about.
There is a moment in almost every agent architecture where the diagram starts looking impressive.
It begins simply:
User → Agent → Tools
Then someone asks:
“What if we add a planner?”
So it becomes:
User → Planner → Agent → Tools
Then:
“What if we add a researcher?”
Now we have:
Planner → Researcher → Analyst → Executor
Then someone adds a critic.
Then a reviewer.
Then a verifier.
Before long, the architecture looks like this:
It looks sophisticated.
It looks like a system built for serious work.
But there is an uncomfortable question we don’t ask often enough:
Did we actually make the system better?
Or did we just create six systems we now have to operate?
Every agent is another boundary
Adding an agent doesn’t just add another capability.
It adds another system boundary.
And every boundary creates work.
A new agent usually means:
another context boundary
another handoff
another interface
another failure mode
another thing to evaluate
another component to observe
another source of latency
another source of cost
And the problem compounds.
Imagine a simple workflow:
Agent A → Agent B → Agent C
Agent A produces something that B needs to understand.
B transforms it and passes something to C.
Now suppose A is changed.
The output changes slightly.
B still works.
Its own evaluation still passes.
But C starts failing because B’s interpretation of A’s output has changed.
Nothing is necessarily “broken” inside any individual agent.
The boundary is broken.
This is exactly the kind of problem we’ve spent decades dealing with in distributed systems.
Except now the components aren’t deterministic services.
They are probabilistic systems interpreting language, context and intent.
That’s a very different kind of boundary.
Agent Sprawl
This is Agent Sprawl.
It is the tendency to turn every capability into another autonomous agent without first proving that the boundary adds value.
It is the agent equivalent of creating a microservice for every function in a codebase.
Microservices taught us an important lesson:
Decomposition is not automatically architecture.
You don’t create a service because you just can.
You create one because a boundary gives you something valuable.
Perhaps it gives you:
independent scaling
independent deployment
ownership
security isolation
fault isolation
a different data lifecycle
The same principle should apply to agents.
The question should be:
“What boundary does making this another agent give us?”
Not every role needs to be an agent
Consider a research workflow.
You might design it as:
Planner → Researcher → Analyst → Critic → Reviewer → Writer
That’s six agents.
But perhaps the actual requirements are much simpler.
The planner might just be a structured planning step.
The researcher might be a tool-calling capability.
The critic might be an evaluation step.
The reviewer might be a deterministic validation process.
And perhaps only the analyst and writer actually need autonomous reasoning.
Suddenly the architecture becomes:
Planner (strutured code) → Researcher (tool call) → Analyst → Critic (Eval)→ Reviewer (coded validation) → Writer
That’s not necessarily less sophisticated.
It may be more engineered.
The mistake is assuming that every logical role in a workflow deserves an autonomous identity.
A function isn’t automatically an agent.
A prompt isn’t automatically an agent.
A tool isn’t automatically an agent.
A validation step certainly doesn’t need to become an agent just because an LLM could perform it.
The best agent architecture usually has fewer AI agents.
So when should you create another agent?
I use a simple test.
A new agent should introduce at least one meaningful boundary.
The following framework helps:
1. Capability boundary
The new agent does something fundamentally different from the existing agent.
For example, a specialised coding agent may have different reasoning patterns, tools and execution environments from a customer-service agent.
2. Data boundary
The new agent operates on a different data domain or requires different access.
For example, separating customer-facing reasoning from an internal risk-data environment may be a meaningful boundary.
3. Authority boundary
The new agent has a different level of permission.
An agent that recommends a transaction and an agent that can actually execute it may need to be separate because their authority is fundamentally different.
4. Failure-isolation boundary
The new agent can fail independently without taking down the rest of the workflow.
This can be particularly valuable for expensive or unpredictable operations.
If creating the agent doesn’t give you one of these boundaries, ask yourself why it exists.
Maybe it shouldn’t.
The hidden cost of adding another agent
Suppose a customer asks:
“Can I increase my credit limit?”
The request passes through:
Router → Customer Agent → Policy Agent → Risk Agent → Decision Agent
The final answer is wrong.
Where do you look?
The model?
The prompt?
The context?
The handoff?
The policy?
The retrieved data?
The risk calculation?
The decision?
The interaction between two of them?
The more agents you add, the more possible places there are for something to go wrong.
And importantly, the failure may not belong to any one agent.
It can emerge between agents.
That’s the real cost of decomposition.
Not just more boxes.
More arrows, more interactions.
The architecture diagram hides this
This is where agent architecture can become deceptive.
On the diagram, adding another agent is easy.
You draw another box.
Connect with arrows.
Done.
But the production system doesn’t see boxes.
It sees:
state
context
messages
permissions
tool calls
timeouts
retries
model versions
handoffs
failures
evaluations
And humans trying to figure out what happened when the workflow produced the wrong answer.
The diagram gets more impressive.
The operating model gets harder.
That’s why I think we need to change how we talk about multi-agent architecture.
The goal shouldn’t be to maximise the number of agents.
The goal should be to create useful boundaries.
Decompose for boundaries
The same principle applies whether you’re designing microservices, data platforms or agentic systems.
A boundary should earn its place.
If it gives you independent capability, data isolation, authority separation or failure isolation, it may be worth the complexity.
If it exists because someone thought:
“Wouldn’t it be cool if we had another agent?”
It probably doesn’t.
Because every agent you add creates another system boundary you now have to operate.
And eventually, the question stops being:
“How many agents do we need?”
It becomes:
“How many boundaries can we afford to operate?”
That’s a much more useful architectural question.
See you in Part 6, where we'll look at Decision Blindless
If you are interested in multi-agent system architectures, you might like this video.
One request:
Your answers will directly shape the next quarter of AgentBuild issues. This isn’t a formality - I’m genuinely building the next stretch of this newsletter around what you tell me. I don’t want to make assumptions. Tell me what you want to learn.
👉 Take the survey here
Thanks for reading,
Sandi
P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.
Ask your friends to join.
More valuable content coming your way.