In February 2026, Notion shipped Custom Agents. The pitch: build autonomous AI agents for different tasks. A research agent. A triage agent. A status report agent. Give each one a job, set a trigger, let it run. Within weeks, early testers had built over 21,000. Notion itself now runs more agents than it has employees.
Every major platform is shipping the same thing. Let teams create specialised agents for their specific needs. For the average large organisation, that means fifty or more.
The enthusiasm is warranted. Agents that automate triage, surface patterns in customer feedback, and compile status reports represent genuine operational gains. But the architecture emerging around them is one we have seen fail before, in at least three previous waves of enterprise technology. What happens when fifty teams each build their own agent, optimised for their own task, drawing on their own data? What happens when those agents need to hand off to each other, share context, or reconcile conflicting instructions?
What happens when nobody owns the joins?
The history of enterprise technology is a history of locally rational decisions producing globally incoherent outcomes.
SaaS proliferation followed this script. Each department adopted the platform that best served its needs. Each adoption was defensible in isolation. Collectively, the average enterprise now runs hundreds of SaaS applications. Customer data lives in dozens of systems that cannot agree on what a customer is. Integration costs routinely exceed the value individual tools deliver.
Data architecture followed the same script. Each function built its own reporting pipeline, its own definitions. The same metric, three different answers, one meeting.
Organisational processes followed it too. Each team designed its handoffs for its own convenience. Customers experienced those joins as friction: explaining their situation for a third time, discovering that one part of the organisation did not know what another had promised.
The cause is consistent across all three. Each failure wave was produced not by bad intentions but by incentive structures that rewarded the local and ignored the global. The team that adopted the SaaS tool was measured on its adoption. The team that built the data pipeline was measured on its delivery. Nobody was measured on whether the joins worked. When the cost of fragmentation arrived, it arrived in a column nobody's performance review tracked: friction for customers, frustration for colleagues, structural debt that compounded silently.
A capability was distributed to teams. The investment in how those capabilities connect never arrived. Local optimisation was incentivised. Global coherence was assumed. The joins were left undesigned.
Agent sprawl is the newest iteration of this pattern, arriving faster than any previous version, because building an agent is now easier than subscribing to a SaaS tool. You describe what you want in plain language. The system builds it.
The ease of creation is the feature. It is also the risk. The lesson from every previous wave is the same: if you do not design the joins at the point of creation, you will pay to retrofit them later, at multiples of the original cost.
Consider a financial services firm that has embraced agents.
The product team builds one to monitor app store reviews. Operations builds one to triage incoming support requests. Compliance builds one to scan communications for regulatory risk. Marketing builds one for campaign performance. HR builds one to field employee policy questions. IT builds one for first-line technical support.
Six agents. Each well designed for its task. Each a local success.
Now a customer writes an app store review about a confusing fee. The product agent flags it as a UX issue. Operations, receiving the same customer's call, classifies it as a billing query. Compliance, scanning the same interaction, flags a potential disclosure failure. Three agents, three interpretations, three functional owners. No shared view of what the customer experienced, and no mechanism to connect these readings to the structural failure that produced the problem.
The customer does not experience three agents. They experience one organisation that cannot give a coherent account of itself.
Writing in CIO magazine in February 2026, Ritu Jyoti put it directly: "When your marketing agent, supply chain agent, and HR bot all operate in silos, you don't have an automated workforce; you have a digital riot." By solving the plumbing problem so effectively, agent tooling has removed the natural brakes that used to force governance conversations. Manual integration friction slowed adoption to the speed at which governance could keep up. That brake is gone.
In 1967, Melvin Conway observed that organisations are constrained to produce system designs that mirror their own communication structures. The principle has been tested across decades of enterprise technology. It holds.
Agents are built by teams. Teams are organised by function. Functions have their own data, priorities, metrics, and incentives. When a team builds an agent, it encodes all of this. The agent does not transcend the organisational structure. It encodes it. It makes the org chart executable.
But this is only half the diagnosis. The other half is incentive design. Conway's Law explains why the structure replicates. Incentives explain why nobody fixes it.
The team lead who flags a cross-functional architecture problem takes on political risk for a system-level gain that will not appear in their performance review. The team lead who ships an agent on time, within scope, on budget, gets rewarded. The incentive system is not broken. It is working exactly as designed. Its design produces fragmentation. Every individual making a locally rational career decision collectively produces an architecturally irrational outcome.
This is not a technology problem that better tooling will solve. It is an organisational design problem. If your teams do not share data, your agents will not share data. If nobody owns the customer journey across functions, no orchestration layer will own the agent journey. If your incentive structures reward local optimisation, your agents will optimise locally, because they were built by people who are rewarded for optimising locally.
Complaints cluster around handoffs between channels, around moments where the customer must provide information the organisation should already hold. These seams persist because nobody owns the gaps between functions, and because nobody is measured on closing them.
Agent sprawl does not close these gaps. It replicates them in a new medium and makes them harder to see.
The analogy between human silos and agent silos breaks down in one important way. When a human process fails at a seam, someone usually notices. A customer complains. A colleague flags it. The feedback loop is imperfect but at least partially self-correcting. Agent architectures have no peripheral vision. An agent will produce a subtly inconsistent output, hand it to the next agent in the chain, and neither will flag the discrepancy. The failure is silent, and it compounds silently.
Fixing your agent architecture requires confronting your organisational design first. There is no technical workaround.
In every system, complexity exists. The design question is who absorbs it.
In most organisations today, the customer absorbs the complexity of internal silos. They explain their problem to a third person. They are told "that is a different department." They discover the app says one thing and the branch says another. The organisation has exported its structural incoherence to the customer and called it a service model.
The colleague absorbs it next. Frontline staff spend their days navigating workarounds for problems they did not create, apologising for contradictions between systems and policies that no one has bothered to reconcile.
With agent proliferation, the user is being asked to absorb the complexity of the AI architecture itself. They must decide which agent to use, when. They must understand which agent holds which capability, which data, which limitations. They must route their own requests to the right specialist. A team of fifty people maintaining a mental model of hundreds of agents is not empowerment. It is a design failure distributed to the person in the chair.
Suff Syed of Microsoft put it plainly when Notion launched its Custom Agents: "One assistant. Many skills. Zero overhead for the human in the chair."
That is the principle. The customer should not need to understand your org chart to get help. The user should not need to orchestrate your agents to get work done.
Before you ship the next agent, ask: who is absorbing the complexity this creates? If the answer is the user, the design is wrong.
The case for specialised agents is real.
Specialisation enables depth. A generalist agent asked to handle research, writing, triage, and project management will do each adequately and none well. Modularity enables evolution: you can swap one capability, upgrade another, add a third, without re-engineering the whole system.
Security boundaries also create legitimate architectural reasons for separation. In regulated industries, a compliance agent and a marketing agent may need structural isolation not because of organisational convenience but because of legal necessity.
The performance data is genuinely mixed. On parallelisable tasks, coordinated multi-agent systems materially outperform single agents. On tasks requiring sequential reasoning, the same multi-agent approach can degrade performance significantly. The right architecture depends on the shape of the work.
What is in dispute is where the boundary between specialised capabilities and user experience should sit. The advantages of specialisation are architectural. They belong behind the interface. The mistake being made is exposing the architectural decomposition as the product. You can have specialised sub-agents behind a unified orchestration layer. You can have security boundaries the architecture enforces without requiring the user to know which agent sits inside which boundary.
The engineering principle and the experience principle are not in conflict. They are in tension only when the engineering abstraction is shipped unmediated to the user.
Organisations accumulate design debt the same way software accumulates technical debt. Every policy written for internal convenience, every handoff that drops context, every channel operating from a different version of the truth adds a small amount of friction. Individually minor. Collectively, an experience that feels disjointed and untrustworthy. And it compounds.
Agent sprawl is design debt at machine speed.
An agent built without an orchestration layer is a future coordination cost. One drawing on its own data source is a future consistency failure. An agent-to-agent handoff that drops context is a future trust failure. An agent without clear ownership is a future governance vacuum.
The compounding is faster because creation is faster. An organisational silo takes months or years to calcify. An agent can be built in an afternoon.
The compounding is also more opaque. When a human team produces an inconsistent outcome, there are ambient signals: a confused customer, a frustrated colleague, a manager who senses something is off. Agent architectures have no peripheral vision. An agent will continue operating, producing plausible but subtly wrong outputs, with no mechanism to sense the conflict.
The governance gap does not show up as a single catastrophic failure. It shows up as a series of small, confusing incidents where the dashboards are green but the business outcome is wrong. One enterprise deployed a procurement agent and a pricing agent with conflicting objectives. The procurement agent, seeing low stock, over-ordered high-value components. The pricing agent, seeing the incoming surplus, slashed prices. The cost: $2 million in premium freight to ship goods they were effectively selling at a loss.
Neither agent made an error within its own logic. The error was architectural. Nobody owned the join.
This argument ends, as the others did, on trust.
Trust is the confidence that a system will behave predictably, even under conditions you cannot directly observe. It resolves into four testable properties: consistency, transparency, reliability, and recoverability. An architecture produces them, or it does not.
Agent sprawl threatens all four.
Consistency fails when the same customer query routes to different agents with different data and different optimisation targets. The inconsistency is a property of the system, not a failure of any component.
Transparency fails when a decision passes through multiple agents, each applying its own logic. Explaining that decision becomes archaeology. No single agent understands the full chain.
Reliability fails when promises depend on agent-to-agent handoffs that were never designed with the same care as the agents themselves. Promises break at the joins.
Recoverability fails when ownership of errors falls between teams, just as it falls between functions in a siloed organisation. The team that built the agent, the team that provided the data, the team whose process depends on the output: each points to the others. The customer waits.
AI has no skin in the game. It cannot be held responsible, lose its job, or feel the weight of a bad decision. When a human colleague makes an error, social and professional accountability create pressure toward correction. When an agent makes an error, that pressure does not exist. It will continue to operate exactly as instructed, compounding the error until a human intervenes. Trust under agent architecture depends entirely on the governance humans design around it.
Across the FCA, CBUAE, and MAS, the same signal is emerging: autonomous AI in regulated processes is a governance question, not merely a technology question. The organisation that goes to its regulator and says "here is what we are building, here is how it is governed, here is what we can demonstrate" owns the conversation rather than reacting to it.
Using regulatory uncertainty as a reason for architectural timidity is the oldest mistake in this industry. The people who benefit from that uncertainty are almost always inside the institution, not inside the regulator. Compliance built on ambiguity is not compliance. It is a postponed conversation, with compounding interest.
The alternative to agent sprawl is not fewer agents. It is intentional architecture.
One relationship, many capabilities. The user interacts with a single coherent interface. Behind that interface, specialised capabilities are orchestrated by the system. The assistant manages the agents. The user manages the assistant.
A governed data layer. Every agent that touches customer, operational, or decision data should operate from a consistent, governed foundation. Agents reading from different sources must not produce contradictory outputs. The fragmentation that currently afflicts enterprise data estates will produce the same fragmentation in agent outputs, at speed, if left unaddressed.
Seam owners with authority. Someone must own the joins between agents, with the mandate to make design decisions that span multiple agents, data sources, and functional boundaries. Not a coordinator. An owner who can change the architecture where it fails. Without this, the joins will be designed by default, which means they will not be designed at all.
Federated orchestration with shared governance. The design question is not "centralised or federated?" It is: does the orchestration produce consistent, explainable, reliable, recoverable outcomes, regardless of which agents are operating underneath?
Lifecycle discipline. Every agent should have a clear owner, a defined purpose, a measured impact, and a planned retirement. Creation without lifecycle management produces redundancy, overlap, conflict, and rising cost.
A governance conversation on the right time horizon. Agent architectures compound over years. Quarterly cycles cannot hold that conversation. The organisations that built data governance seriously a decade ago are not untangling it today. The ones that did not are still paying. The same logic applies here, on a faster clock.
Confront the speed trade-off. The executive objection is predictable: move fast and fix the joins later. The answer is direct: the SaaS era proved that "fix it later" means "pay for it permanently." The data silo era proved the same. The window for architectural intentionality is still open for most organisations. It will not stay open long.
Complaints showed us the seams in the first generation of process design. Trust showed us what it cost when those seams were left unaddressed. Agent architecture is the third iteration of the same problem, arriving faster, at scale, with less peripheral vision and fewer natural brakes.
Organisations now have a narrow window to design their agent estates the way they should have designed their organisational estates: with the joins specified, the complexity absorbed, the data governed, the accountability assigned, the planning horizon set, and the regulatory conversation started.
Most will not take it. They will build agents the way they built SaaS estates, data pipelines, process handoffs: function by function, team by team, each one locally rational, collectively incoherent. The cost will arrive in the same currency it always does: friction for customers, frustration for colleagues, erosion of trust, structural debt that compounds faster than it can be serviced.
Some will see it differently. They will recognise that agent architecture is organisational design made literal, and that the same principles that govern good service design and sound trust architecture apply with equal force to how agents are composed, orchestrated, and governed.
Those organisations will not have zero failures. They will have an architecture that learns from failures and closes the seams before they compound.
That is the difference between agent deployment and agent design. It will be visible, soon, in the distance between the firms that designed the joins and the firms that did not.