The Forward Deployed Engineer's Problem: The Client's Data Cannot Leave

2026-08-22 · 8 min read

Palantir invented the Forward Deployed Engineer in 2005 for one reason: its first customers could not disclose the details of their work, so product discovery had to happen inside the customer's walls. Twenty years later that constraint came back with LLMs, and in May 2026 OpenAI and Anthropic both stood up billion-dollar companies whose entire job is embedding FDEs inside customers.

If you are an FDE (human, or an agent running the engagement with a human gate) you already know the blocker the 2026 literature cites most: most enterprises cannot put proprietary data into multi-tenant SaaS. And the failure that follows is just as predictable: retrieval and classification quality degrade because the model was never tuned against this client's corpus.

What an FDE actually needs per client

1. A model tuned on this client's data, not a shared generic one. Upload the corpus, pick an open-weight base (GLM 5.2, DeepSeek V4, Qwen 3.5, Kimi K2.6), fine-tune it as exactly that model, and get an OpenAI-compatible endpoint the client's stack already knows how to call.
2. Data isolation by construction. Hosted single-tenant for clients who accept it; an in-house implementation inside the client's walls for the ones whose data cannot leave at all. Same stack either way.
3. Ownership the client can defend. Weights exportable on request. Data deletable after training, on request, irreversibly. The client owns data, weights, and inference, which is what turns a security review from weeks into days.
4. Speed measured in days. Upload to trained to serving is minutes-to-hours on our platform. The published FDE benchmarks in 2026 are 48 hours to production agents and 3-7 day vertical deployments; a per-client fine-tuned endpoint should never be the long pole.
5. Several unrelated clients at once. Engagement boundaries enforced by scoped partner access codes and access logs, not by discipline and naming conventions.
6. Governed autonomy. Agents that stop for a human on anything determinative, with approval gates and audit trails you can hand to the client's security team.

The security review is the critical path

The FDE handbooks agree: the customer's security team holds a veto, and "least privilege is a speed tactic." Arrive pre-scoped, named subprocessors, encrypted per-model credentials, immutable access logs, delete-after-training, and the review shrinks. That is why we built the control surface before we named the customer: scoped connection grants, block vocabularies, SSRF guards, human approval gates, erasure workers.

Ship the model, keep the receipts

An FDE does not want a vendor who says everything is green. They want one who can show what broke and what caught it. Every capability we ship goes live only after a production run where it was observed failing when broken, checks with teeth, kept better or rolled back, all of it public in our deploy report.

That is the delivery substrate: stand up a private, client-specific model in a day, on infrastructure the client controls, with the audit trail already written.

Start an engagement, hosted, or in-house for the clients whose data cannot leave.