Enterprise AI adoption is running into an AI execution gap as companies discover that a successful pilot does not automatically become a production system that delivers measurable business value.
At WSO2Con Africa 2026 in Nairobi, Ruwan Linton, Senior Vice President and Chief Customer Officer at WSO2, argued that the problem sits around the AI model itself: enterprises still have to connect agents to legacy systems, usable data, business workflows, security controls and clearly defined outcomes.
Linton cited MIT Project NANDA’s 2025 research, which found that 95% of enterprise generative AI initiatives studied showed no measurable profit-and-loss impact. The study examined more than 300 public AI deployments alongside interviews and surveys, and its headline finding has been widely interpreted as evidence that the gap between experimentation and business value remains substantial.
His argument at WSO2Con was that enterprises should look beyond the model when explaining that gap. A pilot can demonstrate that an AI system is technically capable, yet the same system can struggle once it has to work with an organisation’s existing architecture, data, processes and governance requirements.
Why AI pilots struggle to reach production
The enterprise environment is rarely a clean slate. Linton described it as a “brown field” environment, where new AI applications have to work with legacy systems, established APIs and processes that were built around conventional software and human users.
That creates an immediate integration problem. An API may work perfectly for a conventional application while still being poorly suited to an agent that needs to invoke business capabilities dynamically. TechTrendsKE’s earlier WSO2Con coverage reached a similar conclusion from the API side: as agents gain the ability to act, APIs become part of the infrastructure through which AI interacts with enterprise systems, making their security, governance and design increasingly important.
Data creates another constraint. Linton’s point was more specific than the familiar argument that enterprises need “better data.” Large amounts of unstructured information can be useful to an AI system, but supplying too much context to a model can also increase token consumption and cost. The practical challenge is therefore to make enterprise knowledge accessible in a form that an agent can retrieve and use without turning every interaction into an expensive exercise in context processing.
That issue surfaced in another WSO2Con Africa session covered by TechTrendsKE, where engineers demonstrated how tools, APIs, MCP and RAG can connect existing enterprise systems and information to AI agents.
The third problem is the workflow itself. Many enterprise processes were designed around people who can pause, ask questions, interpret missing information and return to a task later. An autonomous or semi-autonomous agent needs those capabilities represented in the workflow if it is expected to handle the process reliably.
Security and governance add another production constraint. A pilot can operate with controlled information and limited access, but a production agent may need to retrieve sensitive data, call APIs, update records or trigger actions. That raises questions around identity, permissions, auditability and human approval. Earlier WSO2Con reporting has examined the same issue, including how agents need distinct identities and appropriately scoped authority when they begin acting across enterprise systems.
The final bottleneck is ownership. Linton argued that the person responsible for building an AI system is often not the person accountable for the business result. A technically successful deployment can therefore reach the end of its project plan without anyone having clear responsibility for whether the promised business improvement actually occurred.
Why traditional delivery models fall short
Linton’s proposed response starts with changing how these projects are delivered. Traditional implementation engagements often begin with a technical scope, a defined list of deliverables, periodic reviews and a handover once the agreed work is complete.
That model works more comfortably when the target is stable. Linton argued that agentic AI does not offer that stability because models improve, new capabilities become available and organisations learn more about which processes are worth automating after the first systems are deployed.
His alternative is to define the engagement around a business outcome rather than a fixed technical scope. The technology can then change as the team learns what works, while the outcome remains the anchor for decisions about architecture, integration, models and workflows.
The difference also applies to delivery cadence. Instead of waiting for quarterly business reviews to determine whether a long implementation is producing the expected result, Linton wants the business sponsor involved throughout the delivery process. Technical progress and business progress therefore become part of the same feedback loop.
The handover model changes as well. Under the conventional approach, an implementation partner can complete the agreed technical scope and leave the customer with the deployed system. Linton’s FDE model keeps the engineer involved until the defined business outcome has landed, because reaching that outcome may require changing the technical solution after deployment begins.
That does not mean every AI programme should become an open-ended engineering engagement. Linton specifically cautioned against defining an FDE objective as something as broad as 40% business growth. He said the business outcome needs to be sufficiently narrow to deliver within roughly three to six months, even if the wider transformation continues beyond that period.
What Forward Deployed Engineering changes
WSO2’s Forward Deployed Engineering model places a senior engineer inside the customer’s team for the duration of a defined business outcome. The engineer is expected to understand the business problem, contribute architectural and design expertise, write production code and remain involved through delivery rather than simply produce a blueprint and leave. WSO2 describes its FDE approach as sitting between consulting, product engineering and customer success.
That combination is important because each discipline normally operates with a different responsibility. Consultants may define the business problem and recommend an approach. Product engineers build the technology. Customer-success teams track adoption and value after implementation. Linton’s proposition is that the FDE combines those responsibilities closely enough to reduce the gap between what the customer wants to achieve and what ultimately gets built.
The model also changes the engineer’s position inside the project. An FDE joins standups and planning sessions, works alongside the customer’s engineers and adapts the scope as new information emerges. WSO2 says the engagement is designed around measurable objectives and key results, with the engineering team staying involved until those objectives are achieved in production.
This approach fits into the wider architecture WSO2 has been presenting at the conference. Its Agentic Enterprise Fabric brings together agent management, APIs, integration, identity and engineering capabilities, while WSO2’s Agent Manager provides controls around agent identity, MCP governance, runtime, observability and evaluation.
The technology stack, however, is only one part of Linton’s proposition. His central point is that someone still has to work through the specific problems of applying those capabilities to an individual organisation.
WSO2’s customer-support experiment puts the model to work
WSO2 is also using the FDE model internally. Linton described WSO2 itself as a customer of its own technology and used the company’s customer-support operation as the main example.
The problem was straightforward: customer-support cases tend to receive better and faster responses when a highly experienced senior engineer becomes involved early. WSO2 wanted to capture some of that expertise and make it available across a much larger volume of customer cases.
The company embedded an FDE with its customer-success leadership and set a target of resolving 30% of customer issues without human intervention. There is an important qualification, however: Linton said the system was resolving roughly 5% of issues without human intervention at the time of his presentation, meaning the 30% figure was an objective rather than an achieved result.
The implementation also exposed the execution problems Linton had outlined earlier in the presentation. WSO2 had roughly 50,000 historical support issues that could provide useful knowledge, but sending large amounts of that information to an LLM for every new case would create an impractical cost structure.
The team instead converted historical issues into knowledge-base entries and stored them in a vector database, creating a more efficient way to retrieve relevant information. This is the kind of engineering decision that can disappear behind a headline about an “AI support agent,” yet it illustrates Linton’s larger point: getting AI to work economically requires changes to the data architecture surrounding the model.
The first workflow also exposed another problem. WSO2 initially designed the agent to provide a first response intended to resolve the customer’s issue immediately. That approach struggled when the original support request did not contain enough information to determine the cause of the problem.
The team changed the workflow so the agent could behave more like a human support representative, asking for additional information when necessary before attempting to resolve the case. Customers can also move from the AI interaction to a conventional support case when human intervention is required.
The result is a useful example of why enterprise AI deployment involves more than selecting a model. The team had to change how information was retrieved, how much context was supplied, how the workflow operated and where human intervention remained available.
The engineer has to understand the business problem
The question-and-answer session after Linton’s presentation exposed another part of the FDE model: the role requires engineers to develop business understanding alongside technical capability.
Asked how WSO2 ensures that engineers agree on the intended business outcome, Linton said the company is using its own internal projects as practical training grounds. Product engineers who may have spent much of their careers focused on software and technical support are being placed inside business problems involving customer support, HR, marketing and revenue operations.
His view was that formal training alone cannot create this capability. Engineers have to work through real business problems to understand how technical decisions affect the outcome an organisation is trying to achieve.
That also explains why WSO2 treats its own operations as a proving ground for the model. The company has been using FDEs and its own technology across internal use cases as part of its stated effort to become an agentic enterprise itself. The WSO2Con Africa programme describes Linton as responsible not only for customer success and FDE, but also for WSO2’s internal software and applications.
The approach mirrors a broader theme running through the conference. TechTrendsKE’s reporting on durable workflows, enterprise data, agent identity and governance has shown that AI agents have to operate across several layers of enterprise architecture before they can reliably execute business tasks.
From AI capability to measurable business outcomes
Linton’s presentation ultimately places the AI execution gap at the intersection of technology and organisational responsibility. The model may be capable, but an enterprise still has to expose the right systems, make data usable, redesign unsuitable workflows, establish identity and governance controls, and decide who owns the resulting business outcome.
That is particularly relevant in Kenya, where the public sector is also considering how AI agents could coordinate services across institutions with fragmented systems. At WSO2Con Africa, government officials described plans for a unified platform connecting public-sector systems through secure APIs, alongside requirements around Zero Trust, data access, authorisation, audit trails and human escalation.
The same architecture challenge appears in financial services and other large organisations that have to connect modern digital channels with established core systems. CRDB Bank’s WSO2Con presentation, for example, focused on building an integration backbone around fragmented middleware, APIs and core banking modernisation.
That context makes the FDE proposition easier to understand. The difficult work of enterprise AI is often found in the infrastructure and processes that already exist, rather than in the demonstration that first convinced an organisation to pursue an AI project.
For WSO2, Forward Deployed Engineering is the proposed way to put experienced engineers close to those problems and keep them there until a defined result is achieved. Whether that model delivers the business outcomes promised across a wider set of customers will depend on how those outcomes are defined and measured, but Linton’s own customer-support example makes clear that even inside WSO2, reaching the target involves iteration, workflow redesign and compromises between automation, cost, accuracy and human oversight.
The larger lesson from the session is therefore practical. Moving an AI system from a convincing pilot to production requires an organisation to engineer the conditions around the model, then keep adjusting those conditions as the system encounters real work. That is where WSO2 sees the execution gap, and where it is placing its FDE model.
Real ESG impact doesn’t happen in panels alone, it happens in the rooms where financiers, operators, and policymakers actually align. Our GreenShift Forum 2026 cuts the noise, bringing together the people rewiring Africa’s sustainability and energy frameworks for one focused day in Nairobi. Secure your seat.
Go to TECHTRENDSKE.co.ke for more tech and business news from the African continent and across the world.
Follow us on WhatsApp, Telegram, Twitter, and Facebook, or subscribe to our weekly newsletter to ensure you don’t miss out on any future updates. Send tips to info@techtrendsmedia.co.ke
