Palantir gave the industry a role and the industry adopted it without examining it too closely. The forward deployed engineer: technical, embedded with the customer, building in the field rather than against a product roadmap. Every serious AI company now has some version of it and enterprises have started asking for it by name in RFPs.
The idea is sound. What most enterprises are actually receiving is not.
What tends to arrive is a competent engineer, usually young, often genuinely good at the technical part, who runs workshops, asks people to describe their work, documents the workflow and then builds automation that matches the description. Everyone is pleased with the responsiveness. The engineer is helpful and quick and pleasant to have around. Six months later there is a working system that does the existing process slightly faster.
That's digitisation. The nineties did it with workflow software and the twenty tens did it with RPA, and both times the returns were real and modest and nothing like what had been promised. An engineer who doesn't understand the domain is a very capable pair of hands with no opinion about what should be built, which means the customer's existing process becomes the specification by default. And the existing process is usually the problem.
The step that produces the actual return is the one where somebody looks at how the work is done and says it shouldn't be done that way. This step should not exist. This approval is guarding against a risk that stopped being real when the underlying system was replaced. These two teams are both checking the same thing because neither trusts the other's check, and the answer is not to automate both checks. This decision is being made three levels too high, which is why it's slow, and if you move it down you don't need any AI at all.
Nobody without domain authority can say those things. Sometimes that's because they lack the insight. Mostly it's because they lack the standing. When a 28 year old engineer tells a head of operations that a control introduced after a regulatory incident is unnecessary, the conversation ends right there, and frankly it should. When somebody who ran a comparable function for fifteen years says the same thing, it's a different conversation entirely. They can be argued with on the merits. They know which controls are load bearing and, more usefully, which ones are being defended out of memory rather than necessity.
So the role enterprises need isn't a forward deployed engineer. It's a forward deployed executive, meaning somebody who has done the work, who can walk into a department and understand within a week what is actually happening rather than what's written down, and who has the credibility to propose that a large part of it stop. Then the engineer builds it. In that order, and the order is the whole point.
The industry sells the other thing mostly because engineers are available and operators are not. A company can hire twelve forward deployed engineers out of the same pipeline it uses for product engineering. It cannot hire twelve people who have each run a claims department, and if it could, the salary and the seniority would break the delivery model. A genuinely domain led engagement costs enough to deliver that it doesn't scale the way venture funding needs it to. So the role got quietly redefined into something staffable, and "forward deployed" now mostly signals that the engineer will get on a plane.
There's a second reason, and it's less comfortable. Challenging the customer's process is bad for a vendor relationship in the short term. Telling a head of finance that a third of their reconciliation work exists because of a data quality problem three systems upstream is correct, useful and not what they asked for. Automating what's in front of you and reporting a successful deployment is much easier, and it's what most engagements are structured to reward.
The practical version of all this, if you're buying: when a firm proposes an embedded team, ask who on it has actually done the job you're automating, and for how long — not adjacent to it, not consulting to that industry for a few years, but done it. If the answer is nobody, then what you're buying is construction, which is a perfectly legitimate thing to buy, and you should price it as construction and supply the domain judgement yourself from inside your own organisation. Because if you don't, nobody in the room has it, and everyone will be too polite to say so.
That's the fifth pattern.