What is a forward-deployed engineer, and why does your AI build need one?

The short answer

A forward-deployed engineer is a senior software engineer who works inside a client's problem rather than at arm's length from it. Instead of receiving a specification and returning code, the FDE sits in the workshops, talks to the people who do the work, watches how data actually moves, and builds the system while learning the business. The term was popularised by Palantir, whose engineers are sent to customers to make the platform useful in situ, but the model is older than the name: it is how the best internal development teams have always worked.

The important word is embedded, not on site. A forward-deployed engineer can be fully remote. What matters is depth of engagement with the subject-matter experts, the right to ask awkward questions, and a short loop between hearing a requirement and showing a working screen.

How it differs from a consultant, a contractor or an agency

A management consultant produces recommendations and leaves implementation to others. A contractor implements what is in the ticket. An agency takes a brief, disappears for a quarter, and returns with a build that matches the brief and not the business. The forward-deployed engineer does the discovery and the build as one continuous activity, so the understanding gained in week one shapes the code in week eight, and the surprises in week eight are fed back into the design the same day.

The practical consequence is that there is no hand-off. The person who heard the underwriter explain why the quota share needs its own screen is the person who builds that screen. Hand-offs are where requirements die, and the FDE model removes them.

Why AI builds in particular need this

AI-powered systems fail in a specific way: the demo works and the production system does not, because real data is messier, real users phrase things differently, and the edge cases that matter were never in the brief. An engineer embedded with the business sees those edge cases in the first week and designs for them. One working from a specification meets them at go-live.

There is a second reason. AI-accelerated engineering has made the build itself fast; a system that took a year can be built in a quarter. When building is that quick, understanding the problem becomes the bottleneck, and the forward-deployed model is the fastest way to understand a problem.

What a forward-deployed engagement looks like

At Treefrog it runs in four stages. A remote workshop in which your team describes the system they would have if nobody told them no. A Living Requirements Document: a clickable prototype of that system, in users' hands within days, that captures requirements by letting people use them. A proof of concept for the AI pieces, run on your real data and judged on measured results. Then the production build, with working software demonstrated weekly, on your stack, ours, Palantir Foundry or Databricks. The whole arc is typically a quarter.

Throughout, the engineer is senior: at Treefrog that means at least ten years' experience and, for (re)insurance work, people who already know what a layer, a bordereau and a PML are.

How to hire one

Ask three questions. Who exactly will do the work, and how long have they been doing it? Will the same person run the discovery and the build? And what will I be able to click after two weeks? If the answers are a named senior engineer, yes, and a working prototype, you have found a forward-deployed engineer. If the answers are a team to be assigned, a hand-off to delivery, and a requirements document, you have found an agency with a new label.

Frequently asked