Shyam Sankar’s warning is the canonical one: the FDE motion cannot be cargo-culted. The title can be adopted, the LinkedIn listings updated, the methodology described in slide decks, and none of it, absent the underlying substance, produces the outcomes the substance produces. Ted Mabrey, who runs Palantir’s global commercial business, dismisses the imitators as tribute bands, replicating the form without the function.
This matters whether you’re a candidate evaluating an offer or a buyer evaluating a vendor, because the imitation and the real thing can be priced at the same level, staffed by similar people, and described in identical proposals.
The document-versus-code test
The most useful diagnostic: does the engagement produce, as its primary artifact, a document or a deployment? A deployment means running production code in the customer’s environment, shipped against an eval set, with measurable outcomes. A document means a slide deck, an architecture diagram, a roadmap. The difference is whether anyone in the customer’s organization can run the thing six months later. The deployment can still be run, while the document has long since been filed.
The most visible instance of the pattern is the Big Four reframe. Each of the large consulting firms has launched an FDE-branded service whose marketing uses the full FDE vocabulary, and whose delivery, in many engagements, continues to look like classical consulting: a discovery phase producing a current-state assessment, a target-state design, and a roadmap handed to a separate implementation team. No production code ships and no eval set gets built. There are genuine exceptions, usually led by partners from product backgrounds fighting the firm’s default incentives, but the brand name alone does not predict substance, and the customer has to do the work of finding the right pocket.
One analyst put it acerbically: forward-deployed engineers are the invoice for making AI real. The useful version of the barb is a diagnostic. Flat FDE effort across successive deployments is the signal that an engagement has produced a dependency rather than a capability.
Five questions at the four-week mark
From inside an engagement, the cargo-cult pattern compresses into five questions. In one $620,000 engagement I watched go sideways, a portfolio-narrative system for a financial services firm, all five came back wrong at week four:
Has the customer’s sponsor approved the eval set? (It had been built entirely by the vendor; neither the sponsor nor the compliance team who’d have to sign off on client-facing output had seen it.)
Has the FDE looked at production data? (Four weeks of work against synthetic data, while the data-access request sat unescalated.)
Is the FDE’s work showing up in the vendor’s product? (No synthesis review and no patterns flowing to the platform, which made it technically indistinguishable from a one-off consulting contract.)
Has the compliance team been involved in the design? (Planned for week eight, “after the system was working,” which guaranteed a delay or a forced redesign.)
Is there a customer-facing dashboard the sponsor actually reads? (A Slack channel. The sponsor hadn’t seen a metric since kickoff, and her anxiety was rising precisely because she had nothing to show her CEO.)
Five questions, five no’s. The vendor team had the title, and the operating model was standard consulting with AI-flavored vocabulary on top. The correctives (a coauthored eval set, escalated data access, a weekly sponsor dashboard, an internal synthesis review) landed the engagement on a renegotiated timeline. Asked at week one, the same questions would have caught the pattern before it cost three weeks.
For the buyer: five questions before you sign
If you’re on the buying side, ask the vendor these before the contract: Show me the production code you’ve shipped for a previous customer. Describe an engagement that failed and what you learned. Describe an eval set you built with a customer’s domain experts. Describe a feature that moved from a customer engagement into your platform. Describe a contract you walked away from. A vendor who can’t give credible answers to four of the five is unlikely to produce the value the FDE motion is designed for.
And bring your own side of the deal: a sponsor with real exception-granting authority, a domain rebel who knows the work and is dissatisfied with how it currently runs, and a data-access path designed before the engagement starts. The FDE motion is a joint activity. The buyer who understands that gets systems that work. The buyer who doesn’t gets systems that look like they work, and quietly replaces them two years later.
Underneath all of it, the substance is what it has been since 2006: engineers sitting next to customers, shipping code against eval sets, with outcomes you can measure. The titles and the tools will keep changing. The motion won’t.
Want the full playbook, with the templates, the interview transcripts, and the week-one checklist? It’s all in my book Forward Deployed AI Engineering: A Working Guide to the Hottest Job in Software, available on Amazon: [Amazon link]