How forward deployment actually works: Palantir, read closely

Palantir spent two decades being called a consulting company with a stock ticker. In 2025 it booked $4.475 billion in revenue at gross margins above 80% — software margins, not services margins. Accenture, the thing Palantir was supposedly becoming, runs gross margins around 32%. The gap between those two numbers is the entire lesson of the forward deployed model, and most companies copying it are copying the wrong half.

The split

The mechanics, as described by Nabeel Qureshi in Reflections on Palantir, the best first-person account in print: Palantir divided engineering into forward deployed engineers, who lived at customer sites three to four days a week, and product development engineers, who almost never met a customer. The division of labor was explicit. In Qureshi’s words: “Your job was to solve the problem, and not worry about overfitting; PD’s job was to take whatever you’d built and generalize it.”

FDEs were licensed to overfit — to build the hacky, customer-specific thing that solved this client’s problem this quarter. On the Airbus A350 program, that meant software targeting the CEO’s specific production bottleneck, which Qureshi credits with a 4x acceleration in manufacturing pace. The technical debt piled up on purpose: it was raw material for the other half of the company.

The loop, not the staffing model

Stage What happens Who does it What Palantir kept
Embed Engineers sit inside the customer’s operation, absorb context no requirements doc captures FDE The real problem
Solve Ship something overfit, in weeks FDE The deal, plus reference proof
Generalize Field hacks get rebuilt as platform primitives PD Product: Magritte (ingestion), Contour (analysis), Workshop (app builder) all began as field work
Resell The next deployment starts from the platform, not from zero Next FDE Margin

Each pass through the loop makes the next deployment cheaper. That is what turned a services cost structure into 80% gross margins: the field work was upstream R&D wearing a services badge.

The economics were formalized in Palantir’s own S-1 as a three-phase customer lifecycle — Acquire, Expand, Scale. In the Acquire phase, Palantir ran short pilots largely at its own expense, at negative contribution margin; in the Scale phase, contribution margins reached about 55%. Read that as an accounting decision as much as a sales motion: field engineering was booked, in spirit, as customer acquisition cost — a bet that the account pays it back at scale-phase margins. The bet only works if field cost per account actually declines. Which is what the generalization loop is for.

What breaks when you copy it

The model is now the most-imitated org pattern in AI, so it’s worth hearing the skeptical case from inside the industry. a16z’s Marc Andrusko argues Palantir is “a category of one” — mission-critical problems that justify bespoke work, unusual talent density, a real product spine — and that startups copying the embedded-engineer half without the generalization half end up with “thousands of bespoke deployments that are impossible to maintain or upgrade.” His diagnostic question for any team running the motion: does forward deployed effort on a mature account go down over time? If not, you’re not Palantir. You’re Accenture for X, at Accenture margins, without Accenture’s scale.

So steal the loop, skip the costume. But notice what the loop actually ran on. Palantir solved context transfer with co-location and shared payroll: FDE and PD sat in one company, one codebase, one cap table, so what the field learned could find its way into the platform through hallways and code review. A 50-person vendor’s version of that transfer is Slack scrollback, five forks of a Google Doc, and one senior engineer’s memory. The stages of the loop survive the copy; the connective tissue doesn’t.

That connective tissue is what Gravel is: agents that write down the tickets, decisions, and reusable patterns of every engagement as the work happens, so the requests that recurred across four clients actually surface as product signal instead of dissolving into scrollback. The same system that lets one person supervise several engagements is the one keeping the loop’s raw material — which is the half of Palantir’s model that was ever worth stealing.

Sources

  1. Nabeel Qureshi, "Reflections on Palantir"
  2. Palantir S-1 (SEC)
  3. Revenue Memo on Palantir's model and FY2025 results
  4. a16z, "The Palantirization of everything"

Filed under · Palantir · Forward deployed engineering · Product strategy

The lever in this note is the one we built.

Gravel puts a crew of agents on the coordination half of the forward deployed motion, so one person supervises engagements instead of carrying them.