.svg){kind=icon}
Learn
A forward-deployed engineer (FDE) is a software vendor's customer-facing engineer who embeds with a customer's team to configure, adapt, integrate, and operate the vendor's product inside the customer's real production environment.
Last updated: October 23, 2026
Why it matters to your mission. Complex software rarely works the day it arrives. It has to be configured, integrated with legacy systems, and adapted to the data and constraints of a specific environment before it produces anything useful. The forward-deployed engineer is the role the software industry invented to do that work in the field, sitting with the mission team. It is a real and useful function. It also creates a dependency worth naming: when the people who can make the capability work belong to the vendor, your mission's tempo is tied to the vendor's engineers. This page explains the role neutrally, then explains the government-owned alternative, which is capability your own cleared people can operate and extend.
A forward-deployed engineer (FDE) is a software vendor's customer-facing engineer who embeds with a customer's team to configure, adapt, integrate, and operate the vendor's product inside the customer's real production environment. The role is sometimes called a forward-deployed software engineer (FDSE) or a customer-embedded engineer, and it sits between product engineering, solutions engineering, and implementation.
The distinguishing feature is where the work happens. A traditional product engineer builds one version of a product for many customers at once. An FDE does the opposite: they build and adapt a working system for a single customer, close enough to that customer's team to see exactly where the product breaks down in practice. As one widely cited description puts it, an FDE is "an engineer who gets embedded in a customer's team to fill the gap between what your product does and what the customer needs" (PostHog, 2025). The term was coined around 2009 at a data-analytics software company known for its government and intelligence work, and it borrows from military usage, where "forward-deployed" describes resources positioned near the operational area (Wikipedia, Forward Deployed Engineer).
Key takeaways
A forward-deployed engineer owns the path from a software purchase to a working deployment inside the customer's environment. The work spans the full delivery lifecycle: requirements analysis, design, implementation, integration, and sustained operation. An engagement usually starts with discovery, where the FDE maps the customer's existing systems, data sources, authentication, and compliance requirements, then moves into writing production code, building integrations, and solving the environment-specific problems that otherwise turn a promising purchase into unused software.
Three properties define the role. It is production work, not demos. It is customer-specific: the FDE adapts the product to one organization's reality rather than building generalizable features. And in many companies it includes a two-way loop, where what the engineer learns in the field feeds back into the vendor's core product. A common shorthand describes the FDE as part software engineer, part solutions architect, part consultant. What unites those is a single job: make the vendor's capability actually work where the mission is.
The difference is scope and proximity. A product or platform engineer builds a capability meant to serve many customers and spends most of their time in the vendor's own codebase. A forward-deployed engineer builds for one customer at a time and spends most of their time in that customer's environment and alongside that customer's people. One industry description estimates FDEs spend the majority of their time with customers, while traditional engineers spend very little, and frames the split as FDEs building "the rough gravel road" that product teams later turn into a "paved superhighway" (PostHog, 2025).
It is also worth separating the FDE from two roles it is often confused with. A sales or solutions engineer runs demos and scopes the deal; a field service representative or support engineer responds to tickets and keeps a fielded system running to spec. The FDE sits in a different place: they write new production code and build the custom integrations that make the product fit, and they stay embedded until the deployment works.
| Role | Who employs them | Primary job | Writes custom production code? |
|---|---|---|---|
| Forward-deployed engineer (FDE) | The software vendor | Configure, integrate, and adapt the vendor's product inside one customer's environment | Yes, customer-specific |
| Product / platform engineer | The software vendor | Build generalizable features for all customers | Yes, but for the shared product |
| Sales / solutions engineer | The software vendor | Scope the deal, run demos, design the proposed solution | Generally no |
| Field service representative | The software vendor or integrator | Install, maintain, and service a fielded system to spec | Generally no |
| Government engineer / operator | The government (in-house or cleared workforce) | Operate, configure, and extend owned capability for the mission | Yes, when the capability is built to be owned |
A forward-deployed engineer needs a blend that is uncommon in one person. The core is strong software engineering, because the job is real production work: writing code, building integrations, and debugging systems in a live environment. On top of that sits data integration skill, since most of the value is in connecting a new capability to legacy systems, messy data schemas, and existing authentication and security controls. The current wave of FDE hiring is heavily focused on AI, so many roles now add skills like retrieval pipeline tuning, token budget management, and debugging model behavior that only appears in real data.
Two non-engineering skills matter just as much. The FDE works directly with the customer's team, so communication and the ability to translate a mission need into a technical implementation are essential. And the FDE has to operate under the customer's real constraints, which in defense and government settings means clearances, accreditation boundaries, and compliance. The role was created in the first place because even simple demonstrations for intelligence customers could require weeks of clearance and access work, and customers needed engineers who could make features work inside fragmented data systems and high-stakes operational constraints, not engineers who could only show features off.
Vendors use forward-deployed engineers because the gap between what software can do and what a customer can get it to do is wide, and embedding an engineer is the most reliable way to close it. This is especially true for AI. The distance between a general model's capability and a working enterprise or mission application is large, full of data integration, security, and workflow problems that do not appear until the software meets the customer's real environment. Embedding an engineer also lets a vendor demonstrate value through results instead of slideware, and it supports the high-value contracts that complex software commands.
The model has spread well beyond its origin. Multiple leading AI companies now run FDE organizations to carry customers from initial access to production deployment, and in mid-2026 a major cloud provider announced a billion-dollar investment to build a dedicated forward-deployed engineering organization and embed thousands of such engineers inside customer teams (DataCamp, 2026). For a buyer this is a signal worth reading carefully. When a vendor's go-to-market depends on placing its own engineers inside your environment to make the product work, the expertise to run that capability is, by design, concentrated in the vendor.
The forward-deployed engineer model solves a real problem, and there is nothing wrong with the role itself. The question for a mission owner is narrower: when the capability is working, who can keep it working and change it as the mission changes? If the answer is only the vendor's forward engineers, the mission has acquired a dependency that becomes a constraint in exactly the conditions defense operations face most. Clearance and access can be slow. Environments are contested, disconnected, or air-gapped. Tempo can change faster than a vendor can surge people. And the expertise walks out when the engagement ends.
The U.S. Government names this dependency directly. In a 2025 review of defense command and control, the Government Accountability Office defined the risk this way: "Vendor lock means DOD entities cannot shift to another vendor without incurring substantial costs, rework, or inconvenience or become reliant on that contractor to achieve its missions" (GAO-25-106454, 2025). The Department's own answer is to buy differently. The Chief Digital and Artificial Intelligence Office created Open DAGIR, the Open Data and Applications Government-owned Interoperable Repositories framework, specifically to "preserve government data ownership" and keep infrastructure "interoperable across platforms," so the Government can "prototype and adopt new software and data tools quickly, at the speed of mission relevance" rather than staying captive to a single vendor's proprietary system (CDAO Open DAGIR Fact Sheet, 2024). Dependence on a vendor's forward engineers is one concrete form of the lock-in these policies are built to avoid.
The government-owned alternative is to acquire capability built to be owned, operated, and extended by your own cleared workforce, rather than capability that only functions while a vendor's engineers are embedded. The difference is not whether skilled engineers are involved; it is who holds the expertise and the controls. In an owned model, the reasoning layer and its provenance stay with the customer, configuration and extension can be done by cleared government or integrator staff, and resolved outputs remain portable rather than trapped in a vendor's proprietary model. This is the distinction between buying a service that depends on a vendor's forward engineers and acquiring government-owned AI for defense your own people run, and it drives the same case made for government-owned alternatives to commercial data platforms.
Reducing FDE dependence is not a claim that your workforce never needs help standing a capability up. It is a design requirement: the capability must be configurable and extensible by cleared people who are not the vendor, and it must keep working when the vendor's engineers are not in the room. That requirement connects to the practices that let a workforce own AI responsibly, including MLOps for defense, which gives your own teams a repeatable way to deploy, monitor, and update models, and accredited AI deployment, which keeps that owned capability inside its accreditation and security boundary.
Who holds the expertise when the vendor leaves
An FDE makes a vendor's capability work inside your environment. The dependency is that the expertise to run and extend it lives with the vendor's people.
GAO defines vendor lock as becoming reliant on a contractor to achieve missions; CDAO created Open DAGIR to preserve government data ownership and interoperability.
Torch.AI builds government-owned reasoning infrastructure: capability designed to be owned, operated, and extended by the customer rather than capability that only works while a vendor's engineers are embedded. The relevant difference is ownership of the layer where fragmented data becomes understanding. ORCUS provides the data-availability layer that connects to existing systems of record and preserves provenance. NEXUS applies semantic representation so unstructured records become something a system can reason over. HALO fuses resolved entities and relationships into a graph an analyst can inspect and trace. Because this runs as a system of reason on top of existing systems of record, it complements what you already have instead of replacing it, and in a government-owned deployment the customer keeps control of the reasoning layer and its provenance.
Practically, the configuration and extension work an FDE would otherwise own can be done by cleared government or integrator staff, and the capability keeps working whether or not a vendor's forward engineers are present. The goal is not to remove skilled engineers from the picture; it is to make sure the expertise and the controls do not have to live with the vendor. You can see how this is packaged on the Torch.AI software page. If your concern is that a capability stops advancing the moment a vendor's embedded engineers leave, that is a question of ownership and architecture, and it is the one this infrastructure is built to answer. Request a technical walkthrough and we will run it against a representative slice of your own multi-source data.
No. The two roles are often grouped because both involve working at the customer site, but they do different work. A field service representative installs, maintains, and services a fielded system so it keeps running to its existing specification. A forward-deployed engineer writes new production code and builds the custom integrations that make a product fit a customer's environment in the first place, and the role carries the two-way product feedback loop that a service representative does not. The practical implication for a buyer is that an FDE-dependent capability is one where ongoing adaptation, not just maintenance, requires the vendor's people. That is a deeper dependency than routine field service, and it is the dependency a government-owned model is designed to reduce.
If your concern is avoiding a capability that only works while a vendor's forward engineers are embedded, require the following of any AI or data capability you acquire:
Evaluating a capability? Bring these six requirements to a scoping call and we will walk each one against your environment: request a technical walkthrough.
A forward-deployed engineer owns the path from a software purchase to a working deployment inside the customer's environment. The work covers discovery, then writing production code, building integrations and connectors, and solving the environment-specific problems that otherwise leave software unused. It is production work rather than demos, it is adapted to one customer at a time, and it often feeds field learnings back into the vendor's core product.
A traditional product engineer builds one capability for many customers and works mostly in the vendor's own codebase. A forward-deployed engineer builds for a single customer at a time and spends most of their time inside that customer's environment, inheriting its data schemas, authentication, and compliance constraints. The FDE adapts and integrates the product; the product engineer builds the generalizable version.
An FDE needs strong software engineering, systems and data integration skill, and increasingly AI skills such as retrieval tuning and debugging model behavior in real data. Just as important are the ability to communicate with a customer's team and translate a mission need into an implementation, plus the ability to work under real constraints, which in defense means clearances, accreditation boundaries, and compliance.
Because the gap between what software can do and what a customer can get it to do is wide, and embedding an engineer is the most reliable way to close it, especially for AI. Embedding also lets vendors prove value through results rather than demos and supports high-value contracts. The trade-off for buyers is that the expertise to run the capability becomes concentrated in the vendor.
The alternative is acquiring capability built to be owned, operated, and extended by your own cleared workforce, rather than capability that only works while a vendor's engineers are embedded. Skilled engineers are still involved; the difference is that the expertise, the controls, and the reasoning layer stay with the customer, so the capability keeps working and keeps advancing independent of the vendor.
No. A field service representative installs and maintains a fielded system to its existing specification. A forward-deployed engineer writes new production code and builds custom integrations to make a product fit, and carries a product feedback loop. The practical difference for a buyer is that FDE-dependence means ongoing adaptation, not just maintenance, requires the vendor's people.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the capability you need to operate and extend. We will scope a session around your data and your workforce. No embedded crew. Your cleared team. Real work.
