The FDE model: Do you need a forward-deployed engineer?

Written by
Last updated on:
November 11, 2026

Forward-deployed engineers work inside your team and own one outcome until it runs in production. Here's how the FDE model works, and a 2x2 matrix to tell when you need it.

An AI project can stall even when the model works. The trouble is usually everything around it, like data that's hard to reach or workflows nobody has written down. A demo can work on sample data and still never reach the people it was built for.

The forward-deployed engineer (FDE) model was built for that gap. Instead of handing a customer software and a manual, a company sends senior engineers to work inside the customer's environment until the solution works on real data, with real users. AI companies have adopted the model quickly, and demand for the role has grown with it.

Here's what the FDE model is, how it compares with staff augmentation and managed services, and a simple 2x2 matrix to tell whether your project needs it.

An engineer in glasses and a dark suit sits at a desk surrounded by monitors showing code and data in a dimly lit, blue-toned office. It reflects the FDE model, where a forward-deployed engineer works inside a customer’s systems to get an AI project into production.

What is the FDE model?

In the FDE model, a senior engineer works inside one customer's organization to build and launch a working solution in that customer's environment. The engineer is accountable for a business outcome, not a list of tickets. That means doing customer discovery with the people who do the work today, building a working prototype on real data, and connecting it to existing infrastructure until it runs in production.

The model is most closely associated with Palantir, where the job title is forward deployed software engineer. Palantir describes these engineers as people who “deploy our software platforms to customers” as part of "a team that directly supports one customer." It contrasts them with its software engineers who build the core product, whose focus it describes as "one capability, many customers."

That contrast is the core of the FDE model. Product engineering builds one platform for many customers. Forward deployment makes that platform work for a specific customer, with all of its real constraints.

Why AI companies adopted the FDE model

The FDE model has spread across the industry because AI deployment is hard to do from the outside. A model's results depend on the customer's data and on how people actually use the output. Getting AI applications into production often means building data pipelines and setting up access control behind the enterprise firewall, then adjusting the solution after real users try it.

AI companies have been building out an FDE function to do that work, and to get their AI solutions into production faster. According to Financial Times reporting cited by eWeek, OpenAI started its FDE team in early 2024, and Anthropic planned a fivefold expansion of its applied AI team, which includes FDEs. In one example from that reporting, OpenAI FDEs helped customize tools for John Deere's precision farming work, which helped reduce chemical spraying by up to 70%.

Demand for the role has followed. According to Indeed data reported by BW Businessworld, FDE job postings rose nearly 19-fold between June 2025 and June 2026. It's part of a broader shift in how companies buy new technology: less "here's the software," more "here's someone who will make it work."

For more on the role, read What is a forward-deployed engineer?

How is an FDE different from other customer-facing roles?

An FDE is a type of embedded engineer, and the job title overlaps with several familiar roles. Unlike traditional engineering or sales roles, though, the accountability is different:

Forward-deployed engineer compared with solutions engineers, professional services, customer success, and product engineering: main focus and accountability
RoleMain focusWhat they're usually accountable for
Forward-deployed engineerBuilding and launching a solution inside one customer's systemsA business outcome running in production
Solutions engineerShowing how a product fits a customer's needs, often during the saleTechnical fit and a successful evaluation
Professional servicesImplementing a product to a defined scopeDelivering the agreed scope, often measured in billable hours
Customer successAdoption and the ongoing relationshipRenewal and customer satisfaction
Product engineeringBuilding the core platformFeatures that serve many customers

The difference shows up in the work. An FDE spends time mapping systems and data, talking with business stakeholders, and doing rapid prototyping, then keeps iterating until the solution delivers real value. Solutions engineers and professional services teams usually work from a product that already does what the customer needs.

Vendor FDEs vs. independent FDEs

When an AI vendor sends FDEs, their job is to make that vendor's platform work for you. They build solutions for a specific customer, and what they learn flows back to the vendor's product management and product teams, so the next customer, or a future customer, gets a better product. That feedback loop is part of why the model works so well for AI companies.

The trade-off is focus. A vendor's FDEs build bespoke solutions around that vendor's platform, and large AI companies may reserve their own FDEs for their largest, strategic accounts. If your solution needs several models or tools, or you aren't a strategic account for any one vendor, an independent FDE can build across your whole stack instead.

How does the FDE model compare with staff augmentation and managed services?

When companies need outside engineering help, the usual choice is between two delivery models. Staff augmentation adds engineers to your team who work under your direction. Managed services hand a defined scope to a provider that runs it. Both assume someone already knows what to build. The FDE model fits when nobody does yet.

FDE model vs staff augmentation vs managed services: who directs the work, accountability, where they work, best fit, and drawbacks
ComparisonStaff augmentationManaged servicesFDE model
Who directs the workYour teamThe providerYou set the goal, the FDE owns the path
Accountable forAssigned tasksThe agreed scope and service levelsOne outcome running in production
Where they workInside your teamUsually outside, on the provider's processesInside your team, data, and systems
Best whenThe work is clear, and you have leads to direct itThe work is clear, and you'd rather not manage itThe goal is clear, but the path isn't
Main drawbackYour leads become the bottleneckScope changes are slow and costlyNeeds a business owner with time to engage

Like staff augmentation, an FDE works inside your team, with your tools and permissions. Like managed services, an FDE is accountable for a result tied to business outcomes. The difference is that an FDE expects the path to change once real data and real users show up.

For a full comparison of the two traditional models, read Staff augmentation vs. managed services: How to choose the right model.

The 2x2 matrix: Does your project need the FDE model?

There are two questions that do most of the sorting:

  • Is the path to the outcome clear? Can you describe what needs to be built, or will you have to find out along the way?
  • Do you have someone to direct the technical work? Is there a lead on your team with the time and technical expertise to make day-to-day decisions?
FDE model 2x2 decision matrix: staff augmentation, managed services, building in-house, or a forward-deployed engineer, based on whether the path is clear and whether you have a technical lead
Is the path clear?You have a technical lead to direct the workYou don't have a lead to direct the work
The path is clearStaff augmentation. Add engineers to your team and keep directing the work yourself.Managed services. Hand the defined scope to a partner that delivers and runs it.
The path is unclearBuild in-house, or add an FDE to speed it up. Your lead can steer discovery, and an FDE adds hands-on production experience.Forward-deployed engineer. You set the goal, and the FDE owns discovery and delivery inside your team.

You can usually place a project in one box fairly quickly. If a project lands in two boxes, it's often two projects. For example, an AI pilot might need an FDE to find the path, followed by managed services to run the finished system.

The path is clear, and you have a lead: staff augmentation

Choose staff augmentation if your team already knows what to build and has someone to direct it. A web app with a clear roadmap and a growing backlog is a good example. You keep control of the architecture and priorities, and new engineers add capacity.

The path is clear, but you don't have a lead: managed services

If the scope is well defined and you don't want to manage the work day-to-day, a managed engagement can take it off your plate. This fits work you can describe in a statement of work, like a data migration with set requirements, or long-term support for a system your IT team no longer has time to run.

The path is unclear, but you have a lead: build in-house, with an FDE if you need speed

If you have a strong technical lead but the work is new territory, your own team can explore it. The catch is time. Your lead may already be stretched across other projects, and AI work in production brings its own problems, like messy data and approval steps. One FDE can work alongside your lead and bring experience from earlier deployments.

The path is unclear, and you don't have a lead: forward-deployed engineer

This is where the FDE model fits best. Staff augmentation would leave added engineers waiting for direction nobody has time to give. Managed services would need a scope nobody can write yet. An FDE works with your business owner to understand the business problem, prototypes on real data, and builds the solution into your production systems, including the handoffs between what the AI does and what people still do.

What does an FDE do day-to-day?

The work changes as the project moves from discovery to production, but it usually follows the same arc:

  • Discovery. The FDE watches how the work gets done today, finds the pain points, and maps the systems and data involved. Domain knowledge from your team matters most here.
  • Rapid prototyping. The FDE builds a working prototype on real data early, so business stakeholders can react to something concrete.
  • Integration. The FDE builds deep integration with your existing infrastructure, which often means data engineering work, access control, and running inside the enterprise firewall.
  • Iteration with real users. The FDE sets up feedback loops with the people using the tool and makes changes through rapid iteration until it holds up in the real world.
  • Handover. The FDE documents the system and trains your team so it can keep up with continuous improvement after launch.

That mix takes specialized skills. A good FDE needs senior engineering ability, plus the judgment and people skills to scope a business problem with customer teams. That's also why the role pays well. FDE job postings show a median base salary of about $174,000, according to Bloomberry's analysis, and investor Tomasz Tunguz estimates that senior FDEs at AI labs earn hundreds of thousands of dollars a year.

Signs your project needs a forward-deployed engineer

There are a few signs that an FDE model might be a better fit than either traditional model:

  • You've run an AI pilot that never reached production. The demo worked, but connecting it to real systems and real users stalled.
  • Nobody can write the requirements yet. You know the business result you want, but not which steps AI agents can take over or what data you'll need.
  • The work crosses teams. The solution has to fit legacy systems and the people who'll use it every day, which is common at large companies.
  • Your technical leads are already at capacity. Adding engineers would add management work to people who don't have time for it.

If none of these apply, staff augmentation or managed services may be the simpler and cheaper choice. There's no reason to hire a detective for a problem you've already solved.

For the full decision matrix, download our Forward Deployed Engineer Guide.

How to start with the FDE model

Keep the first engagement small enough to measure. Start with a single business process and a business owner who's accountable for the result. Agree up front on what "working" means, such as time saved per case or an error rate you can check. A clear target also shortens time to value, because everyone knows when the first version is done. Getting a working system live sooner can also be a competitive edge.

Get your team ready before the FDE starts. An FDE who spends the first month waiting for system access is a bit like a plumber waiting in the driveway for someone to find the key. Line up data access and time with the people who do the work before day one, and agree on the FDE's reporting line so decisions don't stall.

Plan what happens after launch. Once the path is clear, the work may move to a different box in the matrix. Your own team might take it over, or a managed engagement might run it.

Bringing a forward-deployed engineer into your team

Our forward-deployed engineers are senior nearshore engineers who work inside your team to take AI projects from pilot to production. Because we aren't tied to one AI vendor's platform, they can build custom solutions across the models and tools you already use. We can share a shortlist within 48 hours of the first call, and the first two weeks are free. If the fit isn't right, we swap the engineer or stop, and you don't pay for those weeks.

We also offer staff augmentation and managed projects, so we can help clients place each project in the right box of the matrix.

Book an FDE to talk through your project.

Learn more

Frequently asked questions

In the FDE model, senior engineers work inside a customer's organization to build and launch a solution in the customer's own environment. They're accountable for a business outcome running in production, not for hours or tickets. The model is most closely associated with Palantir and has been widely adopted by AI companies.

No. An augmented engineer works on tasks your team assigns. A forward-deployed engineer is accountable for getting one outcome into production, which includes discovery and integration with your systems. Both work inside your team, but an FDE owns the path to the result.

Solutions engineers usually help customers evaluate a product and confirm it fits, often during the sales process. An FDE builds and launches the solution inside the customer's systems and stays until it's working in production.

Choose an FDE when you know the outcome you want but can't yet define the scope, which is common in AI projects. Managed services works best when you can describe the work in a statement of work. If the path will change once the team sees your real data, an FDE is usually the better fit.

Yes. Once an FDE has found the path and launched a working solution, the work is clearer. Your own team can take it over with augmented engineers, or a managed engagement can run and support it.