What Is a Forward Deployed Engineer, and Why Is Every AI Company Hiring One?

A forward deployed engineer, or FDE, is a software engineer who works inside the customer's team instead of behind a statement of work. They join the stand-up, take tickets from the customer's backlog, commit to the customer's repository and stay with the work until it runs in production.

The title started at Palantir in the mid 2000s. The company found that shipping software to intelligence and defence customers did not get the software used, so it started shipping engineers instead. The name is borrowed from military language: forward deployed means working at the point of action rather than from a base a long way behind it.

Twenty years later the title is on job boards at OpenAI, Anthropic, Databricks and a long list of AI companies. The reason is simple. AI models are now good enough that the hard part of an AI project is no longer the model. It is everything around the model: the data it reads, the systems it writes to, the policy it has to follow, and the people whose job it changes. None of that can be specified from the outside.

What the role actually involves

Strip away the branding and an FDE does four things.

• Learns the customer's work. Not the org chart, the actual process: who checks what, which spreadsheet is the real source of truth, where the queue backs up.
• Builds in the customer's environment. Their tenant, their repositories, their identity model, their release process.
• Ships in short cycles. Something usable lands every sprint, so the customer can react to working software rather than a slide about working software.
• Owns the result to production, including the unglamorous parts: evaluation, monitoring, permissions, handover and training.

The last point is what separates the role from a normal contractor. A contractor closes tickets. An FDE is answerable for whether the thing works in the customer's hands.

Why AI pushed the model into the mainstream

A traditional software project can be specified. You can describe a form, a workflow and a report in enough detail that a team somewhere else can build them.

An agent cannot be specified that way, because nobody knows the answer at the start. What should the agent do when the submission is missing an attachment? Which of the four policy documents wins when they disagree? How wrong can the summary be before a person has to read the original? You discover those answers by building a version, watching people use it, and changing it. That loop is short, and it only works when the engineer is close enough to see it.

There is a second reason. Most useful AI work touches data an organisation will not send anywhere. Building inside the customer's own tenant solves that, and it puts the engineer where the data already lives.

What a forward deployed team is not

Three things get sold under the name that are not it.

• Labour hire with a new label. If you manage the person, set their tasks and carry the delivery risk, you hired a contractor. That is a legitimate way to buy, but it is not this.
• A fixed-scope project delivered from a distance. Useful when the requirements are known. It is the wrong shape when the requirements emerge from use.
• A pilot factory. Demos are easy now. Production is not. If the engagement ends at a proof of concept, the hard half was never attempted.

Questions to ask any provider

1. Who exactly is on the team, and do the same people stay across sprints?
2. Do they work in our tenant and our repositories, under our security model?
3. What ships at the end of the first two weeks?
4. Who is on the hook when an agent gives a wrong answer in production?
5. Where do the engineers sit, and who employs them?
6. What happens to the code, the prompts and the evaluation set when the engagement ends?

The last question matters more than it looks. If the working parts of your AI system live in someone else's platform, you have rented a capability rather than built one.

Frequently asked questions

What does a forward deployed engineer do?

A forward deployed engineer works inside a customer's team and environment: learning the real process, building in the customer's own tenant and repositories, shipping working software in short cycles, and staying with the work until it runs in production.

Where does the term forward deployed engineer come from?

From Palantir in the mid 2000s. The company sent engineers into customer sites to build workflows directly, instead of shipping software and hoping it was adopted. The phrase is borrowed from military language and means working at the point of action.

Is a forward deployed engineer the same as a contractor?

No. A contractor is usually managed by the customer and delivers tasks. A forward deployed team brings its own lead, quality practice and delivery method, and is answerable for whether the work runs in production.

Why is the role common in AI projects?

Because an AI feature cannot be fully specified in advance. The rules for what an agent should do in edge cases come out of watching people use an early version. That loop needs an engineer close to the work.

Our Forward Deployed AI Engineering page sets out how our teams work, and what you get at the end of each sprint.