AI Is Driving an Integration Renaissance — And Most Teams Aren't Ready
The enterprise integration discipline that came of age in the 2010s is suddenly the most important capability in AI delivery. Most teams have under-invested. The bill is coming due.
After fifteen years building enterprise integration platforms — much of it on webMethods inside large delivery programmes — I have a perspective that's worth sharing about where the field is in 2026. The pattern is consistent across the engagements I'm leading: AI workloads are the most demanding consumers of enterprise integration capability we have ever had. The integration discipline that came of age in the 2010s is suddenly the most important capability in AI delivery. Most teams have under-invested. The bill is coming due.
This is a practitioner reflection on what AI is doing to enterprise integration — and what teams need to do about it.
What AI changed about integration
A few specific shifts:
Integration became a real-time concern again
Through the 2010s, much of enterprise integration was batch or near-batch. AI workloads need integration in real time. The latency budget is tighter; the consistency requirements are different; the operating model has shifted.
The integration teams that maintained real-time capability are in good shape. The ones that drifted toward batch-dominated operating models are struggling to support AI.
The integration surface multiplied
A conventional enterprise application integrated with maybe a dozen systems. An AI workload often integrates with twenty or thirty — every system whose data the model might draw on, every system whose action the model might take. The integration surface has grown substantially.
Read-side and write-side both matter
Conventional integration was often read-heavy (data flows in) or write-heavy (transactions flow out). AI workloads are heavy on both. The integration architecture has to handle both well.
Identity propagation is critical
The user's identity has to flow through every layer of AI workloads. Many enterprise integration platforms were built without strong identity propagation; they treated themselves as system-to-system. AI workloads need user-context-aware integration.
Audit is denser
Every interaction the AI has with a downstream system needs to be auditable. The audit infrastructure required for AI exceeds what conventional integration provided.
Standards are emerging
MCP, GraphQL adoption, OpenAPI maturation, OData usage. The integration patterns are standardising in ways they didn't before. AI is accelerating the standardisation pressure.
Where teams are under-invested
A few specific gaps I keep finding:
Real-time API surfaces missing
Many enterprises have rich batch integration but thin real-time API surfaces. The systems of record are accessible by batch and by direct database access, less so by API. AI workloads need APIs.
Identity propagation half-built
Identity flows from the user through the application; it doesn't always flow through the integration layer to downstream systems. The integration layer was built assuming system identity, not user identity.
Insufficient API governance
APIs exist; they're not always governed. Discovery is informal; documentation is uneven; versioning is patchy. AI workloads consuming these APIs accumulate fragility.
Observability gaps
The integration layer logs requests and responses; it doesn't always log enough to reconstruct what an AI workload was doing through the layer. The integration observability needs to be richer.
Performance bottlenecks at scale
AI workloads can produce sudden load on integration layers — a query that triggers fifty downstream calls; an agent loop that hits a system repeatedly. Integration capacity that was sufficient for conventional load gets overwhelmed.
Insufficient catalogues
The integration layer's catalogue — what services exist, what they do, how to use them — is often informal. AI workloads need machine-readable catalogues that LLMs and orchestrators can use.
What good looks like
The enterprises with well-functioning AI workloads have integration layers with specific properties:
Real-time everything
All systems of record accessible by APIs at acceptable latency. Batch is for analytics, not for AI workloads.
Strong identity propagation
The user's identity available at every layer; permissions enforced at the function execution layer; audit identity logged with every action.
API governance
A registry of APIs with descriptions, ownership, versions, examples. The registry is the source of truth; AI workloads can consume from it.
MCP servers where appropriate
For internal systems that AI workloads use, MCP servers expose them in the standard way. The integration surface is consumable by any MCP-aware AI client.
Observability at integration depth
The integration layer captures detailed traces that join with the AI workload's traces. The end-to-end picture is visible.
Capacity planning for AI load
The integration layer's capacity model accounts for AI workload patterns — burstiness, fan-out, agentic loops.
Catalogues that AI can read
Machine-readable descriptions of available capabilities. The semantic information needed for an LLM to use the integration is in the catalogue.
What's at stake
The enterprises that built strong integration through the 2010s and maintained it through the 2020s are in the best position for AI in 2026. The integration capability is the foundation; the AI sits on top.
The enterprises that let integration capability decay during the last decade — assuming it was infrastructure that just worked — are finding the gap as AI workloads demand more from it. The remediation is significant; the timeline is multi-year; the capability has to be rebuilt or re-developed.
This isn't a new lesson. Strong enterprise foundations beat exciting capability layers consistently. AI is just the latest workload that demonstrates this. Some of us have been saying for years that integration matters more than the marketing suggests; AI is now demonstrating the point unmistakably.
What I'm telling teams
For the integration teams I work with in 2026:
- Treat integration as a primary AI enabler, not as infrastructure. The investment case is stronger than ever.
- Modernise toward real-time and API-driven. Batch is residual; AI doesn't tolerate it.
- Build identity propagation through every layer. Without it, AI workloads can't satisfy governance.
- Govern the API catalogue. Discovery, documentation, versioning, deprecation.
- Build MCP servers for systems that AI workloads use. The standardisation is worth it.
- Invest in observability at integration depth. The AI workload's debugability depends on it.
- Plan capacity for AI patterns. Burstiness, fan-out, agentic loops produce load profiles batch integration never saw.
The longer arc
Integration is going to be the integration story of the 2020s. The 2010s were about getting integration platforms in place — webMethods, MuleSoft, Boomi, the iPaaS category. The 2020s are about making them carry workloads they weren't fully designed for. AI is the most demanding of those workloads, but it's not the last; agentic systems, autonomous workflows, real-time decisioning, embedded AI in every enterprise platform — all of these will compound the demand on the integration layer.
The teams that recognise this and invest accordingly will be the ones whose AI initiatives ship at scale. The teams that treat integration as solved infrastructure will keep producing AI workloads that demo well and fail in production. The discipline matters more than the model.
After fifteen years on the integration side of this work, I'm not surprised that integration is the answer. I'm surprised it took this long for the rest of the field to notice.
RELATED READING
More from the field.
Service practices the article draws on, related programmes, and other pieces on adjacent topics.
Service practices
Related pieces
IBM webMethods Modernisation: A Decision Framework for the Eight-Year Horizon
Most webMethods estates do not need a rewrite. They need a structured assessment, a few high-conviction architectural moves, and an operating model that survives the consultant exit. A field framework from a team that has lived inside the practice.
Enterprise Integration Challenges in Large Organizations
Integration estates in large organisations rarely fail because the technology was wrong. They fail because the operating model around the technology was missing. A field perspective on the patterns that hurt — and what to do about them.
Cloud Integration Architecture
Cloud integration services have matured into platforms that compete with traditional iPaaS. A decision framework for what belongs on cloud-native integration versus what belongs on a dedicated integration platform — and how to architect the boundary.
Discuss this work
Bring an enterprise programme.
If anything in this piece resonates with what you're building, talk to us. Senior practitioners engage directly on architecture and delivery.
Work with the practitioners
Bring an enterprise programme.
Architecture audit, new delivery, modernisation, or in-flight rescue — Intellectual engages directly on enterprise programmes with senior practitioners.