“`html
What is a Forward Deployed Engineer?
The term “Forward Deployed Engineer” (FDE) sounds military. That is intentional.
A Forward Deployed Engineer is a software engineer who works embedded with the customer’s technical and operational environment on-site, hybrid, remote, or inside a customer cloud or VPC, depending on the engagement. The FDE does not sit at a home office writing documentation. Instead, the FDE works alongside the client’s domain experts, inside their workflows, and writes real code that runs in the client’s production systems.
The role differs from traditional advisory consulting because FDEs own implementation and production delivery. Consultants write reports and recommendations; an FDE builds the actual system and stays until it runs in production. The role was coined by Palantir in the early 2010s, emerging from a problem Palantir could not solve any other way.
The Origin: Palantir’s Intelligence Agency Problem
Palantir was founded in 2003 to help U.S. intelligence agencies make sense of large, fragmented datasets. The problem was not purely technical.
Intelligence agencies could not clearly describe what they needed. They could not openly share their data. Their workflows changed constantly. A traditional software product could not keep up. Palantir’s engineers had to go inside the agencies and work out the problem on-site. These early on-site engineers were called “Deltas.”
Until 2016, Palantir had more FDEs than software engineers. That ratio is unusual by software company standards, indicating how central the embedded model was to the business from the start.
The FDE role was inspired by how high-end French restaurants operate. The front-of-house staff is deeply integrated with the kitchen. They are empowered to tell customers “no” if the customer is ordering incorrectly. Palantir applied that same philosophy to enterprise software delivery.
Why Standard SaaS Does Not Work for Complex AI Deployments
To understand why the FDE model is trending now, you need to understand where the standard SaaS model breaks down.
The standard enterprise software motion looks like this:
- A company builds a product.
- The sales team pitches it to clients.
- A customer success manager helps with onboarding.
- The client’s internal team integrates it.
This works for well-understood products like a CRM, a project management tool or an analytics dashboard. These have documented APIs, predictable behavior, and large communities who share implementation patterns.
AI systems break this model. There is a knowledge gap on both sides.
The client’s engineers know their business deeply: the data schemas, the compliance requirements, the edge cases, the legacy system architecture. The AI lab’s engineers know how models behave in production: the prompting patterns, the retrieval-augmented generation (RAG) strategies, the evaluation frameworks, and the failure modes that appear only at scale.
Neither side has the other’s knowledge. And anthropic-openai”>you need both to ship something that runs in production.
A customer success manager cannot bridge this gap. Documentation cannot bridge it. An FDE can.
MIT NANDA’s State of AI in Business 2025 report found that 95% of enterprise generative AI pilots show no measurable business impact. The models are not the problem. The deployment is.
Palantir’s Operational Evidence
Before analyzing what OpenAI and Anthropic are doing, it is worth examining Palantir’s results. They provide the most direct proof of concept.
Palantir went public via a direct listing on September 30, 2020, with a reference price of $7.25 per share. The stock opened at $10 and closed its first day at $9.50. It rose to highs near $39 in early 2021, then dropped to around $6 in late 2022. Critics questioned the model throughout this period. The FDE approach looked too expensive and did not scale like a pure SaaS product.
The stronger evidence is operational. Palantir’s Q1 2026 investor release confirmed 85% total year-over-year revenue growth, U.S. government revenue up 84% year-over-year, and U.S. commercial revenue up 133% year-over-year. Palantir raised its full-year 2026 revenue guidance to 71% year-over-year growth. Those numbers reflect what the embedded deployment model produces at scale, in a competitive market, after years of iteration.
The FDE model produced a specific kind of revenue: sticky revenue. When an FDE team spends months inside a client organization building a system that integrates with the client’s internal data pipelines, that client does not switch vendors the following year. The switching cost is not a subscription cancellation. It is rebuilding an entire system woven into how the organization operates. High acquisition cost, very high retention, very high contract value. That is the economic structure the FDE model produces.
The Technical Skills FDEs Must Have
It is useful to be precise about the technical gaps FDEs bridge.
- Prompt architecture: Writing a prompt that works in a demo is not the same as one that works reliably across thousands of production inputs. FDEs design prompt architectures like system prompts, few-shot examples, structured output formats, and guardrails that hold up under real-world variation.
- Retrieval-Augmented Generation (RAG) pipelines: Most enterprise use cases require the model to reason over internal company data absent from the model’s training data. RAG involves embedding documents into a vector database (such as Pinecone, Weaviate, or pgvector), retrieving relevant chunks at inference time, and injecting them into the prompt context. The pipeline design like chunking strategy, embedding model, similarity metric, and reranking logic significantly affects output quality. FDEs configure this for the client’s specific data.
- Evaluation frameworks: Anthropic’s FDE job specification requires “production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale.” Building evaluation suites that catch hallucinations, regressions, bias, and grounding gaps before production is a non-negotiable FDE skill in 2026. OpenAI’s own documentation describes this with John Deere: “after reviewing hundreds of real-world examples with domain experts, building custom evaluation systems to measure accuracy, and iterating.”
- Agent development: As enterprises move from single-step inference to multi-step agentic workflows, FDEs need hands-on experience with agent frameworks. These include LangGraph, LangChain, CrewAI, and DSPy. They also need experience with multi-step tool-use chains where models call external APIs, read from databases, or write to internal systems within a single workflow.
- Production observability: Models behave differently in production than in development. FDEs implement logging, monitoring, and alerting systems that track model outputs over time, including latency, token usage, error rates, and output drift.
- Security, compliance, and data governance: Enterprise clients in financial services, healthcare, and government have strict data handling requirements. FDEs must understand how to deploy models inside client-controlled infrastructure, which often means running models on-premises or in a private cloud rather than calling a public API endpoint.
OpenAI’s Forward Deployed Engineering Team
OpenAI began building its Forward Deployed Engineering team in late 2024 and accelerated hiring through 2025. The Source Read original →
