Forward Deployed Engineer: what the label actually means

The Forward Deployed Engineer is one of the most expensive software engineering roles in the world. It is also, currently, the most overused phrase in AI sales decks. The gap between those two facts is where most Australian mid-market AI conversations are about to go wrong, so it is worth understanding what the role actually is, where it came from, and how to tell the real version from the marketing one.

What a Forward Deployed Engineer actually is

The role was invented by Palantir more than a decade ago to solve a specific problem in US defence and intelligence work. The customer had data trapped across dozens of incompatible systems, no clean way to model the world the data described, and no tolerance for software that needed users to change their workflow to fit the product. Palantir’s answer was to embed full-stack software engineers inside the customer environment for months at a time, building production software on top of the Foundry and Gotham platforms until the system worked under real operational conditions.

These were not consultants. They were not pre-sales engineers. They were senior software developers, often as strong as anyone at Google or Meta, who happened to do their work in someone else’s office. They wrote code that survived the engagement. They owned the data plumbing, the ontology, the workflows, and the production deployment. Their loop was tight: build something that worked for one customer, observe what generalised across customers, and feed those generalisations back into the core platform. That loop is what made the model genuinely valuable, and it is the part that most of the imitators leave out.

Why the model worked for Palantir

Three conditions had to hold for the original Forward Deployed Engineer model to make economic sense, and all three held in Palantir’s customer base.

The first was that the engineering was genuinely the binding constraint. The customer’s problem could not be solved by configuring an off-the-shelf product. It needed software written, by people who could write software at a high level, against data that was hostile and systems that were old. The second was that the customer could absorb the cost. A genuine Forward Deployed Engineer is one of the most expensive billable resources in the industry, and the model only works when the customer is large enough to justify months of senior engineering effort against a single problem. The third was that the platform existed to absorb the lessons. Every FDE engagement at Palantir fed insights back into Foundry and Gotham. Without that, the model degenerates into bespoke services with no compounding value.

Defence agencies, global financial institutions and Fortune 500 enterprises met all three conditions. A 60-person professional services firm in Subiaco meets none of them.

Why the label has been stolen

Palantir’s commercial success made the role aspirational. The stock returned more than 600% over five years, the company’s enterprise revenue grew on the back of a model that looked more like consulting than software, and every AI vendor with a sales motion looked at that and wanted some of it. The label has since travelled.

It now sits on job descriptions at almost every major AI lab. The role descriptions vary widely. Some are genuinely engineering-led. Others are blended roles that bundle workflow design, customer success and solutions architecture under an engineering title. A few are simply senior pre-sales engineers with the words “Forward Deployed” attached for prestige. The label has become a piece of marketing wallpaper that signals seriousness without committing to any particular shape of work.

For a buyer, the practical problem is that “we will send you a Forward Deployed Engineer” no longer tells you what you are actually buying. You could be buying a senior software developer who will build production code inside your environment for six months. You could be buying a solutions architect who will scope a workshop and hand you back a slide deck. You could be buying an integration consultant with a fashionable title. The price tag is often the same.

How to tell a real engagement from a relabelled pitch

Four discriminators separate a genuine Forward Deployed Engineer engagement from a relabelled sales pitch, and they are the questions worth putting to any vendor offering one.

Who does the engineer report to. A real FDE reports into an engineering organisation, not into sales. If the answer is sales or customer success, you are buying a solutions engineer with a different title. There is nothing wrong with a solutions engineer, but you should know that is what you are buying.

What the deliverable actually is. A real FDE engagement produces production software that survives the engagement and continues running after the engineer has left. Configurations, dashboards, prompt libraries, workshop outputs and Notion pages do not meet that bar. If the deliverable is anything other than code that runs in your environment and serves your users, you are not buying engineering, regardless of the label.

Where the work generalises back to. The original Palantir model worked because every engagement fed lessons back into the core platform. Ask the vendor what generalises from your engagement back into their product, and how. If the answer is nothing, the engagement is bespoke services and should be priced as such.

What the engagement looks like at month six. A real FDE engagement is measured in months, not weeks. The engineer is still in your environment, still committing code, still owning a part of the production system. If the vendor’s plan is to be out the door in eight weeks with a finished workshop, the model is consulting, not engineering.

None of these discriminators are about the label. They are about the shape of the work underneath it.

What Australian mid-market should actually be buying

For most Australian mid-market AI projects, the Forward Deployed Engineer model is not the right shape of engagement, even when it is on offer. The reason is not that the model is bad. It is that the binding constraint in a typical Australian mid-market AI deployment is not engineering.

The technology is no longer the hard part. Claude Code, OpenAI Codex, Microsoft Copilot Cowork and Google’s enterprise agents have made it possible for a competent analyst to ship a working automation in an afternoon. Integration plumbing into legacy systems still requires real engineering, and that work is not going away. But it is no longer the first thing that breaks. What breaks first is everything that surrounds the engineering: who owns the agent when it makes a wrong call, how the workflow actually changes when the agent is dropped into it, whether the staff inheriting it have the training and the permission to use it well, whether the audit trail will survive a regulator. Those are people, process and accountability problems, not engineering problems.

For that work, the role that needs to be embedded is an operator, not an engineer. An operator owns the governance, redesigns the workflow before the agent gets dropped in, manages the vendor stack, keeps the audit trail Australian regulators are going to want, and commissions engineering work only where it genuinely earns its place. That role is closer to a virtual CIO with an AI specialisation than to a Palantir FDE, and it sits at the centre of what we mean by managed AI and AI governance as services. We are not going to pretend that is a neutral observation. It is the shape of work we run. The point of laying out the discriminators above is to give you a way to evaluate any vendor pitch you take, including ours.

What you should do now

Apply the four discriminators to any FDE pitch you receive. Who does the engineer report to, what is the deliverable, where does the work generalise back to, and what does month six look like. If the vendor cannot answer those questions clearly, the label is doing more work than the engagement is.

Be honest about your binding constraint. If your problem is genuinely hard engineering against hostile data and legacy systems, a real Forward Deployed Engineer might be the right answer and you should probably be talking to Anthropic, OpenAI, or Palantir directly. If your problem is closer to governance, workflow design, training and accountability, a different shape of engagement will move the needle further and cost less.

Audit what is already running in your business. Most Australian mid-market businesses have more AI in production than their leadership realises, and almost none of it is governed. A free AI readiness review will tell you where you actually stand. The full Epic IT approach is set out on our AI services page.