Building the Delta: FDE is Not Professional Services
How outcome-obsessed engineering teams will drive enterprise AI Agent adoption
I’ve been on Forward Deployed Engineering teams for over five years between Palantir and Sierra. The question I hear most often is: “Isn’t FDE just professional services?”
The answer is no.
Professional services deliver scope. Forward deployed engineering teams operate as a high-leverage extension of the customer’s team to deliver outcomes.
FDE teams deliver what internal teams often cannot. They aren’t constrained by competing priorities, bureaucracy, or legacy processes. They are highly talented, native to the latest technologies, and bring an unencumbered angle to any problem. They focus exclusively on the customer outcome, and in the process, define the next version of the product.
That distinction is critical for enterprise AI adoption. FDE job listings jumped 800%+ in 2025, with OpenAI, Anthropic, and Harvey aggressively hiring FDEs (even Salesforce has said they are planning to hire 1,000). This is because enterprise AI cannot be “implemented” or “onboarded” like typical SaaS software. It requires engineering that operates at the edge of the platform and embedded in the messy reality of the customer’s business until value is real in production.
Learning from the Factory Floor
The Forward Deployed Engineer role was popularized by Palantir in the early 2010s with a simple mandate: go to where the work happens. The role wasn’t to advise from an office, it was to embed with operators, understand their workflows, and leverage the platform to drive business outcomes.
When I first joined Palantir, I spent months at manufacturing facilities in Toledo, Ohio. I sat with operators who had 20+ years of domain expertise and codified their learnings so the platform could drive better decisions at scale.
Whether it was the early days of Palantir or the current frontier of enterprise AI, Forward Deployed Engineering is the discipline of building the “delta” between a flexible platform and a specific business outcome with a relentless sense of urgency.
A Field Example: The Multi-Million Dollar Inventory Problem
Consider a multi-site manufacturer across North America with a multi-million-dollar excess inventory problem.
Situation
Each site made inventory decisions in isolation. The coordination layer was human-driven using emails, calls, and spreadsheets. Decisions were driven by an expert at each site who operated as the source of truth, answering questions like:
“Do we have this part somewhere else?”
“Is that part actually usable as an alternative?”
“If we move it, what breaks downstream?”
Because negotiating across sites was slow and painful, the default decision was predictable: order new inventory. It was fast, defensible, and it didn’t require negotiating across sites.
Task
Instead of starting with requirements gathering, we started by shadowing to build context. We observed their workflows end-to-end and captured the real decision points:
What exactly triggers a new purchase?
Under what conditions is a transfer viable?
What makes an alternate acceptable (and who has veto power)?
What does the operator need to see to trust the number enough to act?
Action
We built an outcome-driven solution by codifying the expert’s intuition:
Unify Inventory (MVP): a central system to create cross-site inventory visibility and a trusted source of truth.
Codify Tribal Knowledge: flexible rules for substitute parts based on the intuition of experts with 20+ years of experience.
Integrate at the Decision Point: integration into the purchasing flow so alternatives showed up at the moment of decision, before a new order was placed.
Capture the Approval Flow: Log requirements, approvals, and rejections. By capturing these decisions, we could see the higher-level patterns to automate the next phase of the workflow.
Outcome
We achieved a 50%+ reduction in excess inventory. Not because we “implemented software” but because we changed the default decision from “order new” to “reuse.” And by capturing the decision logic in real-time, we built a foundation for the customer’s business to operate at a new level of efficiency.
The Evolution: From FDE to Agent Development
At Sierra, the FDE philosophy has evolved into Agent Development. The challenge in enterprise AI today is the “Expertise Gap.” It has never been easier to build a prototype, but it is still incredibly difficult to drive a tangible business outcome.
Without a clear path to value, many enterprise AI initiatives move at typical product roadmap speeds, measured in quarters rather than weeks, and often fall short of C-suite expectations.
Forward deployed engineering teams exist to partner with customers and close that urgency gap by:
Embedding: Discover the workflow constraints and where AI can best be leveraged.
Hardening the Core: Build agent logic + guardrails so it can operate with the nuance of your best operator.
Iterating in Production: Ship with the urgency of an operational team, not a roadmap review committee.
The Takeaway
Forward deployed engineering is about operating as a high-leverage extension of the customer’s team. Not by “doing services faster” but by compressing time-to-outcome and by scaling customer expertise in ways internal roadmaps struggle to reach.
Professional services that just optimize for “go-live” will struggle to see Enterprise AI adoption. FDE teams that deeply partner with their customers (shipping, hardening, and iterating until the outcomes are real) will win the opportunity to partner with the greatest businesses in the world.
What’s your “Toledo”, the place you had to go to understand the real workflow? I’d love to hear your learnings when building FDE teams.
Great read, thanks.
amazing take on what fde actually is