Every large AI company is now hiring forward deployed engineers. AWS said in June 2026 that it is backing a new forward deployed engineering organisation with a $1bn investment. OpenAI and Anthropic both hire under the title. The Financial Times reported in November 2025 that monthly listings for the role had risen more than 800% between January and September that year, on Indeed’s data.
The model itself is older, and it is worth understanding properly before deciding whether it can work at any other scale. If you want the plain description of the role first, we wrote what a forward deployed engineer actually does.
What the model actually was
Forward deployed engineering was invented at Palantir in the mid 2000s. Bob McGrew, who ran product there while the strategy was being worked out and later became chief research officer at OpenAI, describes the founding insight in a way that sounds backwards until you sit with it.
Per-customer work is not services to be minimised. It is product discovery.
An engineer sits inside the customer, builds the thing that customer needs, and what they learn becomes the product. McGrew’s image for it is a gravel road and a paved superhighway. The engineer on site builds a gravel road to where the product needs to go for one customer. Somebody else’s job is to look at that road, work out how it generalises to the next five or ten customers, and build the paved version, which deliberately looks different because it has to serve customers further down the line.
The part that needs enterprise money
Here is the mechanism that makes the whole thing pay, and it is the part that does not travel downmarket.
McGrew calls it a metric inversion. In an ordinary product business you drive cost per customer down while contract size stays flat. In the FDE model you do the opposite. You drive contract size up, doing more and increasingly valuable work inside that account, and because the work is more valuable you can leave the amount of customisation per customer unchanged.
That is land-and-expand. You lose money at a new customer. Discovery makes the work cheaper over time. And once you are inside, the engineers find other problems, sometimes far more valuable than the one you were first hired for.
A small business has nothing to expand into. There is no larger problem to graduate to and a firm ceiling on what will ever be spent. So the variable the model relies on, contract size going up, is unavailable.
That is the real reason forward deployed engineering has been an enterprise practice. Not culture, not sophistication. Arithmetic.
What actually changed
The usual next sentence is that AI tooling makes engineers faster, so smaller projects become viable. That is true and it is not the interesting part.
The interesting part is which specific constraint moved.
Land-and-expand was never the point of the model. It was the financing structure for an expensive first build. The gravel road cost engineer-months, and something had to amortise that cost, so the account had to grow.
If the gravel road now takes days rather than months, you no longer need a growing contract to pay for it. The cost that land-and-expand existed to spread has itself shrunk to the point where it can be spread a different way.
Not across a deepening relationship with one client. Across a segment.
Segment repeatability
Palantir did not discover a law of nature. They solved a specific problem under a specific set of constraints, in a market of enormous contracts and classified environments, with the tooling of twenty years ago. The constraints produced the model. Change the constraints and a different shape fits.
One part of their thinking does carry over, and it is the part about markets rather than the part about money.
McGrew is clear that Palantir’s market was never one coherent market. National intelligence, law enforcement and the military produce projects that look similar and are not. A counter-proliferation workflow and a counterterrorism workflow are not the same problem. Within a segment, though, the familiar story applies: the next customer deploys with little customisation, until you hit a natural limit and enter a new segment, where you build again.
His summary of it is the line to keep: forward deployed engineering is how you do things that do not scale, scalably, once per segment.
Move that downmarket and the shape holds. A client is customer N of a segment, never a one-off. The first one is the gravel road. The next several are the paved road. The variable you drive up is not what any single client pays. It is how much of the previous build survives contact with the next one.
Which makes segment choice the whole strategy, rather than a marketing decision made afterwards.
The test that decides whether this is real
McGrew is asked directly why “it is just consulting with better marketing” is wrong. He refuses to bat it away. He says there is a real risk that it is right, and that in 2015 the two things people said about Palantir were that it was evil and that it was a consulting business that would never scale. They spent considerable time working out whether the second was a fair description.
The only test he offers is falsifiable, which is why it is the one worth adopting:
Is cost per unit of outcome delivered falling at this client over time?
Not whether it feels repeatable. Not whether you have called something a product. A measurable curve. Margins start thin or negative at a new client, then two things compound. Discovery makes the thing better suited to what that client does, so it needs less hands-on work. And you earn access to more valuable problems.
If that curve is flat, the business is consulting and the label is decoration. The number is invisible unless somebody records it deliberately from the first engagement, which is the practical instruction hiding inside the theory.
What nobody knows yet, including us
Two honest limits, and they apply to everyone in this market rather than to one end of it.
The curve takes a year to become visible. The defence against the consulting accusation rests on a trend that cannot be seen early. Almost nobody running this model in 2025 or 2026 has run it long enough to know which side of the line they are on. That includes the enterprise firms, and it includes anyone writing about it.
The generalisation step needs more than one customer. McGrew’s method for deciding what should be generalised is to put the same problem from two or three customers side by side, at which point the argument about general versus specific dissolves. That works at any scale, and it does not work at all with a single client. A method derived from one client is over-fitted to that client, and it will not announce itself. The discipline is to refuse to generalise until there is something to generalise from.
This is a new industry, not a smaller version of an old one
The temptation is to treat the enterprise version as the real thing and everything else as a scaled-down imitation. That gets the situation backwards.
With conventional software you are usually replacing something. One way of paying bills becomes another way of paying bills. Everyone understands the category, so there is little discovery to do and you grow by displacing the incumbent.
With AI systems there is no incumbent product. Nobody is switching from the thing they had before, because they did not have one. That leaves an enormous amount of discovery to do, and it can only be done from inside the business, watching what actually happens rather than what the process document claims happens.
McGrew goes further and suggests that building AI agents is probably several different things nobody has separated yet, and that in five years we may conclude agents were never one category at all.
Take that seriously and the conclusion follows. If the category has not settled, nobody currently holds the answer, and being early to the old version confers less than it appears to. The firms that defined forward deployed engineering defined it for a market of nine-figure contracts. What it means for a business with forty staff is an open question, and it will be answered from both ends.
What this means if you are the business
Practically, it changes what you should expect from a supplier.
The engagement should start with somebody watching how the work is actually done, not a proposal written from a briefing call. That is closer to what a fractional CTO does than to a software quote. The first build should be small enough to finish, with the rest named and parked rather than absorbed. And the supplier should be able to tell you which segment you are in and who came before you, because if you are a one-off, you are paying for the gravel road with none of the benefit of the paved one.
The last question is the sharpest, and it works in both directions. Ask whether the cost of delivering your outcomes is falling. If the answer is a story rather than a number, you are buying consulting, which is a perfectly reasonable thing to buy as long as everyone is honest about the label.
Frequently asked questions
What is the forward deployed engineer model?
An engineer embedded inside a customer’s business, building working systems in the customer’s own environment. The founding insight, from Palantir in the mid 2000s, is that this per-customer work is product discovery rather than services to be minimised: what the engineer learns becomes the product.
Why has it only worked for large companies?
Because it runs on land-and-expand. You lose money on the first engagement and recover it as the contract grows inside the account. Small businesses have no larger problem to graduate to and a hard ceiling on spend, so the mechanism the model depends on is not available.
What replaces land-and-expand at smaller scale?
Segment repeatability. Instead of one client’s contract growing, the same engagement shape is repeated across similar businesses, so more of each build survives into the next. This is Palantir’s own segment argument applied downmarket rather than a new idea.
How can you tell this apart from consulting?
One test, and it is measurable: is the cost per unit of outcome delivered falling at a given client over time? A flat curve means consulting. The number has to be recorded deliberately from the first engagement, because it is invisible otherwise.
Is this proven at small business scale?
No. The curve that distinguishes the model from consulting takes a year or more to become visible, so almost nobody adopting it recently has run it long enough to know. Anyone claiming otherwise is describing an intention rather than a result.
Flux Dynamics is a fractional CTO who builds. We work inside the business rather than presenting to it, and we hold ourselves to the test above: whether the cost of delivering your outcomes falls over time. Tell us what you are considering.