The Forward Deployed Engineer and the Seam Where Deals Die

Most enterprise software deals do not die in the buying committee. They die at a specific seam — the seam between the demo that worked in the sales pitch and the production system that has to work inside the customer's actual environment. The buyer signs off on the demo. The vendor's account executive moves on to the next opportunity. A solutions engineer scopes an architecture. Professional services takes over the implementation. Customer success picks up the relationship after go-live. The product team, two layers removed from any of this, ships features based on aggregated feedback that arrives months late and missing context.

By the time the customer's CFO asks the obvious question — did this thing move the metric we bought it to move — too many people have touched the work for anyone to give a clean answer. The deal does not die in a single moment. It dies in the slow accumulation of translation losses across a five-person handoff chain. The customer renews, possibly. The customer expands, rarely. The next deal in the same vertical takes just as long, because nothing was actually learned.

This is the problem the Forward Deployed Engineer was invented to solve. The role itself is having a moment — OpenAI, Anthropic, Palantir, Scale, Databricks, Salesforce, and Accenture have all announced major FDE-style functions in the last twenty-four months.[^1] But the role is not really the point. The structural insight underneath the role is the point, and that insight applies to every company selling complex software to enterprise buyers, regardless of whether the company can afford a frontier AI lab's compensation budget.

This is a long-form examination of where the role came from, what it actually does, where it fits, and — for the ninety-nine percent of enterprise GTM operators who cannot hire ten Forward Deployed Engineers — what to do instead.

1. A short history of the role

‍

The Forward Deployed Engineer was invented at Palantir, founded in 2003 by Peter Thiel, Alex Karp, Nathan Gettings, Joe Lonsdale, and Stephen Cohen.[^2] The company's first customer was the Central Intelligence Agency through its venture arm In-Q-Tel.[^3] The product was a data integration platform called Gotham, designed to help intelligence analysts find patterns across disparate, classified, and structurally incompatible datasets.
‍

The problem Palantir ran into immediately was not a product problem. It was an installation problem. Gotham could not be shipped, downloaded, and turned on. The data inside the CIA did not look like the data inside the FBI, which did not look like the data inside a defense contractor, which did not look like the data inside a bank. Every deployment required someone to sit inside the customer's environment, understand the customer's actual workflow, write integration code against the customer's specific systems, and produce a working installation that was tailored to that one customer.

Palantir hired engineers to do this work. They were not consultants because they wrote production code. They were not solutions architects because they were not designing reference architectures from outside — they were building the actual system from inside the customer's wire. They were not implementation engineers in the traditional sense because their work fed directly back into the core product roadmap. Karp later described them by analogy to the waiters at high-end French restaurants who understood the kitchen well enough to recommend a dish tailored to each diner.[^4] The kitchen and the dining room collapsed into the same role.

For nearly two decades, this was a Palantir-specific phenomenon. The role existed at a handful of other companies under different names — Intercom called them solutions engineers but expected them to write production integrations, Rippling embedded engineers in customer environments to handle the complexity of HR-payroll-IT integration, Anduril built the function explicitly modeled on Palantir given the defense context — but nobody else fully committed to it.[^5] The conventional enterprise software playbook was the opposite: ship a self-serve product, hire solutions engineers to support sales, hire customer success to drive adoption, and let professional services or system integrators handle the messy deployment work as a separate revenue line with separate margins.

The conventional playbook worked, mostly, because enterprise software was relatively stable. SAP, Salesforce, and Oracle could afford long deployment cycles because the underlying products changed slowly and the integrations, once built, lasted years. The seam between sales and delivery was real, but the translation losses were manageable because there was time to absorb them.

Then ChatGPT shipped in November 2022.

What followed was an enterprise AI adoption wave that ran into a wall almost immediately. MIT research published in 2025 found that ninety-five percent of enterprise AI pilots produced zero measurable return.[^6] The failures were not model failures. The models worked. The failures happened at the seam between the model and the customer's actual environment — the data was messy, the workflows did not match the assumptions in the demo, the integrations were brittle, the evaluation frameworks did not exist, the security review took eleven months. The last mile broke everything, and the seam where it broke was exactly the seam Palantir had been quietly working around for twenty years.

In 2024, OpenAI formalised its FDE practice.[^7] Anthropic followed shortly after, then Scale AI, Databricks, Salesforce. Financial Times reported that hiring interest in the role grew eight hundred percent between January 2025 and early 2026.[^8] In May 2026, OpenAI announced a dedicated FDE venture called The Deployment Company with reported private equity backing in excess of four billion dollars and a structure reported by Reuters and Financial Times to guarantee investors a seventeen and a half percent annual return over five years, though OpenAI has not confirmed that figure.[^9] The venture is led by COO Brad Lightcap. As part of the launch, OpenAI acquired Tomoro, an applied AI consulting firm with approximately one hundred fifty engineers and deployment experience at Tesco, Virgin Atlantic, and Supercell, to seed the team.[^10] Days earlier, Anthropic announced a parallel structure — a new enterprise services firm with Blackstone, Hellman and Friedman, and Goldman Sachs as founding partners.[^11] In March 2026, Accenture launched its own forward deployed engineering practice in partnership with Microsoft.[^12]

What had been a Palantir-specific operating model for twenty years became, in twenty-four months, the consensus answer to the enterprise AI implementation problem. (See the timeline diagram in this series.)

2. The structural insight

The Forward Deployed Engineer matters less as a role and more as a diagnosis of where enterprise software actually breaks. To understand the diagnosis, you have to look at what fails when you do not have one.

In the traditional model, the customer's reality is captured by the account executive, encoded into a statement of work by the solutions engineer, translated into a project plan by professional services, handed to a customer success manager for adoption, and only occasionally and incompletely fed back to the product team. Five layers. Five translations. At each translation, the most context-rich and least documented information — what the customer actually meant, what their environment actually looks like, what would actually move the metric — is the first thing to fall out. What survives the chain is the structured data: contract terms, license counts, project milestones, NPS scores. The structured data tells you whether the deal closed. It does not tell you whether the deal worked. (See the handoff-chain diagram in this series.)

‍

The cost of those translations was manageable when enterprise software was stable. AI products do not have that property. They change weekly. The model that worked in last quarter's demo is replaced by a better model that requires a different prompting strategy. The eval suite that passed in March fails in May because the customer's data has drifted. The integration that worked against the customer's legacy ticketing system breaks the first time the customer rolls out a new release. Every translation in the handoff chain is now a place where time is lost, and time, in enterprise AI, is the entire competitive moat.

The Forward Deployed Engineer exists to remove the translations. The structural innovation is not the engineer. The structural innovation is the collapse of the chain into a single seat. One person who closes the deal, scopes the architecture, writes the code, drives adoption, and feeds the patterns back to product. The same person, the same week. No translations because there are no handoffs to translate across.

There is a useful way to think about why this works mechanically. In a five-stage handoff chain, the cost of moving information between stages compounds. If each handoff loses ten percent of the relevant context — a conservative estimate when the receiver does not have the technical depth to ask the right questions — then after five handoffs you have retained roughly fifty-nine percent of the original information. If each handoff loses twenty percent, which is closer to what actually happens when sales hands off to professional services, you have retained thirty-three percent. By the time the feedback reaches the product team, two-thirds of what mattered is gone, and the team is making roadmap decisions on the basis of a degraded signal. The FDE function eliminates these compounding losses by eliminating the handoffs.

This is also why the FDE function tends to be associated with companies whose products change rapidly. A mature product with a stable feature set can tolerate translation losses because the patterns it serves are already known. An immature product with a rapidly evolving feature set cannot, because the patterns it needs to discover are exactly the patterns that fall out of the handoff chain. This is the structural reason the role lives at frontier AI companies and not at SAP.

3. The role and its responsibilities

The cleanest working definition of the role is from a 2026 ZTABS analysis: the FDE is an engineer who writes production code inside the customer's environment, against the customer's data, on the customer's timeline, and feeds what they learn directly back into the product.[^13] Everything else about the role flows from that definition.

In practice, the responsibilities cluster into four buckets, and a single FDE moves between them within a single week.

‍

Discovery. Before writing code, the FDE sits with the customer and pulls apart reality. Not requirements as written in a procurement document — actual reality. Who runs the workflow today. What tools they use. What data exists, where it lives, who owns it, what condition it is in. What the failure mode is when the current process breaks. What the customer says they want versus what they actually need. This is consulting work, but it is consulting done by someone who is going to write the code, which means it is consulting that ends with a useful artifact rather than a slide deck. The hardest part of discovery, and the part traditional solutions engineering routinely fails at, is finding the wedge problem worth solving first. Most enterprise AI deployments fail not because they tried to do too little but because they tried to do too much.[^14] The FDE's job in discovery is to identify the smallest possible problem that, if solved, would justify the rest of the engagement.

Build. The FDE writes production code against the customer's environment. In 2026, this is overwhelmingly AI infrastructure work — retrieval augmented generation pipelines, evaluation frameworks, agent orchestration, tool calling layers, fine-tuning data preparation, prompt engineering at production scale.[^15] The output is a working system, not a prototype. A typical FDE engagement ships a first working deployment in two to six weeks. The engineering is constrained by the customer's actual systems, which means the FDE is often writing glue code to legacy databases, undocumented internal APIs, and homegrown identity systems that the product team has never seen. The code the FDE writes is sometimes ugly. It is almost always specific to that customer. The temptation to refactor it into something general is constant, and resisting that temptation is part of the job. Generalization happens at the product team level, not at the FDE level. The FDE's job is to ship something that works for this customer this quarter.

Hand-off. Once something works, the FDE transitions the customer's team into operating it. This is not training in the traditional sense. It is more like an apprenticeship that the FDE runs while continuing to ship features. The deliverables are documentation, runbooks, monitoring dashboards, evaluation suites, and a clear understanding of what the customer's team owns versus what the vendor still owns. The hand-off is the part most FDE programs fail at, because it requires the FDE to stop building and start writing things down, and the personality type that excels at the first half tends to resist the second half.[^16] The companies that have built durable FDE functions have figured out that hand-off is a separate skill and have either trained for it explicitly or paired their builder FDEs with hand-off specialists who do nothing else.

Feedback to product. This is the part that distinguishes the FDE from a high-end consultant. Everything the FDE learns in the field — every edge case, every workaround, every place the product almost worked but did not quite — becomes input to the product team. The patterns that recur across multiple deployments become product features. The edge cases become evaluation suites. The integrations that the FDE wrote by hand for one customer become shipped integrations for all customers. The FDE function is, in effect, a continuously running market research operation that produces working code as its research output. Companies that run FDE functions well treat this feedback loop as the entire reason the function exists. Companies that run it badly treat the FDE as a high-margin consulting business and wonder why the product is not getting any better.

The compensation reflects the difficulty. Forward Deployed Engineer base salaries in 2026 run from one hundred seventy-five thousand to two hundred sixty thousand dollars at established AI companies, with on-target earnings of two hundred thirty thousand to three hundred sixty thousand.[^17] Travel can hit fifty percent. Google Cloud FDE base starts at one hundred twenty-seven thousand. OpenAI mid-level FDE in San Francisco runs two hundred twenty to two hundred eighty thousand base.[^18] The variable compensation typically sits at thirty to thirty-five percent and is tied to deployment outcomes rather than booked revenue, which is one of the structural innovations of the role — it aligns the FDE with whether the customer actually got value, not with whether the contract was signed.

According to compensation benchmarking firm Pave, the prevalence of forward deployed engineers in their dataset grew from 0.3% of companies in January 2023 to 1.6% in January 2026, with a notable inflection point in early 2025.[^19] Forward deployed engineers earn just 5.3% less than software engineers on a level-normalized basis, placing them inside most existing engineering pay bands. The market is signalling clearly that this is a technical role first and a customer-facing one second.

4. The three buyers of the role

The strangeness of the role becomes clearer when you look at who actually buys it inside an AI company. The FDE has three distinct internal buyers, each hiring the role for a different job, and the role's difficulty comes from the fact that it has to serve all three simultaneously. (See the three-jobs diagram in this series.)

The sales job: prove it works on real data. In enterprise AI, the demo is dead. Buyers in 2026 have seen too many slideware demos to be impressed by another one. The thing that closes a deal now is a working system running on the buyer's own data, doing the buyer's actual workflow, with the buyer's own people able to break it and watch how it recovers. The FDE is hired by the sales motion to produce this artifact. In some companies the FDE arrives before the contract is signed, runs a paid two-week proof of concept against real data, and the contract is signed on the basis of what was produced.[^20] This is closer to how high-end professional services firms used to sell — engineering hours as the wedge — than to how SaaS companies have sold for the last decade. It also has a second-order effect that the SaaS model lost: when an engineer who is going to be involved in the deployment is also involved in the sale, the customer is buying from someone who knows what they are signing up for. The over-promise problem that destroyed so many early enterprise AI deals largely disappears.

The customer job: deliver outcomes in weeks. The customer's CFO has approved an AI budget on the promise that AI will move a specific business metric. Reduce handle time in the contact centre. Increase first-call resolution. Cut underwriting cycle time. Shrink the time from claim to settlement. The customer does not care about the model architecture. The customer cares about the metric. The FDE is hired by the customer to move the metric, and the metric typically has to move in weeks, not quarters, because the CFO's patience has limits and the next budget cycle is always approaching. This is the job that most enterprise AI vendors get wrong because they sell against the model architecture and not against the metric. The FDE's value to the customer is that the engineer in the room is being measured the same way the customer's own team is being measured — by whether the number moved.

The product job: find the next feature before competitors do. Every AI company in 2026 is racing against every other AI company to figure out which patterns of enterprise deployment generalise. The first company to discover that, say, contract review in pharmaceutical regulatory affairs has a specific structure that lends itself to a productisable agent — that company wins the vertical. The FDE function is the discovery mechanism. By running ten parallel deployments across ten customers, an FDE team produces a continuous stream of insight about which patterns are worth turning into product. The product team buys this signal from the FDE function and pays for it in headcount.

The compensation is not the strangest part of the role. The strangest part is that the same person, on the same Tuesday, is closing a deal, shipping production code, and writing a feature spec for the product team. This is a role that almost nobody is naturally good at, which is why hiring for it is so hard and why the companies that have built strong FDE functions guard them like aircraft carrier crews. The frontier labs are competing for a talent pool of perhaps two or three thousand people globally who can do all three jobs at the level enterprise customers expect, and the bidding has gotten serious enough that OpenAI's acquisition of Tomoro and Anthropic's joint venture with Blackstone are best understood as labour-market plays first and product strategy plays second.[^21]

5. Where the FDE function fits, and where it does not

The FDE function is expensive. A team of ten FDEs at OpenAI compensation levels costs three to four million dollars a year in salary alone, before travel, before opportunity cost on the engineers' alternative use, before the management overhead of running a function that is half engineering and half customer-facing. Not every company should build one. The conditions under which an FDE function pays for itself are specific and worth being honest about.

The FDE function fits best in the upper-left quadrant of the deal-size-by-product-readiness matrix: large deals where the product is still being shaped by the field. In this zone the cost of a senior engineer in a customer environment is recovered in a single deployment, and the field signal generated is genuinely useful to product. This is where Palantir lived for two decades and where the frontier AI labs live today.

It does not fit in the lower-right quadrant — small deals with mature, repeatable products. A SaaS company selling a fifty thousand dollar annual subscription cannot afford a Forward Deployed Engineer; the math does not work even before the engineer leaves the office. For those companies, customer success managers and good documentation are the right answer, and trying to build an FDE function will produce a sub-scale, demoralised team and a customer success function that resents them.

The harder cases are the diagonal quadrants. Large deals with mature products typically belong to solutions engineering, not to FDE — the product already works, the customer just needs help installing it, and the role is fundamentally pre-sales. Small deals with immature products belong to nobody clean; this is usually a sign that the company has product-market fit problems that an FDE function cannot solve, and trying to solve them with FDEs is an expensive way to delay the harder conversation.

A useful heuristic: if the average deal size is below five hundred thousand dollars annually, the FDE function probably does not pay for itself. If the deal size is above two million and the product is less than three years old, the function is probably underbuilt. The frontier AI companies are running deals in the eight-figure range against products that change weekly, which is why they have invested so heavily and why they are still hiring aggressively.

The other condition worth naming is regulatory and data sensitivity. In financial services, healthcare, defense, and parts of insurance, the customer cannot let the vendor's engineers anywhere near production data except under specific contractual structures and on-premises deployment. The FDE function in these contexts looks different: longer engagements, deeper certifications, sometimes literal security clearances. Palantir's entire history was built on this constraint.[^22] Anthropic's joint venture with Blackstone, Hellman and Friedman, and Goldman Sachs reportedly exists precisely to navigate this constraint at the frontier of regulated finance, where the underlying buyers cannot let a standard vendor relationship touch their data and need a counterparty with the legal structure to take on that liability.

6. Companies running the model in 2026

The clearest way to see what the role looks like in practice is to look at the companies running it now.

Palantir. The original. Twenty-plus years of FDE practice across government, defense, and large industrial commercial customers. Palantir's FDE function is the deepest in the industry by a wide margin and its alumni population is the talent base from which every other company is now trying to build. The company has been criticised for many things, but the FDE model is not one of them — every serious analysis of how Palantir wins enterprise deals comes back to the function.[^23]

OpenAI. Formalised the FDE practice in 2024. In May 2026, announced The Deployment Company, a dedicated FDE venture with reported private equity backing in excess of four billion dollars.[^9] The venture is led by COO Brad Lightcap. As part of the launch, OpenAI acquired Tomoro.[^10]

Anthropic. Confirmed its parallel initiative on May 4, 2026, days before OpenAI's announcement. The structure is a new enterprise services firm with Blackstone, Hellman and Friedman, and Goldman Sachs as founding partners.[^11] The financial sponsorship suggests a specific bet that regulated financial services and large industrial enterprise are the FDE-shaped markets that Anthropic intends to win.

Scale AI, Databricks, Salesforce. All three have built FDE-style functions, with Salesforce in particular leaning into the model heavily as part of its Agentforce push.[^24] Scale's function is closer to the original Palantir model given the company's defense and government work. Databricks runs a more solutions-engineering-style version of the role.

Anduril. Has built an FDE function explicitly modeled on Palantir's, which is unsurprising given that several of its early leaders came from Palantir. The defense context creates the same on-premises, security-cleared deployment conditions that made the model work at Palantir originally.

Intercom, Rippling, Vanta, Reducto. Examples of non-frontier-AI companies that have built FDE-style functions for specific reasons.[^13] Intercom and Rippling because their products integrate deeply with customers' internal systems. Vanta and Reducto because their AI products in compliance and document processing require engineering-heavy customer-side configuration.

Accenture and Microsoft. In March 2026, Accenture launched a dedicated forward deployed engineering practice in partnership with Microsoft.[^12] This is the consulting industry's response to the model — packaging an FDE-like delivery capability as a service offering. Whether the cultural fit holds is an open question; the consulting model and the FDE model have historically been in tension because consultants do not write production code that goes back into a product roadmap.

The pattern across all of these is consistent. Each company has either an AI product that breaks at the last mile, an enterprise deal motion where the deal cannot be closed without an engineering proof, or both. The companies that have most committed to the model are the ones whose product roadmaps are still in motion. As products mature and patterns stabilise, FDE functions tend to evolve into solutions engineering, and the surface area of the role shrinks. This is not a failure of the role; it is the natural lifecycle. Palantir's FDE function exists in something like its mature form precisely because the company's products have remained, by design, configurable rather than fully productised.

7. What to do if you do not have a frontier AI budget

This is where most analysis of the Forward Deployed Engineer stops, and it is exactly where the analysis becomes useful for everyone else. The upper-left of the FDE matrix — large deals with research-stage products — describes maybe two hundred companies in the world. The rest of enterprise software lives in the other three quadrants, and the seam-where-deals-die problem applies to all of it.

The structural insight survives the budget constraint. The collapse-the-handoff-chain logic does not require a four-billion-dollar venture. It requires three operating choices, and any GTM team can make them on Monday.

One: send senior people, not junior people, into the discovery motion. The first FDE-equivalent decision is who actually sits in the customer's environment doing the diagnostic work. In most GTM organizations this is a junior BDR running a discovery call from a script, or at best a solutions engineer running a demo. The FDE insight is that the person doing discovery has to be senior enough to act on what they find. Otherwise the information falls back into the handoff chain and dies in translation.

At GTM HQ, this is the principle behind our PIPELINE methodology.[^25] We treat the enterprise buyer journey as a two-mountain model with the contract as the valley between them. The mountain before the contract is discovery; the mountain after is delivery. The same senior pair carries the customer's reality across both. The junior operator does targeted permission-based outreach to get the meeting; the senior practitioner does the work that follows. Senior time scarcity is the upsell mechanic — the prospect knows they are getting the person who will do the work, not a handoff to someone less expensive. This is the cheapest available approximation of the FDE structure for companies that cannot afford ten engineers at four hundred thousand dollars each.

Two: replace slideware with a working artifact, even a small one. The FDE produces a working system in weeks. A GTM team without engineering depth cannot produce a working system, but it can produce a working artifact — a diagnostic document that does for the customer's account what an FDE does for the customer's data. At GTM HQ we call this the Signal artifact.[^26] It is an eight-section read of a target account covering narrative, website, content, LinkedIn presence, AEO posture, founder voice, enterprise sales markers, and prioritized recommendations. We send it to a prospect before any sales conversation. The Signal artifact does the same job the FDE proof-of-concept does at OpenAI: it converts an abstract pitch into a concrete piece of work the buyer can react to.

The mechanics are different, but the operating principle is identical. Instead of asking a prospect to evaluate a pitch, you give them something to evaluate. The thing you give them is built on their reality, not yours. The conversation that follows is not a discovery call. It is a working session. The Signal artifact also has the second-order property the FDE proof-of-concept has: it forces the firm producing it to demonstrate that it can do the work before being paid. This is how high-end professional services have always sold. The SaaS industry forgot this lesson for fifteen years. The FDE function is, in part, the industry remembering.

Three: build the feedback loop, even at small scale. The FDE feeds field signal back to product. A GTM operation can do the same thing at smaller scale by treating every engagement as research, documenting what was learned, and letting the patterns shape what the firm sells next. This is the operating logic of paid R&D — the first ten engagements run at near-cost specifically because the goal is not margin but pattern discovery. The patterns become productized offerings, and the offerings become repeatable revenue.

At GTM HQ, the ninety-day build is the manifestation of this. Every operator log, every Signal artifact, every funnel-math case study is documentation of what works and what does not. The first ten engagements are paid R&D by design. By engagement eleven the firm is selling proven patterns, not aspirational ones. This is the cheapest available approximation of the FDE feedback-to-product loop. It also produces a second asset that the traditional consulting model has historically been bad at: institutional memory. A consulting firm that does not document what it learns repeats the same mistakes across clients. A firm that does document them compounds.

None of this requires a four-billion-dollar venture or a Palantir alumni network. It requires the operating choice that the seam between sales and delivery is where deals die, and that closing the seam is worth more than scaling around it. The Forward Deployed Engineer is the most expensive version of that choice. The Signal artifact, the senior-led discovery motion, and the productized-after-pattern delivery model are the smaller versions. They cost less. They generalize further. And for the ninety-nine percent of companies that will never run a frontier AI lab budget, they are the operating model worth borrowing.

8. The checklist

Whether you are running a five-person GTM agency, a Series A startup with two founders doing sales, or a fifty-person revenue org at a Series C SaaS company, the same diagnostic applies. The checklist below is not exhaustive. It is the minimum set of questions worth asking on a Monday morning if you suspect the seam between sales and delivery is where your deals are dying.

Diagnostic — are you bleeding at the seam?

• [ ] Can you name the last three deals that closed but did not produce a measurable business outcome for the customer? If yes, you have a seam problem.
• [ ] When a customer's CFO asks "did this move the metric we bought it for", does anyone in your organization have a confident answer within forty-eight hours? If no, you have a seam problem.
• [ ] How many people inside your company touch the average deal between the demo and go-live? If the answer is more than three, the translation losses are compounding.
• [ ] When the product team gets a feature request from the field, how long does it take to reach an engineer who can act on it? If the answer is more than a sprint, the feedback loop is broken.
• [ ] Can you point to a single product feature shipped in the last quarter that came directly from a deployment learning? If no, your field is not feeding your roadmap.

Discovery — who is in the room with the customer?

• [ ] Is the most senior person on the deal also the most senior person in the discovery conversation? If no, the discovery is being done by someone who cannot act on what they find.
• [ ] Does the person doing discovery have the authority to commit to changes in scope on the spot? If no, every meeting requires a follow-up meeting.
• [ ] Does the person doing discovery write something — an artifact, a memo, a working document — that the customer can react to before the next conversation? If no, you are running discovery calls, not discovery sessions.
• [ ] Are you sending a working artifact to the customer before the first sales call, or only after? Before is FDE-shaped. After is SaaS-shaped.

Delivery — does the seam exist, and if so, can you close it?

• [ ] Is the person who closed the deal involved in the first week of delivery? If no, the customer's reality is being re-discovered from scratch by someone new.
• [ ] Does the delivery team have direct access to the product team, or does feedback travel through a customer success layer? Direct access closes the seam. CS as an intermediary widens it.
• [ ] Are deployment outcomes — did the metric move — tracked with the same rigor as deal close rates? If no, the organization is rewarding deals signed, not deals that worked.
• [ ] Is there a written record of what was learned in the last five deployments, and is that record being read by the product team? If no, the learning is being lost.

Feedback — are field patterns shaping product?

• [ ] Can you name three patterns that have repeated across deployments in the last year? If no, you are running each engagement as a one-off and missing the compounding learning.
• [ ] Has any product feature shipped in the last six months because of a pattern surfaced by the delivery team? If no, the feedback loop is decorative, not load-bearing.
• [ ] Is there a regular ritual — weekly, biweekly, monthly — where the people closest to the customer talk to the people closest to the product? If no, the seam is reopening every week.

Structural — what is the cheapest version of the FDE function you can actually run?

• [ ] Can the most senior person in the firm spend forty percent of their time inside customer environments? If yes, you are running a one-person FDE function whether you call it that or not.
• [ ] Can you produce a working artifact — diagnostic document, prototype, working dashboard — within two weeks of the first customer conversation? If yes, you have the operating cadence of an FDE engagement.
• [ ] Are your first ten engagements run as paid R&D, with the explicit understanding that margin comes later? If yes, you are running the FDE feedback-to-product loop at small scale.
• [ ] Do you have a written methodology — even a one-page document — for how you approach customer discovery, delivery, and learning? If yes, the institutional memory will compound across engagements.

The companies that answer yes to most of these questions are running the FDE operating model in some form, whether or not they call it that. The companies that answer no are bleeding at the seam, and the most expensive part of that bleeding is invisible — the deals that never reach renewal, the patterns never discovered, the second engagement in the same vertical that takes just as long as the first because nothing was learned.

9. Closing argument

The frontier AI labs have spent the last twenty-four months catching up to a structural insight Palantir had in 2003. The next twenty-four months will determine whether the model survives contact with consulting firms, system integrators, and the inevitable pressure toward productisation. The bet at OpenAI, Anthropic, and Palantir is that it does. The bet of this essay is that the structural insight survives regardless of where the role ends up, and regardless of whether the GTM operator reading this has the budget for ten Forward Deployed Engineers or just one senior pair.

The companies that compress the distance between their engineers and their customers' reality will continue to win. The companies that do not will continue to be surprised by why their pilots do not become production. The Forward Deployed Engineer is the most expensive answer to that problem. It is not the only answer. The Signal artifact, the senior-led discovery motion, the paid-R&D engagement model, and the documented feedback loop are all smaller, cheaper versions of the same operating choice. They are within reach of any GTM team willing to make them.

Find the seam where your deals die. Close it.

Sources and further reading

[^1]: Betts Recruiting, "Top 10 GTM Roles in AI for 2026," March 2026. bettsrecruiting.com/blog/top-10-gtm-roles-in-ai-for-2026

[^2]: Romulus Strategy, "Palantir from inception to future." Founding history and CEO background. romulusstrategy.substack.com/p/palantir-from-inception-to-future

[^3]: Michael Steinberger, The Philosopher in the Valley: Alex Karp, Palantir, and the Rise of the Surveillance State (2024). On Palantir's founding, In-Q-Tel funding, and early CIA customer relationship.

[^4]: ZTABS, "What Is a Forward Deployed Engineer? Complete Guide (2026)," May 2026. Cites Karp's French-restaurant analogy as the origin framing of the role. ztabs.co/blog/what-is-a-forward-deployed-engineer

[^5]: DEV Community / Kunal D., "Forward Deployed Engineer: The Hottest Role in AI-First Tech and Why It Pays So Well [2026]," May 2026. On the spread of the role beyond Palantir to Databricks, Scale AI, Anduril, Intercom, and Rippling. dev.to/kunal_d6a8fea2309e1571ee7/forward-deployed-engineer-the-hottest-role-in-ai-first-tech-and-why-it-pays-so-well-2026-58c0

[^6]: MIT enterprise AI pilot research, 2025, as cited in Gyde, "Forward Deployed Engineers (FDEs): What AI Leaders Need to Know," May 2026. Finding: 95% of enterprise AI pilots produce zero measurable return. blog.gyde.ai/what-are-forward-deployed-engineers

[^7]: Gyde, "Forward Deployed Engineers (FDEs): What AI Leaders Need to Know," May 2026. On OpenAI formalising the FDE practice in 2024.

[^8]: Financial Times, as cited in Gyde (May 2026) and MarkTechPost (May 2026). FT reported 800% growth in FDE hiring interest between January 2025 and early 2026.

[^9]: MarkTechPost, "What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026," May 2026. On The Deployment Company, the $4B+ private equity structure, and the reported 17.5% annual return guarantee. marktechpost.com/2026/05/20/what-is-a-forward-deployed-engineer-the-ai-role-openai-anthropic-and-google-are-hiring-in-2026/

[^10]: MarkTechPost (May 2026). On OpenAI's acquisition of Tomoro, an applied AI consulting firm with approximately 150 engineers and deployment experience at Tesco, Virgin Atlantic, and Supercell.

[^11]: MarkTechPost (May 2026). On Anthropic's enterprise services firm announced May 4, 2026, with Blackstone, Hellman & Friedman, and Goldman Sachs as founding partners.

[^12]: Gyde (May 2026). On Accenture and Microsoft's forward deployed engineering practice launched in March 2026.

[^13]: ZTABS (May 2026). Defines three FDE archetypes — Builder, Solutions Engineer Rebranded, and GTM Engineer — and argues that Builder FDE is the canonical form. Also cites Databricks, Intercom, Vanta, and Reducto as examples.

[^14]: Rocketlane, "Forward Deployed Engineer (FDE): The Essential 2026 Guide," February 2026. On scope creep and the discipline required to ship fast tactical fixes without accumulating tech debt. rocketlane.com/blogs/forward-deployed-engineer

[^15]: MarkTechPost (May 2026) and ZTABS (May 2026). On the 2026 FDE technical stack: RAG pipelines, eval frameworks, agent orchestration, tool calling.

[^16]: Rocketlane (February 2026). On the failure modes of FDE programs, particularly around documentation discipline and pattern isolation.

[^17]: Betts Recruiting (March 2026). FDE base salary range $175K-$260K, OTE $230K-$360K, 30-35% variable compensation.

[^18]: MarkTechPost (May 2026). Google Cloud FDE base $127K-$183K, OpenAI mid-level FDE in SF $220K-$280K, up to 50% travel.

[^19]: Pave compensation data, as reported in "5 jobs of the future riding the AI boom," Stacker / The Mineral County Miner, March 2026. FDE prevalence grew from 0.3% of companies in January 2023 to 1.6% in January 2026.

[^20]: MarkTechPost (May 2026). On FDE interview testing of communication skills and customer empathy alongside coding ability, and on the role as a pre-contract proof-of-concept mechanism.

[^21]: Reuters and Financial Times reporting summarised in MarkTechPost (May 2026). On the labour-market dimension of OpenAI's and Anthropic's announcements.

[^22]: Michael Steinberger, The Philosopher in the Valley (2024); also Communications of the ACM, "Does Palantir See Too Much?" On the regulated-context structural conditions that shaped Palantir's FDE model. cacmb4.acm.org/news/248353-does-palantir-see-too-much

[^23]: Synthesised across Rocketlane (February 2026), Gyde (May 2026), and ZTABS (May 2026). Consistent attribution of the FDE model to Palantir as the origin.

[^24]: ZTABS (May 2026). On Salesforce's FDE-style function as part of the Agentforce push, and on the spectrum of FDE implementations across Scale AI, Databricks, and Salesforce.

[^25]: GTM HQ, internal methodology document. The PIPELINE two-mountain model treats the enterprise buyer journey as discovery (mountain one) and delivery (mountain two) with the contract as the valley between them. Contact: hello@gtmhq.com.

[^26]: GTM HQ, "The Signal Artifact: Eight-Section Buyer Intelligence Read." An HTML deliverable produced before any sales conversation, structured around eight fixed sections covering narrative, website, content, LinkedIn presence, AEO posture, founder voice, enterprise sales markers, and prioritized recommendations. See gtmhq.com.

‍

‍