What Is a Forward Deployed Engineer?

The most common failure mode in enterprise AI is not a weak model. It is a working model that never makes it into production.

Companies are buying AI platforms at a record pace. As a result, the bottleneck has shifted from capability to implementation. The challenge is getting AI solutions to run consistently and reliably within a company's workflows, data environment, compliance requirements, and organizational culture. That last mile is where most AI initiatives stall.

The Forward Deployed Engineer (FDE) exists to close that gap.

FDE Defined: A Forward Deployed Engineer is a production engineer who embeds with a customer to turn a general AI platform or software product into a working system inside that customer's real workflows, data, and constraints. The role is customer-embedded and outcome-owned. It is not remote support, architecture-only consulting, or a temporary implementation contract. An FDE stays until the system works in production, then feeds what they learned back into the product.

Three things that define the role:

• The engineer works inside the customer environment, not behind a ticketing system

• They own the outcome end-to-end, from problem framing through deployment and iteration

• They translate between business process and production engineering, in both directions

This article explains what an FDE does, what makes someone effective in the role, how it differs from adjacent titles, and when a company needs FDE-style talent to make AI operational.

Why the Role Is Surging Now

The FDE role was pioneered by Palantir in the early 2010s. Palantir's internal description frames it as "one customer, many capabilities" versus the traditional software engineer's "one capability, many customers." For years it remained a niche title associated with defense contracts and high-stakes government deployments. That changed fast.

By 2025, OpenAI, Anthropic, Amazon Web Services, and Google had all built FDE-style deployment functions. The reason is the same across all of them: enterprises can now access powerful AI models, but they cannot reliably operationalize them without embedded technical help. The platform is not the bottleneck anymore. The implementation is.

The hiring data reflects this shift directly. According to Perspective AI's 2026 FDE Hiring Trends report, FDE job postings grew from approximately 643 in April 2025 to over 5,300 by April 2026, a 729% year-over-year increase. FDE Pulse tracked more than 900 live FDE roles across the U.S. in May 2026, with 72% concentrated in enterprise-segment employers.

The core tension driving demand:

Andrew Ng, writing in The Batch, noted that FDE is "one of the buzzy new jobs in Silicon Valley, especially for AI agentic workflows," while also predicting that demand for AI Engineers will ultimately outpace FDE demand. That distinction matters: the FDE is not a permanent organizational fixture for every company. It is a deployment capability that closes the gap while internal teams mature.

The practical signal: When AI companies with world-class engineering teams still hire FDEs to deploy their own products, the last-mile implementation problem is real.

What an FDE Actually Does Day to Day

The FDE title sounds strategic. However, the actual work is more tactical than that.

A 2026 survey of 1,500 FDEs by Perspective AI found that the average FDE spends 47% of their time on customer-facing work, 31% coding, and 22% on internal coordination and research synthesis. That breakdown matters because it kills two common misconceptions at once: FDEs are not just consultants who occasionally write code, and they are not pure software engineers who happen to attend client calls.

A realistic day in the field

Morning

• Standup with the deployment team; review overnight system issues, data failures, or user feedback

• Check production health of the customer environment

• Identify the day's primary blocker: a data pipeline problem, a permissions issue, a model output quality gap, or a workflow step that operators are skipping

Midday

• Working session with customer operators to map where the process actually breaks

• Prototype a fix, a new agent path, or a revised integration

• Demo something same-day or next-day; FDEs do not wait for sprint reviews to show progress

Afternoon

• Harden what was demoed: add monitoring, access controls, approval steps, and exception handling

• Write documentation for the customer team so the system survives the FDE's departure

• Share reusable patterns back to the product or platform team

• Realign stakeholders if the scope or success metric has shifted

What the work actually involves

The realistic breakdown of FDE responsibilities includes more of the following than most job descriptions admit:

• Data plumbing: cleaning, normalizing, and routing data between systems that were never designed to talk to each other

• Integration work: connecting the AI platform to existing APIs, databases, ERPs, and approval workflows

• Workflow redesign: identifying which steps in a process need to change for AI to add value, not just be added on top

• Rapid prototyping: building something functional in hours or days, not weeks, so operators can react to a real system instead of a slide deck

• Change management: persuading process owners, IT teams, and frontline users that the new system is worth adopting

• Production hardening: turning a working prototype into a system with monitoring, fallback logic, and operational guardrails

The work that appears less often than pure engineering roles expect: greenfield platform architecture, long isolated build cycles, and clean internal abstractions.

Palantir's published day-in-the-life account emphasizes that FDEs design, write, and test workflows; configure platform capabilities; handle production stability; and share patterns across deployments. The customer-facing work is not a distraction from the engineering. It is the source of the engineering decisions.

The Core Skill Set: What Makes Someone Good at This Role

The FDE role is genuinely hybrid. The skills that make someone effective span engineering, product thinking, and organizational navigation. Hiring for one dimension and expecting the others to follow is the most common mistake companies make when building this capability.

1. Technical depth in production systems

An FDE must write production code, not just review it. The specific stack varies by context, but the underlying capability is consistent:

• Building and debugging integrations across APIs, databases, and third-party platforms

• Deploying and maintaining AI models or agent pipelines in real environments

• Diagnosing failures in production: data issues, latency problems, permission errors, model drift

• Understanding enough about infrastructure to identify where a system will break under real load

The key distinction from a solutions architect is ownership. An FDE is responsible for the system running reliably, not just for designing a system that could.

2. Business process translation

Technical depth alone is not sufficient. FDEs work with operators, business unit leaders, compliance teams, and frontline users. They need to:

• Extract the real workflow from what operators describe versus what they actually do

• Identify which process steps are genuinely painful versus which ones people have just learned to tolerate

• Reframe vague requests ("we want AI to help with approvals") into shippable, scoped systems

• Communicate tradeoffs to non-technical stakeholders without losing technical precision

Andrew Ng's framing is useful here: writing in The Batch, he describes the FDE as someone "embedded in a client organization to customize solutions and tune agentic workflows for that client's particular needs." The customization is both technical and organizational.

3. Execution under ambiguity

Enterprise deployments rarely arrive with clean requirements. An FDE needs to be productive when the problem is not fully defined, the data is incomplete, and the success metric is still being negotiated. That requires:

• Rapid prototyping: building something demonstrable quickly so the customer can react to a real system

• Prioritization under pressure: knowing which blocker to solve today versus which to document and defer

• Comfort with iteration: shipping incrementally and adjusting based on what users actually do with the system

• Tradeoff-making: accepting imperfect solutions that work over elegant solutions that take too long

4. Field-to-product thinking

The best FDEs do not just solve the customer's problem. They recognize when a local solution represents a repeatable pattern, then feed that pattern back to the product or platform team. This is what separates FDE programs from professional services engagements.

In practice, this looks like:

• Flagging a configuration workaround that three customers have independently needed, signaling a product gap

• Documenting a workflow pattern that can become a reusable template for future deployments

• Identifying an edge case that consistently breaks the system and escalating it as a platform bug rather than a one-off fix

Without this loop, the FDE function produces implementation labor. With it, the FDE function produces institutional knowledge that makes every future deployment faster.

5. Stakeholder navigation and change management

AI systems fail in production for organizational reasons as often as technical ones. Process owners do not trust the output. IT teams block access. Frontline users find workarounds. An effective FDE anticipates these dynamics and works through them:

• Building credibility with skeptical operators by showing results quickly

• Navigating security and compliance requirements without treating them as blockers

• Managing expectations when the first version of a system is narrower than what was originally envisioned

• Keeping the engagement moving when internal politics slow down decision-making

The skill combination that is genuinely rare: production engineering ability, business process fluency, and the interpersonal range to work credibly with a data engineer in the morning and a CFO in the afternoon.

Image 1 - Forward Deployed Engineer (FDE) Skill Set

FDE vs. Solutions Architect vs. Professional Services

The FDE role is frequently confused with adjacent titles. The confusion is understandable because the functions overlap in some areas. The differences matter because putting the wrong role into a deployment will produce the wrong outcome.

Where the lines blur

Sales engineers and solutions architects are often the people a customer interacts with before buying a platform. They are skilled at demonstrating capability, designing reference architectures, and building confidence in a product. That is genuinely valuable work. But it is pre-production work.

Professional services teams deliver implementation labor within a defined scope. They can be effective at executing a known playbook. Where they typically fall short is in the ambiguous, iterative, workflow-redesign work that characterizes real AI deployment: the kind where the requirements change after operators actually use the system.

The FDE is post-sale, post-pilot, and post-architecture. Their job starts where the other roles end.

The clearest test: Ask who is responsible if the AI system fails in production six weeks after go-live. If the answer is "the customer's IT team" or "whoever reads the runbook," the FDE function was not present. If the answer is a specific person who owns the live system and has the access and authority to fix it, that is an FDE.

When Does a Company Actually Need FDE-Style Talent?

Not every AI initiative requires a dedicated FDE. But most mid-market companies attempting to operationalize AI are dealing with at least one of the conditions where FDE-style capability is the difference between a pilot and a production system.

Signs you likely need this capability

• You have purchased or built an AI platform, but it is not being used consistently by the people it was built for

• Your AI pilot produced promising results, but moving it to production exposed data, permissions, or workflow problems that were not in scope

• Your internal team can build models or configure agents, but no one owns the end-to-end deployment and iteration cycle

• Your workflows are complex enough that a vendor's standard implementation playbook does not fit

• You are in a regulated industry where compliance requirements are blocking AI adoption rather than being built into the system from the start

The best starting point is almost always narrow

FDE-style work delivers the fastest value when it starts with one painful, high-friction workflow rather than an "AI transformation" initiative. Common starting points include:

• Document intake and extraction: contracts, invoices, applications, or reports that require manual reading and data entry

• Approvals routing: requests that move through multiple reviewers with inconsistent criteria

• Customer support classification: incoming tickets or inquiries that need triage before a human responds

• Operational briefing generation: recurring reports that require pulling data from multiple systems and summarizing it

• Exception handling: edge cases in automated processes that currently require a human to intervene

What you may not need

A company does not necessarily need a full-time FDE headcount. What it needs is the capability: someone with the technical depth to build in production, the process fluency to redesign workflows, and the organizational range to drive adoption across teams. That capability can come from an internal hire, a fractional resource, or an implementation partner with genuine engineering depth.

The distinction that matters is not the title. It is whether the person or team is accountable for the system working in production, not just for delivering the implementation.

The Role Behind Real AI Adoption

The FDE role emerged because a gap appeared between what AI platforms can do and what enterprises can reliably operate. That gap is not closing on its own. It requires a specific kind of person: technically deep enough to build in production, fluent enough in business process to redesign workflows, and organizationally capable enough to drive adoption through real organizations with real politics.

What the role is, in plain terms:

• An engineer embedded in the customer environment, not working from behind a queue

• Someone who owns the outcome, not just the deliverable

• A bridge between platform capability and operational reality

The FDE is not a new concept. Palantir built the model a decade ago. What is new is the scale of the problem it solves. As AI capability becomes a commodity, the companies that win will be the ones that can operationalize it faster and more reliably than their competitors. That requires last-mile deployment talent, whether it carries the FDE title or not.

If your organization is evaluating how to move AI from pilot to production, or trying to figure out why a capable platform is not producing consistent results in the field, the gap is rarely the model. It is almost always the implementation.

OneSpring works with mid-market companies on exactly this problem. From AI Opportunity Assessments and Value Sprints to embedded workflow design and production implementation, we help teams close the gap between AI capability and operational results. Talk to us about your AI implementation.