Forward-deployed engineers: the missing link in AI adoption

95% of enterprise AI pilots fail to deliver measurable business impact. Not because the models are bad — GPT-4, Claude, Gemini are genuinely capable. They fail because nobody bridges the gap between what AI can do in a demo and what it needs to do inside a messy, real-world organisation with legacy systems, tribal knowledge, and processes held together by spreadsheets and goodwill.

That bridge has a name. It’s called a forward-deployed engineer.

FDE job postings grew over 800% in 2025. Salesforce is building a team of 1,000. OpenAI, Anthropic, and Ramp have all established dedicated FDE functions. And in the UK — where 35% of businesses cite lack of AI expertise as their top barrier — this role isn’t just trending. It’s the answer to a structural problem that no amount of SaaS licensing can solve.

The adoption crisis nobody talks about

The AI capability gap closed years ago. The adoption gap is wider than ever.

MIT’s NANDA study surveyed 350 employees, interviewed 150 business leaders, and analysed 300 public AI deployments. Their conclusion: the core failure isn’t model quality. It’s organisational “learning gaps.” Generic tools like ChatGPT work brilliantly for individuals because they’re flexible. They stall in enterprise settings because they don’t learn from or adjust to existing workflows.

Deloitte’s 2026 State of AI report puts it more starkly: only 6% of enterprises have moved generative AI beyond pilot into production. The other 94% are stuck in what the industry politely calls “experimentation” — which often means a few enthusiastic teams running demos while the rest of the organisation carries on as before.

The pattern is consistent across sectors. A financial services firm buys an AI platform. IT spends three months configuring it. Business users try it for a week, find it doesn’t understand their specific compliance requirements, and go back to email. The platform sits on a dashboard somewhere, generating reports nobody reads.

This isn’t a technology problem. It’s a deployment problem. And deploying AI into the real world requires someone who understands both the technology deeply AND the customer’s internal system architecture, politics, and pain points. That intersection is exactly where forward-deployed engineers operate.

What a forward-deployed engineer actually does

The term originated at Palantir in the early 2010s. They called them “Deltas” — engineers who embedded directly with government agencies, working on-site with real data to build solutions against real problems. At its peak, Palantir had more FDEs than traditional software engineers. The model created near-unchurnable accounts and, critically, many of Palantir’s most valuable product features originated in the field.

An FDE is not a consultant who writes recommendations. They’re a builder who ships working systems. The distinction matters.

A traditional consulting engagement produces a 60-page report with a transformation roadmap. An FDE produces a working prototype by Wednesday. Their code might be messy. It might get thrown away later. That’s not failure — that IS the process. The job is to deliver an outcome, not beautiful architecture.

The role combines technical depth (Python, cloud infrastructure, LLM integration, agentic systems) with skills that engineering culture typically undervalues: stakeholder management, business acumen, the ability to sit in a room with a operations manager and understand that the real problem isn’t what anyone said it was in the kickoff meeting.

Pragmatic Engineer describes FDEs as functioning like “startup CTOs” for customer projects — alternating between embedding with customer teams and contributing back to core product engineering. OpenAI’s FDE team, now 10+ engineers across 8 cities, focuses specifically on “hands-on” customer integration rather than traditional consulting-style engagements.

Why the UK needs this more than most

The UK faces a particularly acute version of the adoption crisis. An ANS/YouGov survey of over 1,000 IT decision-makers found that 35% of UK businesses identify lack of expertise as their top barrier to AI adoption, followed by cost concerns at 30% and uncertain ROI at 25%.

But these numbers mask a structural problem. UK enterprises run an average of 796 applications, with only 33% of them integrated. That’s not just a technology debt — it’s an adoption death sentence. You can’t deploy AI into an environment where two-thirds of the systems don’t talk to each other without someone who understands integration at a deep, practical level.

The UK mid-market is where the opportunity — and the need — is sharpest. Companies with 50-500 employees are often “so far behind” on digital transformation that even basic automation provides enormous value. But they don’t have the internal capability to evaluate AI solutions, let alone implement them. They’re the ones most likely to buy a platform, fail to configure it, and conclude that “AI doesn’t work for our business.”

London’s concentration of financial services, legal, logistics, and healthcare companies creates massive demand. These are industries drowning in document processing, compliance requirements, and customer communication — exactly the kind of complex, domain-specific work where generic AI tools fail and embedded engineers thrive.

Larger UK businesses face a different but related challenge. Their primary concerns are regulatory compliance (34%) and data security (31%). The EU AI Act, GDPR, and evolving UK-specific AI governance frameworks add layers of complexity that a simple API integration can’t address. An FDE who understands both the technology and the regulatory landscape isn’t a luxury. It’s risk management.

The 95% failure problem and how FDEs solve it

MIT’s research identified three specific failure modes that FDEs are uniquely positioned to fix.

Generic tools don’t adapt to workflows. ChatGPT is transformative for an individual knowledge worker because it handles anything. That same flexibility becomes a liability in enterprise settings, where the tool needs to understand specific data formats, approval chains, compliance rules, and integration points. FDEs do what SaaS onboarding teams can’t: they sit inside the business, observe how work actually flows (not how the process document says it flows), and build solutions that fit the reality.

Resource misallocation is rampant. Over half of AI budgets flow to sales and marketing tools, yet MIT found the biggest ROI appears in back-office automation — eliminating outsourcing, streamlining operations, reducing manual data entry. FDEs discover these opportunities because they’re embedded deep enough to see them. The PolyAI case is instructive: deployed for basic call handling at a cruise line, their voice system ended up becoming an early warning system for IT outages. At a delivery company, what started as tracking automation uncovered massive unmet demand for parcel collection — a service the company didn’t even offer. At a restaurant chain, booking automation led to demand pattern insights that drove a 13% revenue increase through targeted upselling.

None of these outcomes were in the original project scope. They emerged because someone was close enough to the problem to see patterns that no requirements document could have anticipated.

Building solo fails twice as often as partnering. Companies that build proprietary AI systems internally succeed only about a third as often as those working with specialised vendors. The FDE model is the reason: when an engineer embeds with your team, they bring the accumulated knowledge of every similar deployment they’ve done. They’ve seen your problem before, in a different industry, with different data, and they know which approaches work.

From gravel roads to superhighways

The most elegant aspect of the FDE model is how it turns custom work into scalable products.

When an FDE builds a quick, custom solution for one customer — call it a “gravel road” — the product team back at HQ watches what works. The patterns that repeat across multiple customers get generalised into reusable components. The gravel road becomes a paved superhighway. Every future customer gets onboarded faster because 80% of the problem has already been solved.

This is how Palantir built Foundry. It’s how PolyAI moved from custom voice deployments to a platform. And it’s the trajectory that Salesforce is betting on with its 1,000-strong FDE team for Agentforce.

The insight that everyone misses: the custom work isn’t the business model. The custom work is the R&D engine that discovers what product to build. An FDE agency capped at custom builds might scale to reasonable revenue. An FDE who discovers a product opportunity in logistics, healthcare, or financial services can build something worth orders of magnitude more.

For the UK market specifically, this pattern matters because the mid-market is large enough and underserved enough that the first FDE teams to deeply understand specific verticals — legal, property, hospitality, NHS operations — will have an information advantage that no competitor can replicate without doing the same embedded work.

The talent gap is the real bottleneck

FDE job postings grew 800-1,165% year-over-year in 2025. October 2025 saw the highest number of FDE job postings ever recorded. Yet only 1.24% of companies currently have the role, according to Pave’s compensation data.

This gap explains a lot. The demand for AI transformation is enormous. The supply of people who can actually execute it — who combine deep technical skills with the communication, adaptability, and business acumen to embed with customers — is tiny. Most AI talent sits at frontier labs. Enterprises don’t have people who understand both AI deeply and their own system architecture. That intersection is where FDEs live, and it’s spectacularly underserved.

The skills required go beyond writing code. The Palantir model explicitly sought “heretics” — people who know their industry deeply, see that how things are done is fundamentally broken, and have the drive to change it. They wanted prototypers, not craftsmen. People who could “eat a lot of pain” to get a solution working fast, where beautiful code was secondary to working outcomes.

This profile is rare. It requires someone who loves outcomes over craft, people over code, and impact over comfort. Traditional engineering culture optimises for the opposite — clean abstractions, test coverage, architectural purity. None of that matters if the solution doesn’t ship.

What comes next

AI is bigger than internet, mobile, and cloud combined. Every recommender system, every ad platform, every business process needs to be re-architected for generative AI. That’s decades of work, and the organisations that move first will compound their advantage.

The FDE model isn’t a temporary hiring trend. It’s the recognition that deploying AI is fundamentally different from deploying traditional software. You can’t ship an AI product to a customer and expect self-service adoption. The technology is too new, the use cases too undefined, the integration too complex. Someone has to be in the room, working with real data, building against real constraints, iterating in real time.

For UK businesses — especially the mid-market companies sitting on legacy processes and fragmented tech stacks — the choice is increasingly clear. You can keep buying AI platforms and hoping adoption happens organically. Or you can bring in someone who’ll embed with your team, understand your specific mess, and build something that actually works.

The 95% failure rate is not inevitable. It’s the result of a deployment model that treats AI like traditional software — ship it and they will come. The companies that succeed will be the ones who understood, early, that AI adoption is a human problem that requires human solutions. Forward-deployed engineers are those humans.