What Is a Forward Deployed Engineer? Role, Origins, and Demand

A demo can make almost any AI system look finished. Feed it clean sample data, ask it the questions it was tuned to answer well, and it performs. Put that same system in front of a real company’s actual data, actual permissions structure, and actual messy workflow, and the gap between demo and working product becomes obvious fast. Someone has to close that gap, and increasingly, the person doing it carries the title forward deployed engineer.

The term has gone from a niche label inside one company to one of the most talked-about job titles in tech in a remarkably short time. This guide explains where it came from and what the job actually involves day to day. It also covers how the role differs from the adjacent roles it gets confused with, and why companies serious about AI adoption are building entire organizations around it.

Where the Term Came From, and Why It’s Everywhere Now

Palantir pioneered the role in the early 2010s to solve a specific problem it couldn’t solve any other way. Its software was built to work with government and enterprise data that was too specific, too messy, and too high-stakes to hand off with a manual and a support ticket queue. Someone had to sit inside the client’s environment and understand the actual data and workflow. That person then built the integration that made the generic platform work for that one organization.

That same problem has resurfaced across the AI industry at far larger scale. OpenAI set up a dedicated forward deployed engineering team in early 2025 and grew it through the year. Its job postings describe the work as turning research breakthroughs into production systems for customers, in settings where model performance matters and ambiguity is the default. In May 2026 the company went further and launched the OpenAI Deployment Company, a separate unit with more than $4 billion in initial investment that places forward deployed engineers inside enterprise organizations.

In June 2026, Amazon Web Services announced a dedicated forward deployed engineering organization backed by a $1 billion investment. Its engineers embed with customer teams to build production agentic AI systems, with the stated goal of compressing timelines from months to days. Anthropic, Google, and a growing list of enterprise software and AI companies now hire for the role as well.

What Is a Forward Deployed Engineer? A Working Definition

A forward deployed engineer is a software engineer who embeds directly inside a customer’s team and infrastructure to build, integrate, and operate a working system. The alternative, building a generic product from company headquarters and handing it off, is exactly what the role is designed to avoid. The engineer typically works inside the client’s environment, whether that’s on-site, hybrid, or remote access into the client’s own cloud. They write production code against the client’s real data and existing systems rather than a sanitized demo environment.

The defining feature of the role is ownership through production. A forward deployed engineer doesn’t hand off a design document and move to the next account. They stay involved until the system is actually running and delivering value inside the client’s operation, and often continue supporting it afterward.

What Is a Forward Deployed Software Engineer, Exactly?

Forward deployed software engineer, often abbreviated FDSE, and forward deployed engineer are used interchangeably across the industry and describe the same role. Some companies use one title, some the other, and a few use both depending on seniority or team structure. The underlying job, embedding with a customer to build and ship working software inside their environment, is consistent regardless of which version of the title appears on the posting.

The “software” in the longer title is sometimes added simply to distinguish the role from forward-deployed positions in other technical fields. Examples include forward deployed data scientists or forward deployed solutions architects, which involve a similar embedded delivery model applied to a different discipline.

A Day in the Life: What the Role Actually Involves

Strip away the framing and the job comes down to one thing. The customer has a problem, the company’s product almost solves it, and the forward deployed engineer closes that remaining gap from inside the customer’s own systems.

• Discovery inside the real workflow. Not a requirements document handed down from a project manager, but sitting with the analyst or operations lead and watching how the work actually happens. That includes the manual workaround or spreadsheet nobody mentioned in the official process.
• Solution design against real constraints. Scoping and prototyping against the client’s actual data and systems, not a clean sample dataset. This surfaces integration problems and edge cases much earlier than a generic requirements process would.
• Building the last mile. Writing the integration code, data pipeline connections, and configuration that turns a general-purpose platform into something that works specifically inside this client’s infrastructure and legacy systems.
• Staying through production. Remaining engaged after launch to handle the issues that only show up under real usage, and feeding what gets learned back to the core product team so the next deployment goes faster.

Forward Deployed Engineer vs. Solutions Engineer vs. Consultant vs. Product Engineer

The role gets confused with several adjacent titles that sound similar but involve meaningfully different responsibilities.

Role	Core Output	Relationship to Production Code
Forward Deployed Engineer	A working system running inside the client’s environment	Writes and owns production code directly
Solutions Engineer	Technical support during the sales process	Typically builds demos and proofs of concept, not production systems
Consultant	Recommendations and a delivery plan	Generally does not write the implementation code itself
Product Engineer	The generic product used by every customer	Writes code, but for the shared product rather than one client’s specific environment

A skeptical, and roughly accurate, view of the title is that a forward deployed engineer is simply a new label for a customer-facing software engineer. That’s close to true, and it’s also close to the actual point. The title exists to signal that this person writes real, production-grade code while sitting inside the customer’s world rather than at a comfortable remove from it.

Why AI Pushed This Role Into the Spotlight

Getting an AI system to perform well in a controlled demo has become comparatively easy. Getting that same system to perform reliably against a specific company’s real data, security requirements, and operational quirks remains genuinely hard, and that gap is exactly where forward deployed engineers operate. As more companies moved from experimenting with AI to running it in production during 2025 and 2026, the demand for people who could actually close that gap grew sharply.

Hiring data reflects how quickly this happened. The Financial Times reported that job postings for the role rose by more than 800% between the start of 2025 and September of that year. That growth tracked closely with the pace at which major AI companies began publicly building out these teams, and interest in the title has kept climbing since.

The Skills That Actually Matter for This Work

Technical depth is the baseline, not the differentiator. A forward deployed engineer needs to be a genuinely strong engineer, comfortable with full-stack development, system design, and data integration. There’s rarely a specialist on hand to take over the parts that don’t fit their usual scope.

What separates people who thrive in the role from strong engineers who don’t is a set of adjacent skills:

• the ability to translate a vague, half-articulated business problem into a scoped technical plan without waiting for a formal specification;
• comfort operating with significant autonomy and ambiguity;
• enough interpersonal skill to sit with a domain expert who has never written a line of code and extract the actual requirements from how they describe their work.

Why Companies Build (or Outsource) a Forward Deployed Function

Not every company needs an internal forward deployed engineering team, and building one from scratch is a significant organizational investment. It requires:

• engineers willing to travel or work embedded with clients;
• a different management structure than a typical product engineering organization;
• a business model where the economics of high-touch, customer-specific delivery actually make sense.

Consider companies selling a platform that needs real customization to deliver value, particularly in AI adoption, where the gap between a working demo and a working production deployment is often the entire sales cycle. For them, an embedded delivery model can be the difference between a signed contract and a system that never actually gets used.

Where building a large internal team isn’t the right fit, working with a partner who already operates this way achieves the same outcome without the same organizational buildout. That partner embeds engineers directly with the client to close the last mile. The practical choice is then usually between a dedicated team and staff augmentation, depending on how much delivery ownership the partner should carry.

Diatom works with clients in a similar way. We have been in business since 2004, our 80+ senior engineers work mainly with clients in North America and Western Europe, and we have delivered AI integration and AI solutions since 2019. Our engineers use AI as an active assistant, and every AI output is reviewed by a senior engineer.

Should Your Company Have Forward Deployed Engineers?

The honest answer depends on how much of your product’s value depends on deep customization to each customer’s specific environment. A product that works reasonably well out of the box for most customers doesn’t need this model. A product whose value genuinely depends on custom integration work, complex data pipelines, or workflow-specific configuration is exactly the situation this role was built for.

The same logic applies whether the customization work is being done by an AI platform closing the gap between a demo and production, or by any complex software system. In both cases, the system needs to fit a client’s existing infrastructure rather than the other way around.

Frequently Asked Questions

What does a forward deployed engineer do?

A forward deployed engineer embeds inside a customer’s team and infrastructure to build, integrate, and run a working system. The work spans discovery inside the real workflow, solution design against the client’s actual data, writing the integration code that makes a general-purpose platform fit, and staying engaged after launch. Lessons from each deployment are fed back to the core product team so the next one goes faster.

Is a forward deployed engineer the same as a solutions engineer?

No. A solutions engineer typically supports the sales process with demos and proofs of concept, while a forward deployed engineer writes and owns production code inside the client’s environment. The forward deployed engineer stays involved until the system is running and delivering value, and often supports it afterward. Consultants, by contrast, usually deliver recommendations and a plan rather than the implementation itself.

What skills does a forward deployed engineer need?

Strong engineering is the baseline: full-stack development, system design, and data integration, since there is rarely a specialist on hand to take over the parts that fall outside the usual scope. What sets successful forward deployed engineers apart is the ability to turn a vague business problem into a scoped technical plan. Comfort with autonomy and ambiguity matters too, as does the interpersonal skill to draw real requirements out of non-technical domain experts.

Why is the forward deployed engineer role in such demand?

Getting AI to work in a controlled demo has become comparatively easy, but making it perform reliably against a specific company’s data, security requirements, and workflows remains hard. As companies moved AI from experiments into production, they needed engineers who could close that gap from inside the customer’s systems. Major AI and cloud providers, including OpenAI and Amazon Web Services, have since built dedicated organizations around the role.

Getting the Embedded Delivery Model Right

You may be evaluating whether to build an internal forward deployed function. Or you may need engineers who can embed directly with your team and close the gap between a working prototype and a system running reliably in production. Either way, the underlying need is the same: engineers who can operate inside real, messy environments rather than only in a clean, generic one.

Our team works this way as a matter of course, embedding directly with client teams to build custom software that fits their actual infrastructure and workflows rather than a generic template. If you’re trying to work out whether your project needs this kind of embedded delivery, contact us and we’ll help you think it through.