Billions of dollars are pouring into enterprise AI adoption but turning a promising demo into a system anyone actually uses remains the industry's most stubborn problem.
The challenge is about to get harder as agentic AI — or systems that do not just answer questions but go off, complete workflows and return with results — is moving into enterprise deployment faster than most organisations anticipated. The question companies face is whether AI can reliably complete entire workflows across systems, permissions, approvals and the scrutiny of people who are accountable for the outcome.
Colin Jarvis is the person OpenAI has put in charge of making that work. As its global head of Forward Deployed Engineering, he sends teams into companies to do the unglamorous work of mapping workflows, untangling legacy systems, earning the trust of sceptical end users, and building something that runs in production.
Given the increasing demand for such help, OpenAI committed US$4 billion ($5.12 billion) to scaling that function into a standalone deployment company. In Singapore, OpenAI's newly announced Applied AI Lab will put forward deployed engineers (FDE) to work across public services, healthcare, finance, and digital infrastructure.
With frontier models now capable of reshaping entire workflows rather than automating isolated tasks, The Edge Singapore spoke with Jarvis about what companies need to do differently to get it right, and how FDEs can help.
What separates companies that successfully scale AI from those that stall after the pilot?
See also: OpenAI commits over $300 mil to help Singapore build applied AI base
The strongest companies tend to do three things well.
First, they pick a small number of consequential problems and use them to build momentum. One mistake I see is organisations spreading effort across many low-stakes use cases. Each one ends up creating its own baseline of data access, agent runtime, evaluation and governance, so teams keep rebuilding the same foundations from scratch. That slows progress because every new initiative starts over rather than benefiting from what came before.
The stronger approach is to identify a few high-value lighthouse use cases that matter enough for leadership to back and for users to care about. Done well, those deployments create reusable foundations, technical, operational and organisational, that make the next use case faster and easier to scale.
Second, they embed with end users. Without a deep understanding of the user's needs, expectations and trust requirements, you can get a cool demo but no adoption. Results may be inconsistent or hard to verify, and users will not trust the output. The best use cases often come from people closest to the work, because they understand the friction in the workflow.
Practically, this can mean fundamentally reorganising your business. In the semiconductor example I will describe shortly, the company moved from a central AI productivity team to a model where engineers were distributed into business areas, so each AI-powered product could get the tuning, evaluations and personalisation needed for its end users. This can be the difference between adoption and failure.
Third, they build for production from the start. That means evaluation, security, permissions, reliability and user experience are not afterthoughts. Our customer, Morgan Stanley, was able to make their rollout work because the team invested heavily in evals, controls and advisor trust before scaling adoption across wealth management. Today, over 98% of advisor teams actively use AI @ Morgan Stanley Assistant, its internal chatbot, for answering financial advisors' questions for seamless internal information retrieval.
So it is talent, technology and structure together. Better models matter, but without the right technical talent and organisational design, the value stays trapped in pilots.
Could you walk us through what an FDE actually does inside a client organisation - not the job description, but what a real engagement looks like from the first conversation to a system running in production?
A real FDE engagement usually starts with a business problem, not a model. My team acts as the bridge between research, product and enterprises. We take what models can do at the frontier and work out what it takes for that capability to become a real system and economic benefit inside a company.
That means spending time with leaders and end users to understand where the highest-value work is blocked: what decisions are slow, what information and data is hard to access, what work is repetitive, and where quality or risk matters most. From there, the work becomes very hands-on. FDEs break the problem down, map the workflow, understand the customer's industry, systems and constraints, and build early prototypes with the people who will actually use them. In doing so, FDEs go deep not only with technical counterparts, but also with subject matter experts and senior stakeholders to find and prioritise the most promising entry point with high ROI and high feasibility.
To stay ahead of the latest tech trends, click here for DigitalEdge Section
The thing that differentiates FDE is the iterative deployment model. We use a high-level set of acceptance criteria based on outcomes, which means we can rapidly pivot if we find the original design doesn't stack up or customers don't like the user experience.
One of the best examples of this was when we went deep with a global semiconductor design company, embedding closely with the customer across its core design, verification, and performance workflows. Over the course of the engagement, we identified 23 AI use cases across the IP lifecycle, including a kernel optimiser that reduced chip design optimisation from several days to overnight, and an intelligent debugging assistant that accelerated root-cause analysis and bug resolution from weeks to just a few days. In one particularly complex workflow, the time required was reduced from six weeks to a single day.
The goal is a production system that people use, that is reliable enough for the operating environment, and that delivers measurable value. Because FDEs sit close to the customer and close to OpenAI's product and research teams, the lessons from real deployments can feed back into better products, better tools and better models.
The FDE role sits at the intersection of engineering, product judgment and deep customer context. Why is that combination so difficult to find, and what does the scarcity of this profile mean for companies trying to build or buy that capability internally?
The role is difficult to find because it combines skills that are often developed and served separately.
An FDE needs hard technical depth because the work has to stand up in production and understand how it fits into the enterprise context. They also need product judgment, because the answer is often not obvious at the start. And they need the softer, relationship-based skills that determine whether a deployment actually works: customer empathy, stakeholder management, cultural judgment and the ability to build trust with users who may be sceptical at first.
Paired with AI deployment being a fast-moving discipline that requires high levels of adaptability, this combination of skills is very scarce. It is not enough to know models, and it is not enough to know enterprise transformation. You need people who can move between architecture, code, workflow, evaluation, governance, subject-matter expert collaboration depth, and human adoption.
