What Founders Should Steal From the Forward-Deployed Engineer Model (and What to Leave)

Nabeel Qureshi joined Palantir in the summer of 2015. He later moved to Toulouse and spent a year working four days a week inside the factory where Airbus builds the A350. His team's software tracked work orders, missing parts and non-conformities across the production line. He calls it "Asana, but for building planes," and writes that it "ended up helping to drive the A350 manufacturing surge and successfully 4x'ing the pace of manufacturing while keeping Airbus's high standards of quality."

The same essay holds the opposite memory. On other accounts, "you'd have a company buying an 8-12 week pilot, and we'd spend all 8-12 weeks just getting data access, and the final week scrambling to have something to demo."

Same firm, same software, same hiring bar. What varied was where the engineer sat and how much license he had to push back.

A decade later, the biggest names in AI have picked a side. In May 2026 OpenAI launched a Deployment Company with $4 billion from a nineteen-firm syndicate led by TPG. "Our customers tell us they need help going from pilot to production," said COO Brad Lightcap. "Deployment Company will put our engineers inside their teams, with the resources to ship." At the end of June, AWS announced a $1 billion Forward Deployed Engineering organization: pods of five or six engineers, forty-five-day engagement cycles. Two days later Microsoft unveiled Frontier Company, a $2.5 billion unit of some six thousand engineers and industry experts embedded inside customers. And in mid-July Anthropic, Blackstone and Hellman & Friedman, with Goldman Sachs among the investors, capitalized Ode with $1.5 billion to do the same work against live enterprise data.

Every serious seller of AI has converged on the same delivery model: a senior engineer inside the customer's business, judged on production outcomes rather than demos.

Here is the part that concerns you, the founder of a company doing $3 million to $15 million a year. None of this is being built for you. OpenAI charges at least $10 million per client for this kind of work, per The Information. The smallest deal size Palantir even discloses is $1 million, and its average customer is worth about $4.7 million a year to them ($4.475 billion in revenue across 954 customers, per the FY2025 10-K; the division is ours).

You cannot buy the real thing. You can understand why it wins, and buy the five mechanics that survive translation to your scale. That is what this essay is for. (Disclosure, early and plainly: Mercury, the firm publishing this, sells senior advisory and engineering of the kind the last third argues for. Read accordingly.)

The numbers everyone quotes, corrected

You have probably seen the claim that 95% of AI pilots fail. It is a misquote, and since this essay will lean on the underlying study, the correction matters.

The source is MIT's NANDA initiative, whose July 2025 report drew on 52 organization interviews, 153 leader surveys and 300+ public initiatives. What it found: despite $30 to 40 billion of enterprise investment in generative AI, 95% of organizations were getting zero return, meaning no measurable P&L impact roughly six months after their pilots. The pilot-level numbers are separate, and worse in a more specific way: of custom, task-specific enterprise tools, about 5% reached production. Generic LLM tools reached production around 40% of the time. The report is preliminary, self-described as "directionally accurate," and drew fire for its methodology (Futuriom: "The 95% figure is presented in one sentence, but the authors offer no detail on where they came up with that number"). Treat it as one loud data point, corroborated by quieter ones.

The quieter numbers point the same way. S&P Global's 451 Research surveyed 1,006 IT and business professionals and found the share of companies abandoning the majority of their AI initiatives jumped from 17% to 42% in a year; on average, 46% of projects were scrapped between proof of concept and broad adoption. Gartner forecasts that over 40% of agentic AI projects will be canceled by the end of 2027; a forecast, and a directional one.

The headlines skip why. RAND interviewed 65 practitioners and found 84% of them citing leadership-driven root causes, misunderstanding or miscommunicating what problem needed solving, as the primary reason AI projects fail. Data quality came second. BCG's survey of 1,000 executives attributes 70% of implementation difficulty to people and process, 20% to technology, and 10% to the algorithms themselves. McKinsey's State of AI survey tested 25 practices for their effect on EBIT impact from generative AI; redesigning workflows had the biggest effect, and only 21% of the companies using generative AI had done it at all.

Read those side by side and the models stop looking like the problem. Projects die in data access and workflow fit, with nobody owning the outcome. The failure is in how AI gets delivered into a business. Which is precisely the problem the Forward-Deployed Engineer model was invented to solve, nineteen years before the current wave of announcements.

The waiter and the kitchen

In 2006, Alex Karp asked Shyam Sankar, Palantir employee number thirteen, why French restaurants are so good. His answer: the waitstaff work as part of the kitchen. They know the food, they course-correct the diner, they carry information both ways. Karp asked him to build that, for engineering. Sankar did, and in 2007 named it "forward deployed engineering," in his words "in homage to our customers." His summary of the idea has aged well: "we didn't believe in throwing our software over the wall in the hopes the customer would divine the correct meaning from it."

Palantir's internal structure makes the idea concrete. The company splits engineering in two: Devs build the product ("one capability, many customers"), Deltas, the forward-deployed engineers, live inside a single customer ("one customer, many capabilities"). Until around 2016, Palantir employed more FDEs than product engineers. The company's own S-1 put it in one sentence: "Our forward deployed engineers ('FDEs') have travelled to bases in Afghanistan and factories in the industrial Midwest to deploy our platforms."

Wall Street hated it. On May 19, 2016, Bill Gurley polled a room of investors on what they would pay for Palantir; zero hands went up above $1.5 billion, and the verdict in the room was "unprofitable consulting biz." The services-heavy model looked unscalable, low-margin, everything software investors are trained to run from.

The verdict did not survive contact with the numbers. In 2023 Palantir posted a GAAP gross margin of 80.6%: $2,225.0M of revenue against $431.1M cost of revenue, per SEC filings (revenue, cost). Qureshi's comparison: "These are software margins. Compare to Accenture: 32%." The overfit, customer-specific work the Deltas did was continuously distilled by the Devs into products, and one of them, Foundry, now drives more than half of Palantir's revenue. In 2024 Palantir was the best-performing stock in the S&P 500, up 340.5%. Fiscal 2025 closed at $4.475 billion in revenue, up 56%, with US commercial revenue growing 137% in the final quarter. The consulting-shaped company turned out to be a product company with a better intake mechanism.

One more detail from inside the model, courtesy of Ted Mabrey, a Palantir commercial leader, because it will matter later: the waitstaff in that French restaurant are not order-takers. "If you want to order the wrong wine with the fish, the wait staff will simply tell you no."

The skeptics are mostly right

Before you take any of this to your own company, sit with the objections, because they are strong and mostly correct.

The cheap version first. When OpenAI's FDE hiring hit Hacker News, the recurring framing was dangus's: "Forward Deployed Engineer is just a title change for Solutions Architects." Another commenter, Avicebron: unless the FDE has real pull with the core product team, they are "nothing more than a glorified field engineer/technical consultant." Thomas Otter reduced it to an invoice test: "If you invoice this work to the customer it is consulting, if you don't it is customer success, support or presales."

The serious version comes from inside Palantir. Mabrey wrote an essay in September 2024 titled, without ambiguity, "Sorry, that isn't an FDE." The companies now hiring "forward deployed engineers," he argues, are "replicating the form but not the function of the FDE." He calls them tribute bands. Ex-Palantir FDEs who joined them describe the experience "as feeling like they are in jail." The function, in his telling, rests on things a job title cannot carry: FDEs trained to act "as if you are the CEO, but with zero authority," an organization that wants its engineers yearning for scope creep because the customer's mission demands it, and economics that can absorb the cost. He is direct about those economics: over $1.1 billion a year from Palantir's top twenty clients, core products that took "10-20 different custom implementations before they could be synthesized," and "enormous key-man risk" the whole way. His essay ends by refusing the premise of essays like this one: the lesson is "to not copy the FDE but to provoke you to ask what assumptions are you making about the fabric of your company, and if you should be copying anything at all."

Hold on to all of that, because it is true, and one more thing is also true: most of what is currently sold to mid-market companies under the FDE label is exactly what Mabrey says it is. A body shop with a new business card.

But the refusal misses something at your scale. Mabrey's alignment problem, how you keep an embedded engineer loyal to the customer's mission when nobody has formal authority over anyone, is a big-company problem. Palantir solves it with training, culture and $10-million-plus multi-year contracts that make the customer's mission commercially existential. At a 40-person company most of that machinery has nothing to do, because the alignment exists in the room. The actual CEO, you, sits across the table. The data gatekeeper who can stall an enterprise pilot for twelve weeks is, at your company, one ops manager whose cooperation you can arrange by Thursday. The NANDA numbers back this up: mid-market top performers moved from pilot to full implementation in about 90 days, against nine-plus months for enterprises.

The honest question left over is what disciplines the vendor, since a boutique's engineer still works for a firm that likes billable work. The answer has to be structural there too, only cheaper: a fixed fee instead of a running meter, a kill option after diagnosis, ownership passing to you at the end. The checklist at the bottom of this essay is that structure spelled out.

What does not transfer, and should not be imitated: armies of embedded twenty-somethings, scope creep as a growth strategy, months of free pilots (Palantir's own S-1 concedes the model "often requires us to spend months … on pilot deployments at no or low cost"), five-year land-and-expand arcs, and the product-leverage economics that turn overfit gruntwork into 80% margins. Those parts belong to Palantir and to the four billion-dollar deployment ventures. Leave them.

The menu, priced

Strip the vocabulary away and a founder wanting serious AI help in 2026 has six options. Prices below are sourced or derived; where a number comes from a vendor talking their own book, it says so.

One studio working this space, Utsubo, pitching its own model but doing honest arithmetic: "A $350K–$550K total compensation engineer on 25–50% travel cannot break even on a $40K–$80K SMB engagement at SMB price points." That arithmetic is the story of the table. Between the $50K agency project feeding a funnel where one custom tool in twenty reaches production, and the $1 million Palantir floor, there is almost nothing credible to buy. That gap is cost structure: an engineer paid like the labs pay cannot break even on engagements priced like yours.

$10K$100K$1M$10M

ALMOST NOTHING TO BUY

AGENCY PROJECT$10–50K

BOUTIQUE DIAGNOSTIC (ENTRY)$15–25K

FRACTIONAL CAIO · ADVICE ONLY$60–180K/yr

HEAD OF AI · YEAR-ONE HIRE~$600K

PALANTIR$1M floor · ≈$2.6M avg

OPENAI$10M+

Ranges from the table above; log scale. Muted rows are not vendor-built systems: one is advice, the other is an employment bet. The shaded band is the point.

A boutique escapes that arithmetic the only ways it can be escaped: no half-time travel load, no bench idling between engagements, no pyramid of juniors to keep billable, and principals who own the firm rather than draw lab-scale salaries. The diagnostic gate covers the rest by capping downside on both sides. Whether a particular vendor has actually escaped the arithmetic, rather than quietly cutting the seniority that made the model work in the first place, is checkable. The walk-away list below exists for that.

When each option is the right call

Every row on that menu is right for someone, and pretending otherwise would make this an ad.

Hire the Head of AI when AI is becoming your product, when the role owns a roadmap measured in years, and when you can absorb a $600K first-year bet on one person: $353K average pay, times roughly 1.42 for employer costs (the Bureau of Labor Statistics puts benefits at 29.7% of private-industry compensation cost, $13.49 of every $45.38 an hour, which loads a salary by about 1.42x), plus the search fee, with a repeat possible if the hire misses. The big consultancy earns its fee when you are enterprise-scale and the deliverable is partly political: board cover, a signature the market recognizes. Use an agency when the problem is fully specified, commodity-shaped, and you accept pilot risk with open eyes; at $24–$49 an hour someone has to be junior, and for a well-bounded integration that can be fine. A fractional CAIO makes sense only if you already employ engineers and lack nothing but direction. If you clear the $1 million floor, call Palantir or one of the deployment ventures; nothing at boutique scale replicates a thousand-engineer bench. And skip the FDE-style boutique when your problem is commodity-shaped (the agency is cheaper and adequate), when you need permanent capacity rather than a build, or when what you lack is direction alone.

The through-line, whatever you choose, comes from the NANDA data: the buyers who succeeded "act like BPO clients, not SaaS customers. They demand deep customization, drive adoption from the front lines, and hold vendors accountable to business metrics." In the same data, externally partnered tools reached deployment about twice as often as internal builds, roughly 67% against 33%, with the report's own caveat that correlation is not causation. Buy outcomes, and stay in the room while the vendor builds them.

The five mechanics worth stealing

The FDE model wins on mechanics that have nothing to do with scale. Five of them translate to a founder-led company intact.

1. Embed before specifying. Qureshi credits the model's foundational insight to a Tyler Cowen line: "context is that which is scarce." Software built from a requirements document inherits what he calls the flattened "list of requirements" view of the business, stripped of the tacit knowledge that decides whether a tool survives contact with a Tuesday afternoon. Palantir's answer was four days a week onsite. Yours is simpler: whoever builds your system spends the first week watching the work happen. At a 40-person distributor, week one is finding the ops manager whose spreadsheet secretly runs the company.

We have lived a version of this, at a launch-based education business whose sales tracker was a spreadsheet 91 columns wide, rebuilt by hand every month. Our embedding is not Palantir's, and nobody flies anywhere; that is a large part of why the economics work below the enterprise. It is recorded Zoom sessions in which the person who runs a process walks us through it, click by click, with Loom recordings for the asynchronous parts. The artifact that mattered was a notes column where the CFO had been working out payment plans by hand, deal by deal: base amount, scholarship discount, ten percent interest, four monthly payments of $280.08. We asked why at every step, and the most common answer from smart, senior people was some form of "I don't know, we've always done it this way." Several records turned out to be duplicated across spreadsheets and maintained for no reason anyone could name. A requirements workshop does not produce those answers. Watching where people click does.

2. Data access is the project, plan for it first. Sarah Constantin, writing about the enterprise data integration business generally, observes that "it's not at all unusual for it to be easier to make a multi-million dollar sale than to get the data access necessary to actually deliver the finished software tool." Recall Qureshi's twelve-week pilots, spent whole on access negotiation. At your scale the politics are smaller and still real: the bookkeeper protective of the accounting file, the sales lead whose CRM hygiene is about to become visible. Any vendor whose plan does not begin with named systems, named owners and named access dates is planning a demo.

3. Working software in weeks, because speed is the trust mechanism. Enterprise software expectations were set by waterfall implementations that ran years. Qureshi: "when a ragtag team of 20-something kids showed up to the customer site and built real software that people could use within a week or two, people noticed." Speed is how you find out: a system in real use within weeks generates the evidence that decides whether to continue. The NANDA finding that mid-market winners go pilot to implementation in about 90 days is the same fact measured from the outside. Our own proof point, for what one constrained example is worth: the education business from the scene above went from diagnostic to production in three weeks, and the system put $7.85M through one custom sales command centre in nine months.

4. Overfit first, generalize never (that part is their problem). Palantir ran a deliberate split: the Delta overfits a solution to one customer, the Dev turns it into a product for a thousand. You need the first half only. The system that fits your close-to-quarter workflow, your naming conventions, your exception cases, will beat the configurable platform that fits everyone's approximately. Generalization is a software vendor's economic need. Do not pay for it, and be suspicious of anyone whose deliverable smells like their next product.

5. A deliverer with standing to refuse. Mabrey's waiter again: the wrong wine gets a no. The down-market equivalent of an FDE trained to act "as if you are the CEO, but with zero authority" is a vendor structurally able to tell you no in writing: this workflow should not be automated, this tool you asked for will not return its cost, this project should not proceed past diagnosis. A vendor who can only say yes is a menu, and you will order wrong, because the failure studies above are substantially a catalog of customers who ordered wrong and got exactly what they asked for.

Telling the real thing from a tribute band

Job postings for forward-deployed engineers grew 1,165% year over year through October 2025, per Bloomberry's analysis of a thousand listings. Titles inflate at that growth rate. First Round published a hiring guide for FDEs that quietly assumes the employer serves Fortune 500 customers; nobody has written the buyer's side. So, inverted from everything above, for the founder evaluating anyone selling embedded AI engineering:

Walk away when you see:

• Compensation by output volume. One New York AI-transformation firm's FDE posting (TenEx Labs, the firm co-founded by Morning Brew's Alex Lieberman, June 2026) offers a $180,000 base with quarterly quotas of 562.5 story points and $80 per point above quota, uncapped. Whatever that motivates, it is not the patience to spend week one finding the spreadsheet.
• Hourly billing with no fixed deliverable. Otter's invoice test cuts both ways: if the meter runs by the hour, delay is revenue.
• The senior who sold is not the person who builds. The pyramid model exported downmarket. At your deal size there is no economic reason to accept it.
• No written position on what should NOT be automated. A vendor who has never refused work has never diagnosed anything.
• "AI strategy" with no data-access plan. A plan that does not begin with named systems, named owners and named access dates is a plan for a demo.
• Title inflation as a tell. Anthropic runs its embedded-engineering function under the title "Applied AI"; its careers board listed 22 such roles and zero "Forward Deployed" titles as of July 31, 2026. The label is marketing; the substance is the working pattern.

Lean in when you see:

• A paid diagnostic with a kill option before any build. Fixed fee, fixed weeks, and an explicit possibility that the answer is "do not build." The ability to refuse, made contractual.
• Success defined as the system running without them. The same TenEx posting contains the best one-line definition of done in the industry: what counts is "the workflow running on Monday morning when nobody from [the vendor] is in the room." Adopt that sentence into your contracts.
• You own what gets built. Code, data model, documentation, on your infrastructure, at full payment. Anything else is rent.
• A capacity claim you can verify. Any vendor selling embedded senior attention should be able to tell you, checkably, how many engagements they run at once and what they are working on now. Infinite availability means nothing is embedded.

What to leave

Mabrey ends his essay by telling you not to copy the FDE at all, and on the letter of it he is right. You should not build an FDE program, and you cannot hire the people who staff them: US FDE headcount is around 17,000 by one executive-search estimate reported by TechCrunch, the labs and hyperscalers are bidding for all of them, and the posted bands run to $385,000 base before a single line of your code exists.

What you can do is translate the model into five buying decisions: diagnosis before build. A data-access plan before a roadmap. The same senior diagnosing and building. Production evidence over demos, in weeks. And a vendor with the standing to refuse the wrong wine.

Two scenes in Toulouse, remember. One produced "Asana, but for building planes" and helped four-x a production line. The other produced twelve weeks of access negotiations and a demo assembled in the final week. The models have improved beyond recognition since either scene took place. The thing that decided between them has not changed at all: whether someone senior was inside the building, with the time to learn it and the authority to say no.

---

Mercury Consulting sells the fixed-fee operational diagnostic this essay argues for ($15,000–$25,000, four to eight weeks), and deliberately limits concurrent engagements so the senior team that diagnoses is the team that builds. Weigh the argument with that in mind.