AI Agents Are About to Recreate the Integration Problem
Enterprise architecture has spent the best part of twenty years trying to get rid of spaghetti. Then Agentic AI arrived and apparently ordered extra parmesan.
One agent is easy enough. Give it access to a few systems, connect some APIs, add an MCP server, teach it where the useful data lives and give it the appropriate permissions. Very impressive.
Then another team builds another agent. And another.
Six months later, somebody opens the architecture diagram and discovers that twelve highly intelligent AI agents have each independently developed their own personal relationship with SAP.
Progress.
This is one of the less glamorous problems I think we are about to run into as enterprise AI starts moving beyond isolated pilots. Not agent sprawl on its own, but the integration sprawl quietly forming underneath it.
One agent doesn’t look like an architecture problem
This is why it is easy to miss.
Imagine a disruption-management agent at an airline. It needs aircraft position, crew availability, passenger connections, airport restrictions and maintenance status, so the project team connects those systems.
Perfectly reasonable.
Somewhere else, another team builds a crew-planning agent. It needs aircraft position, crew availability, airport restrictions and training records, so they connect those systems too.
Then somebody builds a passenger-recovery agent. That one needs aircraft position, passenger connections, airport restrictions, hotel availability and ground transport.
Another set of integrations.
Before long, we have several agents asking many of the same systems many of the same questions through slightly different pipes. And, because enterprise software enjoys a sense of humour, they may not even agree on the answers.
One agent thinks a crew member is available because they are not currently assigned. Another knows they are technically available but would breach duty-time rules if used. A third has helpfully decided this is a semantic issue and written a very persuasive paragraph about it.
Everybody has done their job.
Nobody has integrated the business.
We’ve seen this film before
This is basically the old point-to-point integration problem wearing an AI badge.
System A connects to System B. System B connects to System C. Then D arrives. Then E. Eventually you get the famous architecture diagram that looks less like a technology strategy and more like somebody dropped a bowl of noodles onto PowerPoint.
We spent years replacing that pattern with integration layers, event architectures, APIs, shared data models and governed platforms.
Now there is a risk that we quietly recreate it one agent at a time.
Databricks is already using the term AI sprawl and warns that when teams wire agents independently, organisations start accumulating duplicated integrations, fragmented context and inconsistent controls. Databricks: How to scale agentic applications without creating AI sprawl
Microsoft is making much the same point from the governance side. Without a common process and architecture, agent adoption can create inconsistent designs, security gaps and technical debt across the organisation. Microsoft Cloud Adoption Framework: building agents across the organisation
So the problem is starting to get noticed.
I think there is another layer underneath it.
Every new agent can potentially become another integration project.
The really dangerous bit isn’t the number of connections
Connections are annoying.
Different versions of business truth are worse.
Suppose four agents all need to understand a supplier. The procurement agent cares about contracted terms, delivery performance and current capacity. The finance agent cares about payment status and exposure. The operational agent cares about whether the supplier can actually deliver next Tuesday. The compliance agent cares about things everybody else would probably rather discover before the goods arrive.
They may all reach into roughly the same estate, but if each project independently decides which source is authoritative, how supplier identities are matched, what “active” means, how quickly changes need to propagate, which exceptions matter, which history to retain and how conflicting records should be resolved, then we haven’t created four views of the same business.
We have created four businesses.
This is where agent architecture starts becoming a data architecture problem again.
MCP helps. It doesn’t make this disappear.
MCP is genuinely useful here.
Instead of building a bespoke interface between every model and every application, we can expose tools and resources through a common protocol. That removes a lot of plumbing.
But a standard connection does not automatically create a standard understanding of the enterprise.
We covered this in our earlier piece on MCP, AI Agents and Live Enterprise Data.
MCP can help the agent reach something. It does not decide which of three conflicting records represents reality. It does not resolve the supplier that exists as SUP-8831 in one system, 004718 in another and, for reasons lost to history, SMITH_NEW_FINAL2 somewhere else.
Nor should it.
That is not what the protocol is for.
The same applies to agent frameworks. They are getting much better at orchestration, tool selection, memory, planning and agent-to-agent communication.
Excellent.
None of that removes the rather mundane requirement to integrate the enterprise underneath them.
Otherwise every agent starts learning the plumbing
There is an architectural smell I think we should watch for.
The agent prompt starts filling up with integration logic.
“If System A says X but System B says Y, prefer System A unless field Z is populated. If the identifier begins with 7, query the old application. If no current record exists, try this API. If API 1 times out, query database 2. If those disagree, use the timestamp from system 3.”
At that point our highly sophisticated reasoning agent has somehow become middleware.
Very expensive middleware.
With opinions.
An agent should not need to understand twenty years of enterprise plumbing simply to answer a business question.
That logic is usually deterministic. We already know how to engineer it: identity resolution, state management, mappings, CDC, schema handling, data quality, reconciliation, exception processing and lineage.
Those things should not have to be rediscovered every time somebody creates a new agent.
This gets more interesting at agent scale
Humans are comparatively polite users of enterprise systems.
We click things. We wait for screens. Occasionally we go for coffee.
Agents are less considerate.
A single request can fan out into several database lookups, tool calls, APIs and downstream actions. Google has warned about exactly this effect: one agent request can generate multiple queries and actions across underlying infrastructure, creating load patterns very different from the human-scale workloads many systems were designed around. Google Cloud: Your AI agents are ready. Is your data?
Now multiply that by fifty agents and let them work overnight.
Suddenly that elderly operational database in the corner is having the busiest social life of its career.
AWS is already recommending adapter layers around legacy systems specifically to protect them from agent-native invocation patterns, with rate limiting and access controls sitting between the agent and the underlying application. AWS Well-Architected: Legacy system integration for agents
Again, very sensible.
But perhaps we can go further.
Instead of merely protecting every source from every agent, why should every agent need its own relationship with those sources in the first place?
Build the enterprise relationship once
This is where I think the architecture needs to separate two things: agent logic and enterprise integration logic.
They are not the same problem.
An insurance claims agent may reason very differently from an underwriting agent. That is fine. They may use different models, different prompts, different tools and different workflows.
Also fine.
But if both need policy state, customer identity, payment history or exposure information, there is no obvious prize for integrating those things twice.
The underlying production logic can be reusable. Resolve the entities once. Define source precedence once. Maintain current state once. Handle schema changes once. Apply the required quality rules once. Track lineage once.
Then expose the relevant slice of that governed context to whichever agent needs it.
Not necessarily the same data.
Not necessarily the same permissions.
But the same engineered relationship with the enterprise.
That is a very different architecture from giving every agent its own collection of connectors and hoping they all interpret the business consistently.
This does not mean everything needs another central platform
This is worth being careful about.
The answer to agent sprawl is not automatically: “Excellent. Let’s centralise absolutely everything.”
We have tried that before too.
Several times.
The data warehouse does not need to become the operational system. The lakehouse does not need to replace the ERP. The AI platform does not need to own every integration. And the production data layer should not become another giant destination into which the enterprise is forced to move.
The strategic platforms can stay strategic.
Microsoft Fabric can remain Microsoft Fabric. Databricks can remain Databricks. Snowflake can remain Snowflake. Operational systems can remain operational systems.
The question is what happens between them.
This is increasingly the role we see for IOblend.
Not another place to put everything, but a reusable production layer for the integration, state and governance work that would otherwise start appearing repeatedly around every application, platform and agent.
The current IOblend product architecture can handle batch, CDC and streaming while maintaining state, transforming and reconciling data, resolving entities, applying quality rules and retaining lineage across the estate.
For AI, that same layer can maintain a synchronised, governed context that multiple agents can use without each agent having to independently integrate the systems underneath it.
Different agents can still see different things.
That is important.
The finance agent does not automatically inherit what the HR agent can see simply because both consume the same production layer.
Shared integration does not mean shared access.
It means we stop solving the same plumbing problem from scratch.
The agent platform vendors know this is coming
What is interesting is that the large platforms are all moving towards some version of a shared foundation.
Databricks talks about common context, tools and controls. Microsoft talks about standardised agent architecture and governance. Google talks about moving from human-scale systems towards infrastructure capable of supporting agents operating continuously and at much greater scale.
That direction makes sense.
Where I think many enterprises will differ is that their business does not live neatly inside one platform.
It lives in SAP, Salesforce, Oracle, custom applications somebody wrote in 2009 and nobody is allowed to touch, a database underneath a factory, a SaaS application acquired with another company, three clouds, some files and, inevitably, one system called “Temporary” that appears to have been in production since 2014.
That estate isn’t going away because we bought an AI platform.
So the architectural question becomes less:
Which agent platform should own everything?
And more:
How do we give agents a consistent relationship with a business that already spans everything?
That is the more interesting problem.
There is also a very practical benefit
Once the integration logic is separated from the individual agent, changing agents becomes easier.
And agents are going to change.
Models will change. Frameworks will change. MCP will evolve. Agent platforms will consolidate, split, get renamed, acquire a new gradient logo and become “AI-native” again.
The underlying business will be considerably less impressed.
Customers will still be customers. Aircraft will still need to be in the right place. Invoices will still need paying. Machines will still break at inconvenient times.
The integration logic representing those things is likely to outlive several generations of AI tooling.
That logic is worth keeping independent and portable.
We should probably avoid building the same mess twice
The first generation of enterprise integration taught us something fairly useful.
Point-to-point works brilliantly until it doesn’t.
The first few connections are fast. The next few are manageable. Then every change has six dependencies, nobody is entirely sure which transformation owns the truth, and removing one interface requires an archaeological survey.
Agentic AI gives us a rare opportunity.
We can either rediscover that lesson at much greater speed, or remember it.
Because building one agent is getting easier. Building ten agents is getting easier. Building one hundred agents may soon be perfectly realistic.
But if every one of those agents arrives with its own connectors, mappings, definitions, credentials, retries and interpretation of the business, we haven’t created an intelligent enterprise.
We’ve created integration spaghetti with an LLM on top.
Very modern.
Still spaghetti.
And perhaps the simplest rule is this:
An agent should not have to integrate the enterprise while it is trying to reason about it.
