Why Companies Need Forward Deployed Engineers, Not More AI Advice
Most companies do not have an AI strategy problem. They have a deployment problem.
The advice layer is crowded. Consultants, frameworks, maturity models, readiness assessments, webinars, a board deck with a roadmap on slide 14. Very little of it survives contact with a customer’s actual data.
A forward deployed engineer is the answer a growing number of companies have landed on. Not another advisor, but an engineer who sits inside the problem and ships something that works.
This article explains what the role is, what the failure data actually says, and why the bottleneck is not knowing what to do.
What Is a Forward Deployed Engineer?
Short answer: an engineer who embeds with a customer and builds production software inside the customer’s environment, instead of building features from the vendor’s office.
The job has three parts:
- Engineering. Integrations, data pipelines and AI systems running on the customer’s real data.
- Discovery. Working with the people who will use the thing to find the problem worth solving.
- Feedback. Turning what breaks in the field into changes in the core product.
Marty Cagan of the Silicon Valley Product Group defines them as “technical people that embed with the target customer in order to deeply understand their environment, their problems, and what’s truly required to solve those problems.”
The title started at Palantir, where the internal team is still called Delta. Their framing of the split is the cleanest one available. A product engineer works on “one capability, many customers”. A deployed engineer works on “one customer, many capabilities”.
The Advice Is Not the Bottleneck
Short answer: enterprises are not failing at AI because nobody told them what to do. They are failing at the last mile, between a working pilot and a system that changes a number on the P&L.
The most-cited evidence is MIT’s Project NANDA report, The GenAI Divide: State of AI in Business 2025, published July 2025 by Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari.
Its headline finding is blunt. Despite “$30 to 40 billion in enterprise investment into GenAI”, the report found 95% of organisations were getting zero return.
One caveat, because this number gets abused. The report covers generative AI only, and its own notes call the figures “directionally accurate” from interviews rather than audited reporting. Treat 95% as a strong signal, not a verdict.
The diagnosis matters more than the number:
“The core barrier to scaling is not infrastructure, regulation, or talent. It is learning. Most GenAI systems do not retain feedback, adapt to context, or improve over time.”
One interviewee, a manufacturing COO, put it more plainly than any analyst could:
“The hype on LinkedIn says everything has changed, but in our operations, nothing fundamental has shifted. We’re processing some contracts faster, but that’s all that has changed.”
That gap is not an advice gap. Nobody fixes brittle workflows with a maturity model.
If you want to be one of the people who closes that gap rather than diagnoses it, the Advanced Certificate in AI Forward Deployed Engineering with IIT Delhi is built for exactly that: RAG architecture, agentic systems, evaluation and production deployment, over six months of live online sessions with five projects.
The Independent Forecasts Say the Same Thing
Short answer: two Gartner forecasts, made a year apart, blame the same causes MIT found. None of them is model quality.
Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, rising costs and unclear business value.
It followed with a second forecast: over 40% of agentic AI projects will be cancelled by the end of 2027, for much the same reasons.
Read the three findings together and the conclusion is uncomfortable. The industry is not short of direction. It is short of people who will do the integration work in the customer’s environment.
Where Pilots Actually Break
Short answer: almost never on model quality. They break on data access, workflow fit and ownership after launch.
MIT’s deployment funnel is the clearest illustration. Sixty percent of organisations evaluated enterprise-grade AI tools, 20% reached a pilot, and just 5% reached production.
| Where It Breaks | What It Looks Like |
| Data access | The demo ran on a clean extract. Production data is messy, permissioned and owned by someone with no reason to help |
| Workflow fit | The tool sits beside the job instead of inside it, so people keep using the old process |
| No memory | The system does not retain feedback or adapt, so it never gets better than day one |
| No owner | It launches, the vendor leaves, and nobody on the customer side can maintain or explain it |
| Wrong target | Budget goes to visible functions while the higher-return back-office work is left alone |
Each of those is an engineering and ownership failure. None of them is solved by a better strategy document.
What a Forward Deployed Engineer Does Differently
Short answer: they work inside the customer’s constraints from day one, and they are accountable for the outcome rather than the recommendation.
The difference from consulting is structural, not attitudinal. A consultant “generally creates a one-time analysis, recommendation, or solution”, as Palantir’s engineering blog puts it. A deployed engineer builds a long-term system alongside the customer and keeps contributing to the core product.
Four things change when the seat exists:
- The work starts in production reality. Real data, real security review, real permissions.
- Discovery happens with operators. Not only with the executive who signed the contract.
- Delivery is owned end to end. Palantir’s posting asks engineers to “own the end-to-end execution and implementation of high-stakes projects”.
- Field lessons become product. Anthropic asks engineers to “identify and codify repeatable deployment patterns and contribute insights back to our Product and Engineering teams”.
The clearest published example comes from The Pragmatic Engineer. An OpenAI forward deployed engineer went to Iowa to work with John Deere on scaling personalised guidance for farmers, previously handled by manual phone calls.
The deadline was the growing season, which does not move. They shipped in time, and the work improved OpenAI’s own API.
No advisory engagement produces that. Someone had to be in Iowa.
Why Companies Are Suddenly Funding This
Short answer: because the economics of the last mile finally became visible, and the biggest vendors moved first.
AWS announced a $1 billion investment in a Forward Deployed Engineering organisation that will “embed thousands of experts with customers to co-develop and deploy agentic AI solutions in days.”
That is a vendor deciding that shipping the customer’s outcome is cheaper than watching pilots die.
MIT found the same pattern from the buyer’s side: external partnerships reached deployment at roughly twice the rate of internal builds. Companies that brought in people who deploy for a living got further than companies that tried to figure it out alone.
For engineers, that shift is the whole story. Demand is moving toward people who can build and talk to customers in the same week.
What This Means If You Are an Engineer
Short answer: the skill that is scarce is not model training. It is making a model survive a real customer’s data, security review and staff.
The hiring bar is wide, which surprises people:
| Employer | Experience Asked For |
| Palantir | 1+ years post-college, travel up to 25% |
| Anthropic | 4+ years in a technical customer-facing role, travel around 25% |
| Indian AI product firms | Varies, often 4+ years, frequently titled deployment or solutions engineer |
In India the seat is real and growing. Sarvam AI in Bengaluru was hiring for it on the date this was written, and many Indian companies list the same work under a different title.
If you want the detail, this breakdown of the skills employers screen for covers what postings test, and this look at the day-to-day and pay covers what the week looks like. For preparation, these role-specific interview questions show how the customer-facing half gets tested, and this step-by-step roadmap sets out the path in order.
The honest version: this is not an escape from engineering, and it is not a sales job with a technical badge. It is engineering with a customer in the room, and it suits people who find “shipped but unused” more frustrating than a messy codebase.
The gap the failure data describes is a production-AI gap. That is the half of the job most engineers have never had to build deliberately, and it is what the IIT Delhi AI engineering programme is structured around, from retrieval and agents through evaluation, observability, cost, security and deployment.
Frequently Asked Questions
Are forward deployed engineers just consultants with a new title?
No, though the confusion is fair. The structural difference is the product feedback loop. Consultants deliver a recommendation and leave. Forward deployed engineers ship production code and push what they learn back into the core product.
Does hiring forward deployed engineers turn a product company into a services business?
It can, and that is the real risk. The protection is generalisation: each deployment must produce reusable platform capability, not another bespoke system. Palantir built Foundry out of exactly that accumulated field learning.
Do small companies need forward deployed engineers, or only enterprises?
It depends on the customer, not your size. If your buyers have messy data, long security reviews and non-technical users, the last mile will sink pilots regardless of headcount. Early-stage startups often call the same person a founding engineer.
Is the 95% AI failure statistic reliable?
Treat it as directional. MIT’s own notes call the figures directionally accurate from interviews rather than audited reporting, and the success bar is narrow: measurable P&L impact within months. Gartner’s independent forecasts point the same way.
How is a forward deployed engineer different from an AI engineer?
An AI engineer typically builds the model or the AI product itself. A forward deployed engineer makes that product work for one specific customer, which means integration, data access, evaluation and adoption rather than core model work.
What should a company measure to know it is working?
Deployment rate past pilot, time to first production use, and whether anyone on the customer side can maintain the system without the vendor. Adoption by the intended users matters more than model benchmarks.
