The most expensive AI hires of 2026 are not model researchers. According to an executive-search study by Christian & Timbers, reported by TechCrunch on 30 July 2026, only about 2,000 engineers in the United States combine the sector knowledge, boardroom credibility and hands-on applied-AI experience needed to reliably turn enterprise AI spend into returns. Not 2,000 available. 2,000 in total.
That scarcity explains why OpenAI, Anthropic, Microsoft, AWS and Google have each spent the past four months building or funding units whose product is people, not models. The job title they are all hiring for is forward-deployed engineer. This article explains what the role is, why the operating model behind it matters more than the title, and how a Hong Kong enterprise with 50 to 500 staff can access the same capability without a Fortune 500 budget.
What is a forward-deployed engineer?
A forward-deployed engineer (FDE) is a software engineer who works inside a customer's organisation, alongside its operators and frontline teams, to design, build and ship production AI systems connected to that customer's real data, tools and controls. The FDE is accountable for a measurable business outcome, not for delivering a report or a proof of concept.
The role was invented at Palantir, where engineers were posted into client sites for months at a time. The 2026 version is narrower and more specific to AI: an FDE typically owns retrieval pipelines, evaluations, guardrails and workflow integration for large language model deployments. The distinguishing feature is dual accountability. The FDE builds for one customer, then feeds what they learned back into the vendor's product.
Three things separate an FDE from a conventional consultant or systems integrator:
--- They write and ship production code inside your environment, rather than producing a recommendation for someone else to implement.
--- They are measured on an operating metric you already track, such as claims cycle time, first-response time or cost per processed document.
--- They stay through adoption. A typical embedded engagement runs 60 to 180 days, long enough to see whether frontline staff actually use what was built.
Why are OpenAI, Anthropic and Microsoft betting billions on FDEs now?
Because the bottleneck in enterprise AI has moved. Access to capable models is no longer scarce; the ability to implement them against proprietary data inside legacy workflows is. Between May and September 2026, every major AI vendor responded by building a deployment business staffed with forward-deployed engineers, backed by a combined commitment well above US$9 billion.
The sequence is instructive. On 11 May 2026, OpenAI launched the OpenAI Deployment Company with more than US$4 billion of initial investment led by TPG, acquiring the applied-AI firm Tomoro to bring roughly 150 experienced FDEs on day one. McKinsey, Bain & Company and Capgemini are among the investors. On 2 July, Microsoft committed US$2.5 billion and 6,000 staff to a new implementation unit embedded with customers, two days after AWS announced a US$1 billion equivalent. On 15 July, Anthropic, Blackstone and Hellman & Friedman introduced Ode with Anthropic, a US$1.5 billion enterprise AI services firm built on the acquired team of Fractional AI. This week, Accenture and Google Cloud announced a Gemini Enterprise Business Group with a 1,000-person forward-deployed engineering workforce.
The financial pressure behind this is not subtle. In its State of AI 2026 survey, McKinsey found that 40 percent of organisations with more than US$1 billion in revenue are now scaling AI agents, up from 27 percent a year earlier, yet the share reporting any EBIT contribution from AI is unchanged at 37 percent, and AI high performers remain about 6 percent of respondents. Eighty percent of users report individual productivity gains. The organisation-level number has not moved. Vendors have concluded that the only way to close that gap is to put their own engineers inside the customer's workflow.
How does an FDE engagement actually work?
An FDE engagement follows a recognisable four-phase pattern: a short diagnostic to locate value, joint selection of two or three priority workflows with the customer's leadership, an embedded build phase that connects models to the customer's data, tools and permission controls, and a handover phase that measures adoption and trains internal owners. The whole cycle usually runs one to two quarters.
OpenAI's own description of a typical Deployment Company engagement is a useful reference because it is explicit about sequencing. It begins with a focused diagnostic of where AI can create the most value, followed by a small number of priority workflows selected with the customer's leadership and operating teams. Engineers then work inside the organisation to design, build, test and deploy production systems connected to the customer's data, tools, controls and business processes.
Notice what is absent. There is no enterprise-wide "AI transformation programme", no twelve-month roadmap deck, and no attempt to roll a chat assistant out to every desk on day one. The model is deliberately narrow: pick a workflow that already has a number attached to it, fix that workflow, prove the number moved, then repeat.
The economics follow from the scarcity. FDE engagements at the vendor-owned firms are priced for Fortune 500 clients, and the value bar they describe is measured in tens of millions of US dollars of impact. That is precisely why the model, rather than the vendor, is what a Hong Kong mid-market enterprise should study.
Why does the FDE model matter for Hong Kong enterprises in particular?
Hong Kong enterprises face three structural conditions that make the FDE operating model unusually relevant: a high share of AI-skilled job postings but a shallow pool of senior applied-AI talent, a heavy dependence on legacy systems in financial services, logistics and property management, and vendor deployment programmes that are designed for much larger organisations elsewhere.
The talent condition is measurable. According to SalaryExpert data as of 26 August 2026, the average gross salary for an AI forward-deployed engineer in Hong Kong is HK$897,556. A team of three, with on-costs and tooling, is a HK$3 million to HK$4 million annual line item before a single workflow has been rebuilt. For a 200-person professional services firm, that is a board-level commitment with no guarantee the hires will stay. The Christian & Timbers study found demand for FDEs projected to rise 2,100 percent by year-end, which means the people you hire will be recruited away.
The gap between leaders and laggards is also widening faster than most boards realise. OpenAI's Enterprise Signals data published on 1 September 2026 shows that frontier firms, the top 10 percent by AI usage, now generate 8.3 times as many output tokens per active user as typical firms, up from 2.6 times in January. The difference is not headcount or budget. Frontier firms connect agents to company context and tools and make successful workflows repeatable, which is exactly what an FDE does.
Finally, the vendor programmes themselves are not built for you. The OpenAI Deployment Company, Ode with Anthropic and Microsoft's unit are staffed to serve the sponsors' portfolio companies and global enterprises. Some frontier vendors also restrict service availability in Hong Kong, a point covered in our analysis of Claudeforce for Hong Kong enterprises. The practical question for a Hong Kong COO is therefore not "how do I hire an FDE from OpenAI" but "how do I get FDE-style outcomes with the resources I actually have".
What are the three ways a Hong Kong enterprise can access FDE-style capability?
A Hong Kong enterprise has three realistic routes to forward-deployed capability: build an internal FDE team, buy embedded engineering from a vendor's deployment programme, or partner with a local implementation firm that works on the FDE model. Each route trades cost, speed, knowledge retention and vendor lock-in differently, and the right answer usually depends on how many workflows you intend to rebuild in the next 24 months.
Route 1: Build an internal FDE function. Best for organisations with five or more high-value workflows to rebuild and a genuine concern about proprietary process knowledge leaving the building. The Christian & Timbers interviews found many enterprises hiring internal FDE teams precisely to keep operating know-how away from the AI labs. The cost is the HK$3 million to HK$4 million annual line item above, a 6 to 9 month hiring lead time, and retention risk in a market where demand is rising twentyfold.
Route 2: Buy from a vendor deployment programme. Best for organisations already committed to one platform at scale, typically with more than 1,000 seats, where the vendor's own engineers are the right door. The advantage is that these engineers build for where the vendor's roadmap is heading. The disadvantages are minimum engagement sizes designed for global enterprises, contractual ambiguity about who owns the resulting workflows, and the risk that your operating processes become training data for the vendor's next product.
Route 3: Partner with a local firm working on the FDE model. Best for mid-market organisations with two to four priority workflows, legacy systems that need careful integration, and a requirement that the partner understands Hong Kong's regulatory context, including the Personal Data (Privacy) Ordinance. The advantage is speed to a first measurable result, usually within one quarter, and a partner who is accountable to you rather than to a model vendor. The trade-off is that you must insist on the FDE disciplines, embedded build, operating-metric accountability, and staying through adoption, rather than accepting a conventional project delivery.
A useful decision rule: if you cannot name the operating metric a workflow rebuild should move, you are not ready for any of the three routes. Start with a readiness assessment instead; our comparison of AI readiness assessment options and costs sets out what free, fixed-fee and Big Four approaches deliver.
What questions should you ask before signing an FDE-style engagement?
Five questions separate a genuine forward-deployed engagement from a rebranded consulting project: which operating metric the engagement is accountable for, who owns the resulting code and workflow, how much time engineers spend inside your environment versus at the vendor's office, what the handover to internal owners looks like, and how adoption will be measured after go-live. If a vendor cannot answer all five in writing, the engagement is not forward-deployed.
--- Which number moves? Insist on one operating metric you already report, with a baseline measured before the engagement begins.
--- Who owns the output? Code, prompts, evaluation sets and workflow documentation should be yours. Read the intellectual property clause before the pricing schedule.
--- Where do the engineers sit? An FDE spends the majority of the engagement inside your systems and meetings. A weekly status call is not embedding.
--- What does handover include? Named internal owners, runbooks, monitoring dashboards and at least one cycle of the internal team operating the workflow unaided.
--- How is adoption measured? Usage by frontline staff at 30, 60 and 90 days, not a launch announcement. A workflow with 12 percent adoption has not been deployed.
What goes wrong when organisations get the FDE model wrong?
The most common failures are predictable: treating the FDE as a contractor for a pre-decided solution, choosing a workflow with no measurable baseline, letting the engagement expand into a platform programme, and skipping handover so the capability leaves when the engineer does. Each failure converts an outcome-based engagement back into the pilot-and-slide-deck pattern that McKinsey's data shows has not moved EBIT.
The first failure is the most expensive. Organisations that have already decided what to build, and simply want hands to build it, remove the diagnostic phase that makes the model work. The FDE's value lies in judgement about where AI will move a number, and that judgement is wasted on a predetermined scope.
The second is choosing the wrong workflow. A workflow that is politically visible but has no clean baseline metric will produce an impressive demonstration and no evidence for the CFO. Our diagnostic on why scaling AI agents has not improved EBIT sets out how to select workflows that can actually be measured.
The third is scope creep into transformation. Once a first workflow succeeds, there is pressure to expand to an enterprise-wide programme. The FDE model resists this deliberately. The discipline is to repeat the narrow cycle, workflow by workflow, each with its own metric.
The fourth is handover. If internal owners are not named and trained, the capability departs with the engineer, and the organisation is left maintaining a system nobody understands. This is also the mechanism by which vendor lock-in occurs in practice.
How should you present the FDE model to your board?
Present it as a change in operating model, not a hiring request. The board case has three parts: evidence that enterprise AI returns depend on implementation rather than model access, a proposal to fund two or three workflow rebuilds with named operating metrics and a one-quarter checkpoint, and a clear statement of which of the three access routes you have chosen and why.
The evidence base is now strong enough to be uncontroversial. Five of the world's largest technology companies have committed more than US$9 billion to implementation units within four months. McKinsey's survey shows individual productivity gains without organisational financial impact. OpenAI's data shows the gap between frontier and typical firms tripling in six months. None of this requires a board to believe in AI; it only requires them to notice where the vendors are putting their own money.
The proposal should be modest by design. Two workflows, two metrics, one quarter, one checkpoint. A board that has already seen one AI pilot produce a slide deck and nothing else will fund a narrow, measurable engagement far more readily than a transformation programme.
Conclusion
The forward-deployed engineer is the AI industry's admission that models alone do not produce returns. What produces returns is someone with engineering skill and business judgement, sitting inside your organisation, accountable for a number you already track, staying long enough to see it move. The largest vendors have built billion-dollar units to provide exactly that to their largest customers.
A Hong Kong enterprise with 200 staff will not be a priority client for those units, and does not need to be. The operating model is available to anyone willing to insist on it: a diagnostic first, a narrow workflow with a baseline, engineers embedded rather than reporting, ownership of the output, and a handover that leaves the capability with you.
The hard parts of enterprise AI have never been the models. They are integration, adoption and measurement, and they are solved by people who know your business as well as the technology. We understand AI. We understand you. With UD by your side, AI never feels cold.
Now that you have the framework, the next step is identifying which two workflows in your organisation have a clean baseline metric and a realistic path to a first measurable result. We'll walk you through every step, from readiness assessment and workflow selection to embedded deployment, adoption tracking and handover to your own team, with 28 years of Hong Kong enterprise experience behind you.
Reviewed by the UD enterprise AI team. Sources: TechCrunch and Christian & Timbers (30 July 2026); OpenAI (11 May and 1 September 2026); CNBC (2 July 2026); Business Wire (15 July 2026); McKinsey State of AI 2026; SalaryExpert (26 August 2026).
