In short: Forward-deployed engineer postings rose more than tenfold in a year. Enterprises are paying expensive people to carry the context their software cannot hold. That is the clearest market price for the missing layer, and the clearest specification of what it should contain.
Key points
- From January to August 2026, forward-deployed engineer postings rose more than 1,000% year on year.
- Most of that work is context: data quirks, conflicting definitions, exceptions, past attempts and decision rights.
- One estimate put 2025 model API spend at about $12.5 billion versus about $1.5 billion on the context layer.
- Make a structured, client-owned context record a named deliverable in deployment contracts.
- Treat context that exists only in one engineer's head as an operational risk.
From January to August 2026, job postings for forward-deployed engineers rose more than 1,000% compared with the same period a year earlier, at a median advertised salary above $188,000. The largest systems integrators now employ tens of thousands of AI and data professionals.
Read that as a price. Organisations are paying, at scale and at high rates, for people whose job is to understand how a particular client's world works and make AI function inside it.
What these people actually carry
Watch what a forward-deployed engineer spends their time on, and very little of it is model work. It is context:
- how this client's data is actually shaped, as opposed to how the documentation says it is;
- which definitions differ between teams, and which one is authoritative;
- which exceptions matter and which are noise;
- what was tried before, and why it did not stick;
- who decides what, and who must be consulted.
That list is a specification. It is precisely what a durable organisational record would hold, if one existed. The engineer is, functionally, a walking judgment layer.
The spend split says the same
On one bottom-up estimate, enterprises spent about $12.5 billion on model APIs in 2025, and about $1.5 billion on the retrieval, storage and orchestration layer that connects those models to their own context. The layer that holds context is underfunded relative to the models it feeds, and labour is filling the gap.
The warning inside the opportunity
An influential venture essay this year warned that many "Palantir for X" startups risk becoming services businesses with a platform attached: high revenue, low margins, growth limited by hiring. Nobody has yet shown a product that replaces deployment labour at software margins.
The practical path between those two facts is not to eliminate the people. It is to make sure their context does not leave with them.
Convert context into a deliverable
If you buy forward-deployed work, make the context record a contractual deliverable: a documented set of definitions, exceptions, data quirks, decisions and their reasons, owned by you and maintained throughout the engagement. Measure the engagement partly by what it leaves behind.
If you sell it, measure how much faster your second deployment in a similar client is than your first, and why. If the answer is "because the same engineer remembered", the knowledge is still in a head, not a product.
In practice
- Add a client-owned context record to every integration or deployment contract as a named deliverable.
- Structure it: definitions, exceptions, data quirks, decisions with reasons, open questions.
- Track time to productive use for each new deployment in a familiar segment.
- Treat any context that exists only in one engineer's head as an operational risk.
What would prove this wrong. Forward-deployed demand falling sharply as products mature, without any durable context record being built. Then the labour was transitional integration, not a missing layer.
Common questions
Why are forward-deployed engineer jobs growing?
Organisations are paying people to understand how a client's world works and make AI function inside it. Postings rose more than 1,000% from January to August 2026 versus a year earlier.
What does a forward-deployed engineer actually do?
Mostly carry context: how the client's data is really shaped, which definitions differ between teams, which exceptions matter, what was tried before, and who decides what.
How do I keep knowledge when a consultant or deployment engineer leaves?
Make a client-owned context record a contractual deliverable, structured as definitions, exceptions, data quirks, decisions with reasons and open questions, maintained throughout the engagement.
How can vendors tell whether deployment knowledge is in the product or in people?
Measure how much faster the second deployment in a similar client is than the first. If it is faster because the same engineer remembered, the knowledge is still in a head.