rico.wtf

What is a forward-deployed AI engineer?

Last updated 15 October 2026.

A forward-deployed AI engineer is a software engineer who works inside a customer's systems until an AI system is running there and people actually use it. The job sits between writing code and changing how a team works. Most of it happens in the gap between a prototype that works on sample data and a system a team relies on every day.

Where the title comes from

Palantir popularised it. Wikipedia says the company used the title for staff by 2009. The IIT overview puts the core distinction well: a regular developer builds one capability for many customers, while a forward-deployed engineer works on one customer across many capabilities.

In 2026 the title spread fast. Wikipedia lists Anthropic, OpenAI, Amazon Web Services, Microsoft and Google Cloud among companies that announced divisions built around the role this year. Andreessen Horowitz has called the title "title arbitrage": a new name for solutions and integration roles. Both things are true. The work is real, and some of the title is relabelling, so judge a posting by what it asks you to own, not by its title.

What the job involves

Alexey Grigorev read 113 AI forward-deployed engineering job postings from January to July 2026 and counted how often each responsibility appears:

  • Direct client engagement: 90% of postings
  • Building and deploying production systems: 87%
  • System, API and data integration: 62%
  • Scoping, discovery and requirements gathering: 51%
  • Testing, evaluation and monitoring: 41%
  • Channelling customer feedback back into the product roadmap: 39%
  • Prototypes, demos and proofs of concept: 25%
  • Travel or on-site presence: 10%

Read that list as what the employer will hold you to. It says less about the day-to-day, and nothing about what the job pays.

The list leaves out what does not show up in a posting. From where I sit, the job also involves:

  • Understanding systems. Knowing how the existing systems work, how to build new ones, and how they fit together.
  • Security and privacy. The system has to pass review and handle customer data the way the customer expects.
  • The people side. People may be reluctant to tell you exactly what they do. Make it clear you want to give them more time for the work they enjoy and are good at.
  • A healthy dose of paranoia. Keep asking what could go wrong, at all times of the day, and build the defences in before it does.

How it differs from nearby roles

This is one common way to split the roles, not an industry standard.

  • Solutions engineer: supports the sale. Runs demos and proofs of concept before a contract, and usually hands over when it closes.
  • Solutions architect or consultant: designs or advises on the change. May never build or run the system.
  • Product software engineer: builds to a specification that serves many customers at once.
  • Forward-deployed AI engineer: builds and owns the production system inside the customer's environment, and stays until people use it.

A quick test: after the contract is signed, who is still accountable for the system working? If the answer is nobody, you are looking at a sales role with a new title. fde.academy's guide lists the warning signs: demos valued above production code, no ownership after launch, and commission or quota pay.

When a company needs one

Usually when an AI system has to work on the company's own data, tools and approvals, and the team lacks the engineering time or depth to do that integration. A prototype can run on clean sample data. The real version has to reach internal systems, pass a security review, handle the edge cases nobody wrote down, and change how people spend their day.

A company that wants a demo, a strategy deck or a SaaS tool it can configure itself does not need one. Those are different jobs, and a good vendor will say so.

How I work in this role

At Unblock Labs I manage fleets of AI agents, aka klankers. I deploy them into real workflows and build the automation around them. Here is how that tends to go, with receipts from my public work.

  1. Decide what done means before the agent starts. Most of the job is here. A vague brief gets you a confident wrong answer.
  2. Let the agents write, then review like it matters. In dstar, there are over a hundred commits and most of them are agent co-authored. Generation is cheap. The review is where the risk sits, and the klanker log records the times it went wrong too.
  3. Work against the real thing, not a sample. The Tiptap rich-text plugin for Bubble is used by around 2,500 apps. Every Bubble plugin I maintain is built with Pled, the CLI I wrote to develop them.
  4. Turn recurring problems into tooling. Companion and BeanStalk started when I noticed the same spreadsheet-and-process problem kept coming back. When the same problem shows up twice, I try to build it into a tool rather than solve it by hand again.

Common questions

Is a forward-deployed AI engineer a sales job?

It should not be. The role owns production code and the result after launch. Some postings put the title on solutions-engineering work, so check whether the job asks you to ship and run something, or only to demo it.

Do you have to travel?

It depends. Only about 10% of the postings in Alexey Grigorev's sample mention travel or on-site presence. Vendor postings run higher: Digital Applied's summary gives Palantir 25–50% and OpenAI up to 50%.

How much experience does it take?

According to FDE Academy's guide to postings, most ask for three to five years or more, tied to production systems and customer-facing work rather than general tenure. Some companies hire earlier-career engineers who can show deployment experience. This is one guide's reading of the postings, not a survey.

Is it the same as an AI engineer?

The titles overlap, and some companies use them interchangeably. My working distinction: an AI engineer's work is usually inside one product. A forward-deployed engineer's work is inside the customer's systems, and it is judged by whether the customer's team uses it.

Sources

The day-to-day is easier to judge in the open. See the klanker log and the projects page.