A Hong Kong logistics group signs a frontier AI contract in March. By June the model is live, the licences are paid, and the shipment exception workflow it was bought to fix still runs on three spreadsheets and a WhatsApp group. Nothing broke. Nobody was negligent. The vendor delivered a model, and the organisation needed a system.
That gap has a name now, and in 2026 it has a job title attached to it. The forward deployed engineer is the fastest-growing role in enterprise AI, and understanding what it is has become a prerequisite for evaluating almost any serious AI proposal you will receive this year.
What is a forward deployed engineer?
A forward deployed engineer, or FDE, is a senior engineer who works inside the customer's own environment rather than at the vendor's office. They learn your data, your systems and your internal politics, then build and ship production software against that reality, feeding what they learn back into the vendor's core product.
The role sits between four familiar jobs. It is part software engineer, part solutions architect, part management consultant, and part startup CTO.
The distinction that matters to a buyer is scope of accountability. A consultant advises and leaves a document. A systems integrator implements to a signed specification. An FDE is accountable for the outcome working in your environment, including the parts of your environment nobody documented.
The four things an FDE is expected to do
--- Sit physically or virtually inside the customer's team, often for months
--- Write and ship production code against legacy systems, not slideware
--- Redesign the workflow around the model, not just connect the model to the workflow
--- Return findings to the vendor's product team so the next customer needs less bespoke work
Why did OpenAI and Anthropic both build deployment companies in 2026?
In May 2026 both frontier labs created separate, heavily capitalised businesses whose only job is getting their models into production inside enterprises. This was not a marketing move. It was an admission that selling model access alone was not converting into deployed systems fast enough.
Anthropic formed a joint venture on 4 May 2026, valued at US$1.5 billion, backed by Blackstone, Hellman & Friedman and Goldman Sachs, with a stated focus on mid-sized companies that lack the in-house resources to run frontier deployments themselves.
OpenAI followed on 11 May 2026 with a majority-owned subsidiary, the Deployment Company, which raised more than US$4 billion from 19 investors including TPG, Bain Capital and Goldman Sachs, and acquired the consulting and engineering firm Tomoro to add roughly 150 deployment engineers on day one.
As CIO reported, the logic behind both ventures is the same: raise capital from alternative asset managers, gain preferred access to those managers' portfolio companies, and capture the implementation value that was previously flowing to systems integrators.
For a Hong Kong department head, the strategic reading is blunt. The companies that build the models have concluded that the model is not the product. The deployed workflow is the product.
How does the forward deployed model differ from traditional IT consulting?
Traditional consulting sells a defined scope against a signed specification and manages change requests when reality differs. The forward deployed model assumes reality will differ, prices for that assumption, and puts the engineer inside the organisation so discovery and delivery happen at the same time.
Palantir invented the function in 2008 for exactly this reason. Its customers had messy, sensitive, non-standard data estates, and no specification written in advance survived contact with them. OpenAI and Anthropic rebuilt the function for the large language model era.
Four practical differences a buyer will feel
--- Discovery is continuous, not a phase that ends before build begins
--- The engineer has commit rights in your systems, which is a security and governance decision, not just a procurement one
--- Success is measured by workflow adoption, not by deliverables accepted
--- The vendor has an incentive to generalise your solution, because that is how their product improves
That last point cuts both ways. It means faster improvement and lower future cost. It also means you should read the intellectual property and data-use clauses carefully before signing.
What does a forward deployed engineer actually cost?
Forward deployed engineering is the most expensive delivery model in enterprise software, and the numbers have moved sharply upward in 2026. Compensation data compiled across roughly 1,200 FDEs puts median mid-level total compensation at US$385,000, staff level at US$610,000, and principal engineers at frontier labs clearing US$1.2 million.
Palantir's median for the equivalent role sits near US$215,000, which means the frontier labs are paying two to three and a half times the established benchmark for the same seniority.
Equity now represents between 55% and 70% of total compensation at the top of that market, up from 35% to 45% in 2024. That structure matters to buyers, because equity-heavy packages are how vendors afford to embed people at rates a Hong Kong enterprise could not match by direct hiring.
What this means for your budget line
--- Direct hiring an FDE-calibre engineer in Hong Kong competes against packages built on frontier-lab equity, which most non-technology firms cannot match
--- Buying the capability as a service converts an unwinnable recruitment problem into a contracted cost
--- The relevant comparison is not FDE cost against a cheaper contractor, but FDE cost against the carrying cost of a pilot that never reaches production
TechCrunch reported on 30 July 2026 that the role has become the AI industry's central talent obsession, which is a polite way of saying supply is short and rates are firm.
When does a Hong Kong enterprise actually need this model?
The forward deployed model earns its cost when the difficulty of your problem lives in your environment rather than in the model. If the hard part is your data, your legacy systems, your regulatory constraints or your internal process, embedding an engineer is proportionate. If the hard part is choosing a tool, it is not.
Three signals suggest you are in forward deployed territory.
Signal one: your data does not exist in the form the model needs. A property management group with 20 years of maintenance records across a legacy system, scanned PDFs and a WhatsApp archive does not have a model problem. It has a data engineering problem wearing an AI costume.
Signal two: the workflow has to change for the value to appear. Gartner has forecast that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from under 5% in 2025. Agents that take actions require somebody to redesign approval paths, exception handling and audit trails. That is organisational work, not configuration.
Signal three: compliance sits inside the build, not after it. For a Hong Kong financial services or professional services firm, personal data handling under the Personal Data (Privacy) Ordinance has to be designed into the pipeline. Retrofitting it after a pilot succeeds is how pilots die at the governance gate.
Conversely, if your requirement is document summarisation for a 40-person team using standard file formats, a well-configured off-the-shelf product will beat an embedded engineering engagement on every measure including speed.
How do you evaluate a forward deployed engagement?
Evaluate the engagement on transfer, not on delivery. The question is not whether the vendor's engineer can make the system work while they are sitting in your office. It is what remains functioning and maintainable in your organisation ninety days after they leave.
Six questions to ask any vendor proposing embedded engineers
--- Who specifically is being embedded, what have they shipped before, and can we interview them?
--- What access will they hold in our systems, under what identity, and who reviews it?
--- What is the defined handover artefact, and which of our people are named as receivers?
--- What happens to the code and the workflow logic if we end the relationship in month four?
--- Which of our learnings feed back into your product, and what does our contract say about that?
--- What is the measured business outcome we are both accountable for, stated as a number?
If a vendor cannot answer the last question with a number your finance director recognises, the engagement is a research project with an implementation label on it.
What goes wrong with forward deployed engagements?
Forward deployed engagements fail in predictable ways, and almost none of the failures are technical. They come from access, dependency, scope and measurement, which are all governance issues that sit with the buying organisation rather than the vendor.
Failure one: dependency replaces capability. The engineer becomes the only person who understands the system. Eighteen months later the organisation is paying a retainer to keep the lights on and cannot change a business rule without a purchase order.
Failure two: access is granted informally. Under time pressure, an embedded engineer is given broad production credentials because narrow ones would slow delivery. That decision is rarely revisited and rarely documented, and it will be the first thing an auditor asks about.
Failure three: scope expands into the gaps. Because the engineer sits inside the team, adjacent problems attach themselves to the engagement. Nine months in, nobody can say which of the original objectives were met.
Failure four: nobody defined the number. The single most common cause of expensive disappointment is that success was described qualitatively at the outset. Without a baseline measurement taken before work begins, there is no defensible way to report value afterwards.
Each of these is preventable at contract stage and expensive to fix afterwards.
What should you take away from this?
The rise of the forward deployed engineer confirms something Hong Kong enterprise leaders have suspected since their first pilot: the difficulty was never the model. The difficulty is the distance between a capable model and a changed workflow inside a real organisation with real systems and real people.
The frontier labs have now put billions of dollars behind that conclusion. Your evaluation framework should follow. When a vendor presents an AI proposal this year, the questions that separate a good decision from an expensive one are about who will sit inside your organisation, what they will be accountable for, and what remains after they go.
Technology has never been the whole answer. Someone has to understand your building, your legacy system, your team's habits and your regulator's expectations, and then stay long enough to make it work. We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team, Hong Kong.
Where to start
Before you evaluate anyone's embedded engineers, it helps to know which of your workflows are actually ready for them. We'll walk you through every step, from AI readiness assessment and use-case prioritisation to vendor evaluation, deployment and performance tracking, with 28 years of Hong Kong enterprise experience behind each one.
