Enterprise AI adoption is expanding, but the transition to measurable business value remains uneven. In McKinsey’s 2026 global survey, 37% of respondents reported that AI had contributed positively to their organisation’s earnings before interest and taxes. This measures reported financial impact, rather than the percentage of pilots that reach production. [1]
One reason agent initiatives struggle is that companies treat agents as a standalone layer and underestimate the integration work underneath. Without reliable connections and governed data, agents cannot perform consistently. Understanding the role of the integration layer is therefore essential to designing agent architectures that can support real business processes.
Integration complexity does not disappear
In 2025, vendors and analysts promised that autonomous AI systems would transform enterprises: writing code, managing sales pipelines, processing requests and coordinating business processes. Many organisations have since encountered the difficulty of moving these ambitions beyond pilots.
Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027 because of rising costs, unclear business value or inadequate risk controls. This is a forecast, not a measured project failure rate. A central architectural issue is that agents and integration platforms operate at different layers of the same system. [2]
For those who worked through the enterprise service bus, service-oriented architecture and integration platform eras, the current enthusiasm for agents feels familiar. The names, tools and interfaces have changed, while the underlying architectural task remains.
Twenty years ago, companies were trying to connect fragmented systems, incompatible data formats and numerous unstable point-to-point integrations. One response was the enterprise service bus, or ESB.
Today, the same challenge appears in a different form. Services and SaaS products have replaced many monolithic enterprise applications. Python and prompt-driven logic have taken over some of the work previously expressed in XML configurations, while agents and orchestrators increasingly sit alongside visual integration tools. Data still has to be received, standardised, enriched, routed, validated, secured and monitored.
A traditional ESB handled five core tasks:
- Receiving messages from different sources.
- Normalising data.
- Transforming and enriching it.
- Managing routing and orchestration.
- Applying validation, security, retry and monitoring policies.
The agent era has brought two important changes. First, a new class of tools has emerged. Large language models can generate data mappings, propose routes, assemble pipelines and help connect systems faster than a developer working entirely by hand. They accelerate integration work, while its underlying complexity remains.
Second, the barrier to entry has fallen. Open-source tools, cloud infrastructure and familiar programming languages make it easier to build agent systems. They also make it easier for an integration estate to grow without sufficient control.
An organisation could usually identify its service bus, understand its structure and assign an owner. Modern agent systems are often distributed and less explicit. A collection of scripts, agents and service connections can be difficult to audit.
Integration complexity is conserved. As agents become more autonomous, the need for common data models, governance, control, ownership and accountability increases. Faster execution raises the cost of architectural disorder.
What the integration and AI agent markets indicate
Demand for integration platforms continues alongside the expansion of AI agents. Enterprises still need tools that connect systems, prepare data and make processes manageable. Agent workflows increase the importance of these capabilities.
Gartner’s July 2025 market-share analysis puts worldwide iPaaS revenue at $8.5 billion in 2024, an increase of 23.4%. The analysis identifies AI adoption, low-code and no-code tools, and SaaS as growth drivers. These findings show continued investment in integration as AI use expands. [3]
The gap is also visible inside organisations. MuleSoft’s 2026 Connectivity Benchmark Report surveyed 1,050 IT leaders globally. Respondents reported an average of 957 applications, with only 27% connected. Meanwhile, 82% identified data integration as one of the biggest challenges their organisation faces when using AI. [4]
These are findings from a technology vendor’s survey, rather than evidence that integration causes a fixed share of all AI project failures. They nevertheless provide a concrete international measure of the integration challenge: widespread AI adoption still has to contend with fragmented enterprise systems.
The three layers of an agent architecture
The distinction between architectural layers is central. Agent platforms and integration platforms fulfil different responsibilities within the same model.
| Layer | What it does | Examples |
| AI agents | Interpret goals, plan actions and adapt decisions. | CrewAI, LangGraph, Microsoft Copilot Studio, Kore.ai |
| Data integration | Delivers reliable, secure data between systems in the required format and sequence. | USEBUS AI-Code, MuleSoft, Boomi |
| Business systems | Store and process business data. | SAP, PostgreSQL, Snowflake, MongoDB |
An agent may decide to retrieve a customer record from a CRM system, enrich it with information from a data warehouse and prepare an offer. The integration layer supplies the controlled access, transformations and delivery mechanisms needed to execute that workflow reliably.
Three traps that undermine agent pilots
An organisation can connect a language model to enterprise systems while leaving the surrounding environment unprepared. Without normalised data, access controls and managed pipelines, an agent may receive conflicting or incomplete context and produce unpredictable results.
Poor data entering a RAG pipeline
Retrieval-augmented generation, or RAG, combines the retrieval of relevant external information with the generation of an answer by a language model. Retrieval can use vector search, keyword search or a combination of methods. Its effectiveness depends on the information supplied. Unclean, duplicated or outdated documents can create noisy context, reduce accuracy and contribute to hallucinations. [5]
The problem begins before retrieval, when data enters the knowledge base without sufficient preparation. The integration layer should clean, deduplicate and refresh information before it becomes model context.
Direct connections to legacy APIs
Real enterprise interfaces can be complex and inconsistent. An agent should not have to handle every system-specific exception on its own. An integration layer normalises data, handles errors and encapsulates the technical details of accessing each system.
Uncontrolled polling
Polling means repeatedly checking another system for changes. It is often necessary when a system does not support an event model: it has no webhooks, does not publish to a message broker and offers no suitable change data capture mechanism. Uncontrolled polling can introduce unnecessary load and delays when frequency limits, deduplication and error handling are missing.
Where the source systems support it, an event-driven architecture can use webhooks and message brokers to propagate changes. When polling is unavoidable, an integration platform makes it a managed process by controlling frequency, handling failures, deduplicating records and applying the configured delivery guarantees.
In each case, the agent is being deployed on top of an environment that needs preparation. Greater autonomy increases the requirements for data quality and integration discipline.
Why this matters for GCC enterprises
The same gap between adoption and scale is visible in the Gulf. In McKinsey’s 2025 survey of 139 senior executives and board directors across the six GCC countries, only 31% said their organisations were scaling AI or had fully deployed it across the organisation. [6]
Regional programmes also make the data foundation explicit. Dubai’s updated Data Manual addresses government data quality, governance and AI readiness. Saudi Arabia’s Data Sharing Policy describes a government service bus and an API-based data marketplace for controlled sharing. These are distinct national and local frameworks. For enterprises, the practical lesson is to design agent access around governed data flows, clear ownership and the requirements of each operating environment. [7] [8]
How USEBUS AI-Code supports agent systems
An agent can decide that customer data needs to be enriched from an ERP system and a data warehouse. Execution requires a layer that retrieves the records, brings them into a common format, checks and enriches them, and passes them on securely. Integration platforms such as USEBUS AI-Code fulfil this role.
The platform is built around a data transformation pipeline that assembles integration flows from reusable operations. Data moves through successive preparation steps so that an agent receives it in a usable form.
The key distinction concerns execution. An agent’s reasoning is probabilistic, while the integration layer needs deterministic controls. Format conversion, field mapping, validation and error handling should produce reproducible results. USEBUS AI-Code provides schema controls, delivery mechanisms, retry logic, change auditing and traceability from source to result.
This creates a data foundation for agents: preparing relevant context for retrieval, supporting event-driven flows, providing managed connectors and addressing data quality and consistency. Delivery and ordering guarantees depend on the configured routes, transports and failure-handling policies.
Security is another important part of the architecture. USEBUS AI-Code uses role-based access controls and encrypted data transmission. Its AI components work with metadata and flow structures without access to the underlying data content. These controls help limit exposure of sensitive data; overall security also depends on configuration, identity management and the wider deployment environment.
By managing data preparation and movement, the integration platform gives agent systems a more predictable, governable foundation that can support expansion beyond individual use cases.
How integration platforms should develop
Integration platforms help make agents suitable for production. An agent determines the intended action. The integration layer determines how the necessary data will be obtained, transformed, delivered and controlled. Without explicit ownership of those execution responsibilities, a pilot built from scripts and assumptions becomes difficult to operate reliably at scale.
Four strategic priorities follow:
- Provide a foundational integration layer that exposes managed flows as standard tools agents can use.
- Strengthen the functions that require deterministic behaviour, including delivery controls, data transformation, quality checks, lineage and data logging.
- Explain the layered architecture clearly so that customers understand the integration requirements of scaling agent systems.
- Build practical connections with agent platforms. Together, the two layers can support AI systems that participate in real enterprise workflows.
Integration vendors should avoid losing their core execution role by trying to become another agent platform. Equally, they need to respond to the new requirements that agents create.
What determines success beyond the pilot
The success of an agent system depends on the environment in which it operates: validated input data, deterministic execution controls, integration into real workflows and automated testing against prepared datasets. Teams that understand the boundary between probabilistic reasoning and deterministic execution can make the system easier to control.
Agents redistribute enterprise integration complexity. Responsibilities previously handled by an ESB or other middleware still have to be fulfilled across data flows and pipelines. Giving those responsibilities clear ownership makes the architecture more predictable.
Platforms such as USEBUS AI-Code provide the integration foundation for this work. Moving from a pilot to production still requires testing under realistic operating conditions and measuring business outcomes. A dependable integration layer makes those requirements more achievable; it does not replace them.
Ph.D. in Mechanical Engineering and a Certified TOGAF 9 Enterprise Architect.
Sources
1. McKinsey. The state of AI in 2026 On the road to ROI. 25 August 2026.
2. Gartner. Forecast for agentic AI project cancellations by the end of 2027. 25 June 2025.
3. Gartner. Market Share Analysis Integration Platform as a Service Worldwide 2024. 21 July 2025.
4. MuleSoft. 2026 Connectivity Benchmark Report findings. 5 February 2026.
5. Microsoft Learn. Retrieval augmented generation and indexes in Microsoft Foundry.
6. McKinsey and GCC Board Directors Institute. The state of AI in GCC countries In pursuit of scale and value. 13 November 2025.
7. Digital Dubai. Launch of the updated Dubai Data Manual. 1 July 2026.
8. SDAIA. Data Sharing Policy.