Definition
A forward deployed engineer (FDE) is a software engineer who works inside a client’s teams to turn a loosely defined problem into a system that runs in production.
They don’t advise from the outside. They sit close to the business teams, learn how they work, build the solution on their data and tools, deploy it, fix it, and stay until it’s actually being used.
Where the role comes from
The term comes from military language. Palantir adopted it in the late 2000s: its first clients, government agencies with highly sensitive and unusual data environments, couldn’t be served remotely. Engineers had to be on site.
Starting in 2025, the major AI companies adopted the model at scale. OpenAI, Anthropic, and Google built FDE teams to support their customers. The reason is simple: in a company, the hard part isn’t the AI model, it’s deploying it into existing processes, data, and tools.
How it differs
From a consultant. A consultant recommends and hands over a deliverable. An FDE writes the code that runs in production, and is judged on what happens after deployment.
From a solutions architect. An architect designs, often on anonymized data, then hands off. An FDE works on real data and accepts the ambiguity of the starting problem.
From a standard product engineer. A product engineer builds one capability for many customers. An FDE brings many capabilities to one customer, and feeds back what they learn.
Why the model works where AI projects fail
Most failed AI projects share the same flaws: a tool picked before the problem, a pilot that never reaches production, business teams kept on the sidelines, no measurement of results.
The FDE model fixes each of them:
- the problem comes from the field, not from a feature catalog
- the solution is built on real data, flaws and all
- users are involved from the first prototype
- success is measured by usage, not by the demo
What a small or mid-sized company can take from it
A small company won’t hire a team of FDEs. But it can apply the method:
- Start from the real work. Watch the teams, list repetitive tasks and pain points, before talking tools.
- Build small, on real data. A prototype on your data, tested by the people who will use it, with a success criterion set in advance.
- Stop what doesn’t work, fast. A POC that fails in two weeks costs less than a project that fails in six months.
- Actually deploy. Go-live, training, usage rules, measurement.
- Hand over. Internal champions who can evolve what was built.
AI is still new. Few companies have deployed it successfully in a real transformation, and no method applies as is. So the adoption plan has to be built with the teams, not imposed on them.
How it connects to the CTO role
In a small or mid-sized company, the CTO is often the only person who can see all of the company’s systems. So it falls to the CTO to drive the AI transformation, in engineering and every other team, with an FDE’s mindset: on site, hands in the work, judged on results.
That’s Monolithic Lab’s approach, as a fractional CTO, an interim CTO, or through a fixed-price project: AI exploration, POC, MVP.