Closing the AI Execution Gap with Forward Deployed Engineering

ai/agents ai/enterprise engineering/fde casestudies softwareengineering wso2 conference

Core idea

A successful AI pilot is not the same as a successful business outcome. Ruwan Linton argues that the main execution gap lies in integration, data, workflows, governance, and delivery ownership, rather than access to capable models. Forward Deployed Engineering (FDE) addresses this by embedding senior engineers in the customer’s team and keeping them responsible for a defined business outcome.

Video

1. What is the AI execution gap?

The gap is between demonstrating technical capability in a pilot and delivering measurable value in production.

A pilot can show that an AI application works while leaving the hardest enterprise questions unresolved:

• Can it work with existing systems?
• Can it use real data safely and at a viable cost?
• Does the workflow let it complete the task?
• Who owns the business result?
• Can the team adapt before the implementation becomes outdated?

Delays reduce business value and can cause the project to lose leadership attention.

Opening statistic

The speaker cites an MIT study and states that 95% of AI projects complete pilots without demonstrating profit-and-loss improvement. The transcript does not identify the study precisely or establish its scope. Treat this as an attributed claim, not a general failure rate for all AI projects.

2. Five enterprise bottlenecks

Bottleneck	Why it blocks production	Implication
Legacy systems and APIs	Enterprise deployments are usually brownfield. Existing interfaces may not support agent-driven use.	Adapt integrations instead of assuming a clean starting point.
Data	Unstructured or noisy data can require more context and consume more tokens.	Organize knowledge so the application can use it economically.
Processes and workflows	Workflows designed for humans may not fit how an agent gathers information and acts.	Redesign the process, not only the model prompt.
Security and compliance	Mock-data pilots do not establish that real enterprise data can be sent to a model safely.	Address governance before the production transition.
Business objectives	A technical demonstration does not establish the value needed for leadership sponsorship.	Define the business result clearly.

Four broader forms of the gap

1. Integration depth: Existing systems, APIs, and processes need to serve both humans and agents.
2. Governance friction: Production requires a trusted governance framework.
3. Unclear outcome ownership: The implementation team and the business owner are often different groups.
4. Roadmaps that move too slowly: Multi-year delivery assumptions conflict with rapidly changing AI technology.

3. Why the delivery model must change

The speaker contrasts traditional delivery practices with an outcome-led model for AI:

Dimension	Traditional model described in the talk	Proposed AI delivery model
Scope and contract	Agree on a technical checklist.	Agree on a business outcome and adapt the technical solution as needed.
Review cadence	Review business progress quarterly, separate from engineering sprints.	Include business-outcome reviews in the sprint cycle.
Business participation	The sponsor stays outside much of implementation.	The business sponsor participates in delivery and evaluates progress.
Handover	Complete the technical scope, hand it over, and leave after limited support.	Stay embedded until the agreed outcome is achieved.
Roadmap	Plan around a two-to-five-year horizon.	Use shorter planning and delivery cycles.

Technical completion versus outcome completion

Delivering the agreed features does not guarantee that the business problem is solved. The implementation may need to change after the team sees how it performs in the real workflow.

4. What Forward Deployed Engineering means here

In WSO2’s definition, a forward deployed engineer is a senior engineer who:

• Works inside the customer’s team.
• Understands the business problem and domain.
• Has architecture and design skills.
• Writes production code rather than only recommending a blueprint.
• Works closely with the customer’s engineers and leadership.
• Owns delivery of a defined business outcome.

The role combines three skill sets:

Skill set	Contribution
Consulting	Understand the business problem and propose an approach.
Product engineering	Turn the approach into a working technical implementation.
Customer success	Work with the customer to make the implementation produce value.

The speaker notes that FDE has different definitions across organizations. This note uses the definition given in this talk.

Engagement sequence

flowchart TD
    A[Define business outcome] --> B[Embed in customer team]
    B --> C[Align technology and outcome]
    C --> D[Deliver small increments]
    D --> E[Evaluate business result]
    E -->|Adjust| C
    E -->|Achieved| F[Complete agreed outcome]

The engineer must be able to change the solution as the problem becomes clearer or better technology becomes available.

Keep the outcome bounded

An outcome such as “grow the whole business by 40%” is too broad for this engagement model. The speaker recommends a smaller outcome that can ideally be delivered within three to six months.

This is guidance for sizing the outcome, not a guarantee that every engagement ends within that period.

5. WSO2’s agentic-enterprise context

The speaker describes an agentic enterprise as an ideal future state in which autonomous agents work together to support business operations and growth.

• WSO2 presents a “golden path” toward that state.
• The speaker explicitly says it is not a maturity model. Organizations can start from different points according to their needs.
• WSO2 positions its product portfolio as an agentic-enterprise fabric, including an AI gateway for controlled access to LLMs.

The transcript refers to visual slides without explaining every step or component. It is not sufficient to reconstruct the full path or architecture.

6. Case study: AI-assisted customer support

Business problem

WSO2 wanted to provide faster, accurate support responses by making senior engineers’ knowledge available across more customer requests.

Both speed and correctness mattered. A fast but incorrect answer would not satisfy the business goal.

Engagement and outcome

An internal FDE joined the customer-success leadership team. WSO2 treated its own digital operation as a customer and used its own technology to implement the solution.

Measure	Reported value at the time of the talk
Target	Resolve 30% of support issues without human intervention.
Current result	Resolve approximately 5% without human intervention.

Target is not achieved performance

The speaker explicitly says WSO2 had not reached the 30% target. The reported result was approximately 5%. The talk does not provide a measurement period, evaluation method, or independent validation.

Bottleneck 1: Available data was not usable context

The customer portal contained roughly 50,000 historical issues, which represented a large body of support knowledge.

Sending that entire history to an LLM for every request would not be economically viable. WSO2 instead:

1. Created knowledge-base entries from historical issues.
2. Stored those entries in a vector database.
3. Used retrieval-augmented generation (RAG) as the initial approach.

Lesson: Having a large knowledge source is not enough. The application must select useful context at a viable cost.

Bottleneck 2: The first-response workflow lacked context

The initial workflow tried to resolve a case from the customer’s first description. It worked to some extent, but many requests did not contain enough information.

Human support engineers normally ask follow-up questions. A one-shot AI response did not reproduce that information-gathering process.

WSO2 changed the workflow to a conversational interaction:

1. The customer describes the problem.
2. The agent asks for more information when needed.
3. The agent attempts resolution with the additional context.
4. The customer retains the option to create a support case and receive engineer-based support.

Main case-study lesson

RAG addressed the knowledge-access problem, but the team also had to change the workflow. Improving retrieval alone could not supply details that the customer had not yet provided.

Key takeaways

1. Measure business value, not only technical completion.
2. Embed engineers close to the real problem. Architecture, implementation, and customer collaboration must work together.
3. Treat data preparation and workflow design as core engineering work.
4. Use short feedback cycles and bounded outcomes.
5. Preserve human escalation. The support case study does not assume complete trust in AI.

---

Related vault notes: Abstractions for the Agentic Enterprise connects agentic systems to enterprise workflows; Software Factory and AgentOps - Deploying to Production cover governed delivery and production operation.
LLMs and AI Agents, 3. Resoning LLMs and AI Agents, 7. RAG - Retrieval as Context Selection, Retrieval-Augmented Generation (RAG), 6. Reflexes and Guardrails