What Is a Forward Deployed Engineer and What Do They Bring?

A Forward Deployed Engineer (FDE) is an engineer who works alongside the client's team, learns the workflow on site and personally writes the code that connects AI to the company's existing systems. They understand the problem the way a consultant does and take the solution into production the way a software developer does. For companies whose AI trial stalled at the demo stage and never reached their CRM, ERP or internal tools, this is one of the most effective ways to work.

In this article I cover where the role came from, how it differs from classic consulting and from software outsourcing, what an FDE does in the first few weeks, and how to tell when your company needs one.

Where did the Forward Deployed Engineer role come from?

The role emerged at Palantir in the early 2010s. Internally, Palantir called these engineers "Deltas". In the company's own words, Deltas deploy the software platform at the customer, adapt it to the customer's business problem and measure their success by the impact on the customer's goals. Palantir's post comparing the Dev and Delta roles sums up the difference in one line: a traditional software engineer works on "one capability, many customers", while an FDE works on "one customer, many capabilities".

Over the past two years the role has come back into focus along with AI companies. The reason is simple: language models are powerful, but connecting a model to a company's data, permission structure and daily workflow is still hands-on engineering work. The Pragmatic Engineer's piece on FDEs explains in detail why the role has become so sought after.

What does a Forward Deployed Engineer do?

An FDE's work starts in a meeting, but most of it happens inside the team's day-to-day work. Typical responsibilities include:

• Learning the workflow on site: They watch how the sales, operations or support team handles a task today. They note which screens people open, where they pull data from and where they end up waiting.
• Narrowing the use case: They turn a broad request like "let's connect AI to the CRM" into a single task with a clear start and finish.
• Writing the integration themselves: They build the code that connects the model to the CRM, ERP, email or document archive, along with the permission settings and test scenarios.
• Testing with real data: They try the first version on the team's actual records with controlled access, not on sample data.
• Turning feedback into code: They fix users' objections and sticking points in a weekly iteration loop.
• Handing knowledge over to the team: They teach the company's own team how the system works, where it stops and how to monitor it.

None of these tasks is new on its own. What makes an FDE different is that one person does all of them.

How is an FDE different from a classic AI consultant?

Classic consulting usually ends with an analysis, a roadmap or a recommendation report. The report has value, but it leaves the implementation to another team, and a good share of the knowledge gets lost in that handover.

An FDE builds what they recommend. In the same Palantir post, Deltas make this point when they explain how their work differs from consulting: consultants typically produce a one-off analysis or recommendation, while an FDE builds a lasting solution together with the customer.

Putting the three models side by side makes the difference concrete:

Topic	Classic consulting	Software vendor	Forward Deployed Engineer
Output	Report and roadmap	Software delivered to a specification	A working workflow and transferred knowledge
Requirements	Gathered in interviews	Written at the start of the project	Clarified during real use
Code	Not written, or left to someone else	Written by the vendor	Written by the same person, next to the team
Changes	Require a new engagement	Become a change request	Part of the weekly loop

If you want a closer look at how a consultant differs from a solution partner, see our article on the difference between an AI solution partner and a software vendor.

Why do requirements surface in the field rather than in meetings?

The most common problem in AI projects is a demo that works well and then stumbles in the real system. The cause is rarely the model. It is usually the unwritten rules of the workflow.

When a sales team says "active customer", they may not mean the field in the CRM but the companies they have spoken to in the last three months. An operations team may trust the email from the warehouse lead rather than the order status in the ERP. Rules like these rarely come up in meetings, because people do not think of them as rules. Once the system is used with real data, they show up right away.

That is why an FDE stays close to the team. When a user says "this answer is wrong", the engineer sees the cause the same day and fixes it. Run through a specification and an approval chain, the same loop takes weeks.

What does an FDE do in the first 30 days?

The flow below is a made-up example for the sales support team of a mid-sized company. It is not a real client case. Its purpose is to make the day-to-day work of the role concrete.

Week 1, observation and selection. The engineer sits with two people on the team who prepare quotes. They see that each quote requires manually collecting customer details from the CRM, the price list from the ERP and old quotes from a shared folder. This task is chosen as the single use case: the assistant gathers information from these three sources and prepares a draft quote for the sales rep, but does not send it to the customer.

Week 2, read-only integration. The assistant connects to the CRM, the ERP and the folder with read-only access. The first drafts are tested on the team's real requests. At this stage the system cannot write to any record.

Week 3, the correction loop. The reps mark where the drafts go wrong. For example, it turns out that an old price list is still sitting in the folder and the assistant is using it. The engineer sets a rule for which source counts as the valid one.

Week 4, measurement and handover. The team tracks, using its own records, how many corrections each draft needs and how preparation time changes. The engineer shows the team how to monitor the system and puts together a shortlist of candidates for the next workflow.

In this example, success does not come down to the choice of model. It comes down to choosing the right task and correcting quickly with real data. We explain how to pick the first workflow in our 30-day AI pilot framework.

How can you tell your company needs a Forward Deployed Engineer?

Not every AI project needs an FDE. For setting up an off-the-shelf tool or a simple automation used by a single team, the role may be more than you need. It becomes valuable if several of these signs apply to you:

• You ran an AI trial and the demo worked well, but it never went into production.
• The data you want to use sits in more than one system, and those systems are not connected.
• Your workflow includes company-specific rules, and those rules are not written down.
• You have an in-house software team, but it has no time to spend on AI integration.
• The specifications you give vendors keep changing after the project starts.

If you are torn between building a team in-house and bringing in an outside partner, our article on whether to build an in-house team or work with an external partner is a good starting point for the decision.

What should you prepare before working with an FDE?

An FDE moves as fast as the access the company gives them. Settling these four points before you start shortens the first few weeks:

1. A single workflow: Pick a task with a clear start, finish and owner. The first workflow should be one that repeats often and can be undone if something goes wrong.
2. A business owner: Name someone on the team who can answer the engineer's questions on the same day.
3. An access and permission plan: Write down which systems get read-only access, which get draft access and which get approved write access. We walk through this step by step in our guide to connecting an AI assistant to existing systems.
4. A success measure: Define at the start, in measurable terms, what you expect to improve, and record where things stand today.

How does Binode approach this role?

At Binode we keep consulting and software development in the same team. The reason is that a large part of the requirements only surfaces once the team starts using the system with real data. We prefer not to move on to a second task until the first workflow works end to end.

If your company has an AI trial that never made it to production, we suggest picking one workflow and starting there. If you would like to talk it through, you can reach us through our contact page.

Frequently asked questions

Is a Forward Deployed Engineer the same as a solutions engineer?

Not exactly. A solutions engineer usually presents the product during the sales process and supports the setup. An FDE works inside the client's team after the sale, writes the code and takes the solution into production.

Do only large companies need an FDE?

No. The value of the role depends more on how complex the workflow is than on company size. A workflow that touches several systems and includes unwritten rules benefits from the FDE approach in a small company too.

How long does an FDE project take?

It depends on the workflow chosen and how quickly access to the systems is opened up. Work that starts with a single workflow and moves in weekly loops usually shows its first concrete result within a few weeks. It is more accurate to give a firm timeline after the first week of observation.

Does an FDE replace the company's own software team?

No. One of an FDE's goals is to leave the system in a state the company's own team can monitor and develop further. That is why the handover is part of the plan from day one.

---

Author: Abdullah Oğuz is the founder of Binode. He works on enterprise AI transformation, software integration around AI and B2B customer acquisition systems.

Cover photo: cottonbro studio / Pexels