AI Agents Are Repeating the Microservices Trap
Splitting work into smaller pieces makes the system look cleaner, but the real complexity needs to be in the handoffs
A recent 2026 study of production agents found that 68% execute at most 10 steps before needing human intervention, and 74% still depend primarily on human evaluation.1 Another industry study found only one of twelve companies had reached a multi-agent orchestration maturity level.2 The implication is that agents still can’t operate broadly without human touches.
In the real world Moltbook showed more than 1.5 million agents on the platform just four days after launch. Moltbook is not enterprise software, but this is still a useful signal of the moment we are in.
The pattern is pretty clear: agents are becoming easier to create than they are to govern.
My working theory is that we are creating agent workflows the way many teams thought about microservices: give each piece a specific role, put it inside a defined boundary, let it do one job well, connect the pieces together, and call the result architecture.
The appeal of microservices was they made large applications easier to reason about once teams split it into smaller services. Each service could own a clear job and teams could move independently. This architecture looked more scalable, more modern, and more adaptable to whatever came next.
The lesson came later3: Splitting the system apart made the boundaries visible but actually operating across those boundaries required real changes to discipline: contract testing, observability, deployment patterns and support that the architecture diagram doesn’t have.
This lesson is one that agent teams should take note of: breaking a system into smaller parts does not remove complexity. It moves complexity into the relationships between the parts.
My argument is that multi-agent systems are heading toward the same challenges. The case rests on four claims:
Agent creation is getting easier faster than agent operation is becoming reliable.
Multi-agent systems create collaboration costs because agents pass interpretation, not just data.
Handoffs between agents are where governance needs to focus.
The response should reinforce trust in the system, not just make the architecture look organized.
If these hold, the lesson from microservices becomes useful again: boundaries only help when the operating discipline around those boundaries is strong enough to reduce coordination instead of hiding it.
Decomposition Is Not Maturity
Agents are useful, and multi-agent systems will probably become a normal part of how software teams work. The mistake is assuming that more agents means the system is becoming more mature or efficient.
Agents make decomposition cheap. They do not make coordination cheap.
That is the real microservices lesson. A service boundary is only useful when the contract across that boundary is understood. Agents have the same problem, but the boundary is softer because they pass interpretation, not just data.
A mature agent system doesn’t need every internal step exposed in the way microservices might. But it does need important handoffs to be legible enough that the team can answer why a result was trusted and how they know.
The test of maturity is whether trust is built into the agent’s role in the system, or rebuilt manually after each meaningful output. Without trust, more agents will produce more work and humans still have to spend more attention deciding whether that work is safe to rely on.
1. Agent Creation Is Getting Easier Faster Than Agent Operation Is Getting Reliable
One agent failing inside a narrow workflow may be fine. The blast radius is small and annoying but not significant.
But when there are five, ten, or twenty agents working across different environments where do you set the boundary when a critical output is the context and interpretation? Every boundary means an expected handoff, and every handoff creates a trust decision.
One common use case is using agents to orchestrate discovery-to-delivery work: synthesizing customer conversations, identifying opportunity areas, shaping recommendations, and translating those recommendations into delivery work.
How do you ensure the research agent preserves uncertainty from customer interviews? How many things need to go right before you can trust the recommendation of a reasoning agent? When does a summary become evidence? When does a recommendation become a requirement?
That is the operating gap I see. Agent creation makes the chain easy to build but agent operation has to make the chain safe to rely on.
2. Multi-Agent Systems Create Collaboration Costs
This is why decomposing a system is not maturity: once agents start passing interpretation to each other, the system’s real complexity moves to the collaboration layer.
Here’s where the microservices comparison gets sharper when you look closely at the handoffs.
A service will accept a formatted request and return a specific response explicit enough to inspect in case of failure. An agent reads context, makes judgments, chooses tools, and produces artifacts. That makes failure harder to manage because the failure may not look like something’s broken.
If a payment service fails, there is an error you can trace from service to service through logs. If a research agent misreads three customer interviews, a planning agent turns that into a confident recommendation, and a backlog agent transforms the recommendation into work, there is no error. No observable failure. It looks the same as success.
The collaboration cost is the cost of interpretation moving through the system.
One agent’s “good enough” summary becomes another agent’s source of truth. One agent’s assumption becomes another agent’s requirement. One agent’s missing context becomes another agent’s confident next step. By the time a human sees the result, the original uncertainty has been laundered through several layers of plausible output.
The more agents you add, the more the system depends on the relationships between them.
That is where the architecture diagram can mislead you. Boxes look clean and the arrows look simple. But the real operating question lives inside the arrows. Who owns this handoff? What does success vs failure look like? What confidence is required? What should stop the chain? How does the downstream agent know the difference between evidence, inference, and a polished guess?
The more agent boundaries you create, the more trust decisions the system has to manage. That is why the next problem is not creating more agents, it’s governing the handoffs between them.
3. Handoffs Between Agents Are Where Governance Needs to Focus
Yesterday’s question was whether we could make an agent do a task. Today’s question is whether an agent should be allowed to do that task.
That is the shift from agent building to agent governance. Once agents start passing interpretation through a system, the important work is deciding what each agent is allowed to know, what it is allowed to do, what evidence it owes, and what happens when it is wrong. That means the next layer of maturity is governance, not more agent-building.
For me this is where the microservices comparison starts to diverge and the idea of an agent control plane starts to make sense, as long as we keep it grounded.
A useful control plane should focus on results, not only activity. It should make each agent’s operating responsibility clear.
In the product-team example, the control plane should help the team see when a story-writing agent depended on an outdated roadmap summary, when a research summary carried low confidence, when acceptance criteria were generated from inferred user behavior rather than observed evidence, and when no one reviewed the handoff before work entered delivery.
Most large organizations already struggle to keep moving pieces coherent under pressure. Agents make that harder because the moving pieces can now produce language that sounds more complete than the underlying reasoning may be.
4. Don’t Overcorrect Into Premature Architecture
The obvious response to messy agent coordination is to add more structure.
This was my first response too. If agents need context, why not model everything? Every document, decision, roadmap item, assumption, dependency, and workflow should get a node. I thought that if I understand the system first before connecting agents, it would be legible enough to trace failures and successes.
But that risks repeating the microservices mistake too.
Microservices became most useful when the service boundaries reflected real operating pressure with clear contracts, known dependencies, observable failures, ownership, and deployment discipline. Effective microservice architecture works when practices complement the technology.
Agent systems will be similar. A knowledge graph, vector database, or control plane is only useful if it makes the agent system easier to trust, operate, or correct.
This where AI changes the old product instinct that seeks structure. A strong model can often pull useful signal out of rough material. It can tolerate a bad filing cabinet better than traditional software could. So this tells us that not all knowledge needs to be perfectly structured before agents can work. The goal is to add structure where failure, trust, or ownership matters.
This Is Product Discipline, Not Just Infrastructure
It is easy to treat all of this as an infrastructure problem. In one sense, it is. Someone has to build the systems that deploy, observe, evaluate, govern, and manage agents. But like microservices, agent systems will work when practices complement the technology.
The same is true for evaluation. For example, AI evals are often talked about as a technical quality gate, and they are partly that. But they also define harder questions like what “good” means in the workflow. The evaluation has to match the responsibility.
These aren’t only feasibility questions, they’re operating questions. That’s why product people, designers, engineers, and leaders all belong in this conversation. The question we are asking is no longer whether the agent works but if the organization understands what kind of work it has allowed the agent to perform.
Our Systems Still Need to Know What to Do With The Mess
Microservices taught us that smaller parts can make a system easier to build and harder to operate. Agents may do the same thing to AI work.
A multi-agent system might look mature because every agent has a role, but the real maturity lives in the handoffs and trust boundaries. It will be successful when the organization can trust what happens after agents start interacting with real work.
That is why I can’t see “more agents” being a real answer at the Enterprise level until teams can operate the agent ecosystems they already have.
Your AI operating system might involve a graph. It might involve a control plane or evals, provenance, permissions, ownership rules, or better handoff contracts. At the moment, all are valid ideas. But the form matters less than the discipline it creates.
Building the agent is the easy part now. Owning what it does next is the work.
https://arxiv.org/abs/2512.04123
https://arxiv.org/abs/2605.14675
https://www.pyyne.com/post/the-microservices-trap-why-your-next-project-shouldn-t-start-distributed