If you’ve been anywhere near a tech hiring page in 2026, you’ve seen the title: Forward-Deployed Engineer (FDE). OpenAI has them. Anthropic has them. So does Palantir, Ramp, and Salesforce. In late June, AWS announced a $1 billion investment to build an entire organization around the role. Days later, Microsoft went further, launching a $2.5 billion “Frontier Company” business built on roughly 6,000 embedded experts. Andreessen Horowitz has called it the hottest job in startups.
So what is this role, why is everyone hiring for it right now, and what does it actually take to put AI to work inside a real organization?
What is a Forward-Deployed Engineer?
The term was coined by Palantir, borrowing from the military sense of “forward-deployed” — stationed in the field, close to the action. An FDE is a software engineer embedded directly inside a customer’s organization to design, build, and ship custom software — usually AI systems — inside that customer’s real environment, not a sandboxed demo.
Palantir’s own framing is a useful way to think about it: a typical engineer builds one capability for many customers; an FDE builds many capabilities for one customer. It’s part software engineer, part solutions architect, part consultant, and part startup CTO — someone who writes production code, wires up messy real-world data, configures workflows, and stays hands-on through the whole lifecycle rather than handing off a spec and walking away.
Why Organizations Are Looking for FDEs
The short version: AI is easy to demo and hard to deploy. A polished model in a lab looks nothing like a working system inside a bank, hospital, or factory — each with its own data silos, security rules, legacy systems, and business logic. That gap is enormous: research cited by tech outlets found that roughly 95% of enterprise AI pilots never make it to production, largely because company data is fragmented and hard to integrate.
That gap is exactly where the FDE lives. A few forces are driving the demand:
- Vendors are trading margin for moat. Companies like OpenAI and AWS are willing to eat the cost of hands-on implementation because it’s what makes their platform indispensable — the same playbook Salesforce and ServiceNow ran during the shift to cloud computing.
- Hiring data backs it up. More than half of U.S. tech job postings now call for AI or ML skills, up sharply from about a year earlier, and the large majority of organizations plan to increase AI investment. One talent-industry executive summed up the shift bluntly: companies need “FDEs, not FTEs.”
- The work is genuinely different from a generic engineering role. Enterprises don’t just need a model API — they need someone who can fine-tune it, build retrieval systems around it, write evaluations that prove it’s accurate enough to trust, and keep adjusting it as real usage reveals edge cases.
Not everyone agrees the FDE boom will last at the same scale, though. AI researcher Andrew Ng has pointed out that while FDEs are having a real resurgence, he expects far more AI Engineer jobs than FDE jobs going forward. His reasoning: a company might accept a handful of embedded FDEs from a vendor, but it wants far more of its own people building on its own systems — and FDEs, almost by design, are there to bind a company tightly to one vendor’s product. In a moment when it’s hard to know which AI provider will lead a year from now, that loss of flexibility is a real cost, not just a convenience. He expects the generalist “AI Engineer” role to eventually fragment into more specialized jobs — possibly including AI FDEs, evals engineers, and LLMOps engineers — the same way “software engineer” split into frontend, backend, and DevOps over the past two decades.
How to Approach an AI Implementation for Automation
If you’re an organization considering AI-driven automation — whether via a vendor’s FDE team or your own internal build — the lessons from how FDEs actually work translate into a practical checklist:
- Get your data house in order first. Most failed pilots don’t fail because the model is bad — they fail because the data feeding it is siloed, inconsistent, or ungoverned. Fix that before scaling anything.
- Build evals before you build trust. An “eval” — a quality check that measures whether the system is accurate enough for the task — should exist before the system goes anywhere near production, not after something goes wrong.
- Start narrow, in the real environment. Don’t perfect a system in a clean sandbox and hope it transfers. Build and test inside the messy, actual workflow it’s meant to automate, with the people who’ll use it daily.
- Protect your optionality. If you bring in outside FDEs, be deliberate about how deeply their solution binds you to one vendor’s tooling. Model quality and pricing shift quickly; a system that’s portable across providers ages better than one that isn’t.
- Treat feedback as part of the build, not an afterthought. The improvements an FDE makes for one team should feed back into the platform — and internally, the fixes your automation surfaces in week one should inform week two, continuously.
- Staff for both halves of the job. Technical depth (fine-tuning, RAG, infrastructure, security) matters, but so does the human side — someone who can sit with the people whose workflow is being automated, translate their real needs into a spec, and push back when a request isn’t realistic.
The Bottom Line
Whatever happens to the title — and it may well evolve or fragment the way “prompt engineer” already has — the underlying skill set is durable: connecting AI systems to real business outcomes, working inside messy environments instead of clean demos, and closing the gap between what a model can do in principle and what it reliably does in production. That gap, not the model itself, has always been the hard part of AI.