Most enterprise AI programmes do not stall because the model is weak. They stall in the gap between a convincing demo and a system that runs inside real workflows, with real permissions, real data and real people who would rather keep doing things the old way.
On 2 October 2026, Anthropic put a price on that gap. It committed US$100 million to train 10,000 Frontier Deployed Engineers by the end of 2027, with first cohorts drawn from Accenture, Bain, Capgemini, Deloitte, McKinsey, Morgan Stanley, Commonwealth Bank of Australia and Novo Nordisk.
When the companies that build the models start paying to train the people who deploy them, enterprise leaders should pay attention. This guide explains what a forward deployed engineer is, why the role suddenly matters, and how to decide whether your organisation should hire, borrow or partner for this capability.
What is a forward deployed engineer?
A forward deployed engineer (FDE) is a software engineer who works inside a customer's organisation, rather than at the vendor's office, to turn AI capability into a working production system. The FDE scopes the use case, connects the AI to real systems and data, clears security review and stays accountable for a business result.
The model was popularised by Palantir, which placed engineers on client sites to build directly against messy operational data. AI companies have adopted it because large language models are general-purpose: the value appears only once someone shapes them around a specific process.
Titles vary. Anthropic now uses Frontier Deployed Engineer for its credential. Others use applied AI engineer, deployment engineer or AI resident architect. The defining feature is not the title but the location and the accountability: the engineer sits with the business and owns whether the system is actually used.
Why are AI vendors investing so heavily in forward deployed engineers?
AI vendors are investing in forward deployed engineers because enterprise adoption is stuck between pilot and production. Models are capable, but integration, security review and change management decide whether value appears. Vendors now see deployment talent, not model quality, as the bottleneck to revenue and customer retention.
The signals in 2026 are hard to ignore:
--- Anthropic's Claude Frontier Academy pairs in-person training with a simulated enterprise deployment, then a 12-week residency in which each engineer leads a real Claude project at their own organisation.
--- According to Channel Dive, reported by Let's Data Science, Google Cloud confirmed 59 open forward deployed engineer roles in May 2026 across the US, London, Paris and Hong Kong.
--- The same report notes OpenAI launched a deployment company by acquiring engineering firm Tomoro, bringing in roughly 150 forward deployed engineers.
--- A Bloomberry analysis of job titles found forward deployed engineer postings up 1,165% year on year in early 2026.
The underlying driver is the pilot problem. MIT's NANDA initiative reported in 2025 that around 95% of enterprise generative AI pilots it studied showed no measurable profit-and-loss impact. Vendors have concluded that selling access is not enough. Someone has to make it work.
How is a forward deployed engineer different from a consultant or an internal AI team?
A forward deployed engineer differs from a consultant because they write and ship production code, not recommendations. They differ from an internal AI team because they bring deep platform expertise and patterns from many deployments. The trade-off is that they usually leave, so knowledge transfer must be planned from day one.
Versus a management consultant
A consultant typically delivers a strategy, a business case or a target operating model. An FDE delivers a running system. The best engagements combine both, which is why consulting firms are among the first cohorts in Anthropic's programme.
Versus a solutions architect
A solutions architect designs and advises during the sales cycle. An FDE stays through build, security review, launch and early adoption, and is judged on whether the business metric moves.
Versus your internal AI or IT team
Your team knows the business, the legacy systems and the politics. An FDE knows the platform's edge cases and has seen dozens of deployments fail and succeed. Neither replaces the other. Omdia analyst Peter Bryant, quoted by Channel Dive, noted that vendor FDEs often stay on site for a month at most, leaving partners and internal teams to sustain momentum.
What does a forward deployed engineering engagement actually deliver?
A well-run forward deployed engagement delivers one AI use case in production, measured against an agreed business metric, with security approval, documented integrations, trained users and an internal owner ready to take over. It is a delivery model for the first working system, not a permanent staffing arrangement.
Anthropic's own curriculum is a useful blueprint because it mirrors the stages enterprises struggle with. Engineers practise a deployment that runs from choosing the right use case, through security review, to handover. A typical engagement for a mid-sized enterprise looks like this:
--- Weeks 1 to 2: select one high-value process, agree the success metric and map the data and permissions it needs.
--- Weeks 3 to 6: build the integration, test it against real cases and clear information security and privacy review.
--- Weeks 7 to 10: launch to a pilot group, measure adoption and fix the friction users report.
--- Weeks 11 to 12: hand over runbooks, monitoring and ownership to an internal team.
If an engagement cannot name its handover owner in week one, it is a dependency, not a deployment.
Do you need a forward deployed engineer? A four-question framework
You need forward deployed capability when your AI use case touches several core systems, involves sensitive data, lacks internal engineers who know the platform, and has a deadline measured in months. Answer four questions on integration, data, skills and time; three or more yes answers mean you need it in some form.
Use these four questions before you buy another licence:
--- Integration depth: does the use case read from or write to two or more core systems such as ERP, CRM or a policy administration platform?
--- Data sensitivity: does it process personal data, client confidential information or financial transactions?
--- Internal skills: do you lack engineers who have shipped an AI agent into production before?
--- Time to value: does the business expect a measurable result within one or two quarters?
Hire, borrow or partner
--- Hire when AI is core to your product and you will run many use cases. Expect a long search and premium pay.
--- Borrow from a vendor when you have standardised on one platform and the vendor offers FDEs in your region.
--- Partner locally when you need someone who knows your language, regulators and legacy systems, and who will still be there after launch.
--- Hybrid is the most common answer: an external team builds the first system while two internal engineers shadow and take over.
This is a version of the build-or-buy decision. We compared one example in Copilot Studio vs AI Staff.
What does forward deployed engineering look like in Hong Kong?
In Hong Kong, forward deployed work has extra local demands: bilingual and Cantonese workflows, PDPO and sector regulators, legacy systems common in finance and property, and limited vendor FDE headcount in the region. That favours a hybrid model, with a local delivery partner and an internal owner from the start.
A financial services firm wants an agent that drafts suitability notes from client meeting records. The FDE work is less about the model and more about connecting to the CRM, applying HKMA and SFC expectations on record keeping, and designing reviewer checkpoints that compliance will sign off.
A logistics group wants exception handling for delayed shipments. Most of the effort goes into reading status data from three carrier systems and writing updates back safely. The pilot succeeds when dispatchers trust it enough to stop double-checking every case.
A professional services firm wants to search 20 years of bilingual precedent documents. The hard part is permissions: partners must not see matters they are conflicted out of. An engineer who understands both the platform and the firm's matter structure is what makes it safe to launch.
What are the common pitfalls with forward deployed engineering?
The most common pitfalls are treating the FDE as the owner instead of a builder, skipping knowledge transfer, letting a vendor engineer lock you into one platform, measuring outputs instead of business outcomes, and choosing a showcase use case rather than a painful, high-volume one. Each turns a promising launch into an orphaned system.
--- No internal owner. When the engineer leaves, nobody knows how the system works.
--- Vendor gravity. A vendor's engineer will naturally design around their own platform. Ask for portable data and documented interfaces.
--- Output metrics. Counting prompts or documents processed says little. Track cycle time, error rate or cost per case.
--- Showcase use cases. The demo that impresses the board is rarely the process that wastes the most hours. Start where the pain is measurable.
--- Ignoring adoption. A system that works but is not used is still a failed project.
How do you measure whether a forward deployed engagement worked?
Measure a forward deployed engagement on four outcomes: the business metric agreed in week one, active usage after 90 days, the time your internal team needs to make a change without outside help, and incidents or security exceptions. If usage falls once the engineer leaves, the engagement delivered a demo, not a capability.
--- Business metric: for example, claims handling time down 30%, or invoice exceptions cleared within one day.
--- Adoption: weekly active users as a share of the target group, measured 90 days after launch.
--- Self-sufficiency: days needed for your own team to ship a small change unaided.
--- Risk: security exceptions, privacy incidents and escalations per month.
These four numbers also make the board conversation easier, because they show return and control on a single page.
Conclusion: the scarce resource is deployment, not models
Anthropic, Google and OpenAI are all telling enterprise buyers the same thing with their money: access to a capable model is no longer the hard part. The hard part is the engineer who sits beside your operations team and turns that model into a system people trust and use.
You do not need to hire a team of forward deployed engineers to benefit from the idea. You need one painful use case, an agreed metric, a delivery partner who will build alongside you, and an internal owner who will still be there in a year.
We understand the cold edges of AI and the hard parts of your work, and UD has walked with Hong Kong enterprises for twenty-eight years, making technology a partnership with warmth.
Reviewed by the UD enterprise AI team. Programme details were checked on 8 October 2026 against Anthropic's announcement and the industry reporting linked above. Hiring figures come from third-party analyses and should be read as directional.
Find the Right First Use Case
Now that you have the framework, the next step is identifying the process where hands-on AI deployment will pay back fastest. Start with the free AI Ready Check. We'll walk you through every step, from use-case selection and integration design to security review, handover and performance tracking.
