The Engineer Who Doesn't Leave
By the end of last year, 88% of companies had deployed AI in at least one business function. In the same survey, 94% reported seeing no significant value from it.
That is McKinsey, not a sceptic on the internet. And that single gap, between everyone having bought the thing and almost nobody getting anything out of it, is the entire reason a job title you have started seeing everywhere exists at all.
The response has been unusually expensive. Roughly $9 billion of capital was committed to four enterprise deployment ventures in four months: the OpenAI Deployment Company in May, AWS's $1B forward deployed engineering unit on 30 June, Microsoft Frontier two days later, and Ode with Anthropic in July. Not four companies each writing that cheque, to be precise about it: four ventures, funded by the labs alongside investors, integrators and consultancies.
This post is the practical half of that story: how to tell a real posting from a relabelled one, what the job actually asks you to build, what each Indian lane pays and who it takes, and why the experience you have been apologising for is the qualification. The video is the same case told as a story, if you would rather hear it than use it.
The definition, and the two jobs it keeps getting confused with
Here is the shortest honest version. A forward deployed engineer works for the company that builds the technology, sits inside the company that bought it, and writes production code there until the thing actually works.
If that sounds like something we already had, it should. Vendor pays you, client hosts you, you build on your employer's platform. AWS Professional Services has worked that way for years. So has every Databricks or Snowflake implementation engineer. The distinction that matters is not vendor versus client. It is what you own and when you are allowed to stop.
software engineerBuilds the vendor's product. Same codebase every day, thousands of customers, you meet none of them. Your feedback loop is a metrics dashboard and a support queue.
solutions architectDesigns how one customer should use it. Discovery, reference architecture, a proof of concept, a handoff. Once the design is signed off the architect is done, and if it is broken in production six months later, that belongs to somebody else.
forward deployed engineerThe one who doesn't leave. Published analyses put technical work at roughly 70 to 80% of the role. You own the system inside the customer's environment until people are genuinely using it, which is a condition somebody has to measure rather than a date on a plan.
It's cloud consulting with a fashionable title. We already have delivery engineers, implementation engineers and professional services.
AWS already had thousands of solutions architects and a full professional services organisation. In June it spent a billion dollars standing up a separate forward deployed group anyway, saying explicitly that unlike traditional consulting, which assesses, recommends and treats each deployment as a standalone project, this one builds for the long term. Nobody spends a billion dollars renaming a team they already own.
The part that has no equivalent in cloud delivery
Configure a Kubernetes cluster correctly and it behaves the same way tomorrow. Same input, same output. That determinism is the quiet foundation under every runbook, every acceptance test and every handoff document in infrastructure work.
A language model does not do that. The same prompt can return a different answer, or a confidently wrong answer, or a correct answer in a shape that quietly breaks whatever runs downstream.
So a large share of this job is work that traditional delivery has no procedure for. If you want to know what separates the role from implementation engineering in practice, it is this list, and it is the part most candidates have never built.
Not a public leaderboard. A set of real examples from this customer, labelled by people who understand the domain and nothing about machine learning, with a scoring rule you can defend to them. Everything else depends on this existing, because without it "better" is an opinion.
Structure validation before anything downstream consumes the output. Refusal paths. Confidence thresholds that route to a human instead of guessing. Assume wrong output as a normal operating condition, not an incident.
Anything that sends money, sends a message externally, writes to a system of record, or touches a customer. The design question is not whether a human approves, it is what the human is shown at the moment they decide.
The model version changes, the retrieval corpus changes, the customer's data changes shape, and none of those three events announce themselves. You need a scheduled run of the eval set and an alert when the score moves, or you find out from the client.
Every enterprise document store has an access model, and the demo version ignores it. Retrieval that leaks across permission boundaries is not a bug you patch later, it is the thing that ends the deployment.
Written down, measurable, agreed before you build. The 94% number exists largely because this step gets skipped and every party leaves the room with a different picture of success.
If you are trying to become hireable for this and you only have time to build one thing, build the eval harness. It is the artifact that most cleanly separates people who have deployed AI into a business from people who have demoed it, and it is the one you can build this month on a problem you already understand.
What the work actually looked like, once
OpenAI's forward deployed team worked with John Deere. The head of the team and one engineer flew to Iowa and spent time with farmers, in fields.
The interesting detail is the deadline. It was not a product deadline. Crops go in the ground when crops go in the ground, and if you miss the growing season there is no next sprint, there is next year. The engineering was reviewing hundreds of real examples alongside people who knew agriculture and nothing about machine learning, building a custom evaluation system because no benchmark existed for whether this advice actually helped a farmer, then iterating until the numbers moved. By OpenAI's own account, chemical usage on those farms dropped by up to 70%.
If you have spent time in Indian services, alarm bells are going off, and they should. Fly in, learn the client's domain, build the custom thing, bill the hours. We have decades of experience with that model and we know exactly how it ends.
Except this one has a different exit. That work fed back into OpenAI's Realtime API, which means every other customer got the improvement, including customers who have never heard of a tractor.
That is the actual output of the role. Not the project. The pattern. The custom integration becomes a component. The evaluation harness becomes part of the platform. An engineer who only ever ships one-off client code that teaches the product nothing is a contractor with a better title, and the whole model collapses back into staff augmentation.
This is also the sharpest question to ask in an interview, and it tells you what you are really being hired into: "What from the last deployment shipped into the product?" A specific answer means the loop exists. A vague one means you are being sold a billable-hours job with a fashionable name on it.
Reading a posting: real role, or relabelled one?
Here is where most of the wasted effort happens. Search results lie about this role, badly. Glassdoor returns hundreds of Indian results for the phrase and only around fifty for the tightly matched title, and TeamLease Digital counts roughly 250 to 270 genuinely active openings nationally at any moment. Most of the rest is solutions engineering wearing a better hat.
Run any posting through these six tells before you spend an evening on the application.
Who runs productionReal one: you own the deployed system in the customer's environment. Relabelled one: you hand over to a delivery team, or to the customer's own engineers, at go-live.
Where coding sitsReal one: hands-on engineering leads the responsibilities and the stack is named. Relabelled one: system design and stakeholder management lead, and coding appears somewhere near "and other duties".
Evals and guardrailsReal one: evaluation frameworks, guardrails, agent development, human-in-the-loop appear by name. Relabelled one: talks about AI strategy, roadmaps and enablement.
The feedback loopReal one: the description says something about improvements flowing back into the product or platform. Relabelled one: measures you in utilisation, billable hours or number of accounts.
Success criteriaReal one: adoption, usage, an outcome metric. Relabelled one: delivery milestones and sign-off.
Who the vendor isReal one: you work for the company that builds the technology. Relabelled one: you work for a partner reselling somebody else's platform, which is a genuinely different job with a different ceiling.
Compare that against a real spec. Anthropic's posting asks for production LLM experience including advanced prompt engineering, agent development, evaluation frameworks and deployment at scale, on top of three-plus years in technical customer-facing roles. Nowhere does it ask you to publish a paper.
Most of the big Indian numbers are not open hiring. TCS, India's largest IT services company, plans to move up to 8,900 of its own engineers into this role, roughly 1 to 1.5% of its associate base. Cognizant's Frontier programme is certifying 5,000 engineers and 10,000 business operators, and Coforge launched Momentuum AI at the end of July with a 90-day academy attached. Those are overwhelmingly internal conversions. If you are already inside one of those firms, the fastest route into this work is an internal transfer, not a job board.
The three lanes in India, and what they actually pay
These are not three tiers of the same job. They are three different jobs that share a title, with different ceilings, different doors and genuinely different day-to-day work. Bands below are ranges compiled from posted data and market guides, not offers.
Global remote at the labsThe AI-first companies and labs hiring India-based engineers on global remote tracks. Palantir is the long-running example. Roughly ₹35–55L at the junior end and ₹90L and above at senior. Highest ceiling, smallest door: openings are few and most fill through referral rather than job boards.
India offices of the AI platformsDatabricks, Snowflake, Salesforce, ServiceNow, Google Cloud, and McKinsey QuantumBlack with its Principal Forward Deployment Engineer track. About 70% of Indian FDE postings sit in the Bengaluru–Hyderabad corridor. Roughly ₹22–35L early and ₹55–80L senior, approximate and drawn from overlapping published ranges. Realistic target if you have solid product or backend experience.
Services firms and GCCsWhere the volume is, by an enormous margin, and where the money is lowest: often ₹10–18L at entry, with the wider services band running to ₹28L. TeamLease puts experienced Indian FDEs at around ₹40L on average, which is an average for experienced practitioners rather than a starting number.
This is not a fresher role, and pretending otherwise wastes your year. Almost every Indian job description asks for two to five years of real product or backend experience. The job is judgment under ambiguity in somebody else's environment, in front of their executives, and there is no way to fake that out of college. If you are earlier than that, the honest move is two years of production engineering first, with the AI application layer picked up alongside it.
What to build, and what to stop trying to build
The reflex is to go and learn machine learning research. That is the wrong direction and it will cost you a year. Three things carry this role instead.
The problem will jump from backend to frontend to infrastructure inside a single afternoon, and there is nobody to escalate to, because you are the escalation. You do not need depth everywhere. You need to not stop when the problem crosses a boundary.
Retrieval, tool calling, evals, guardrails, human approval steps, and above all the ways models fail: hallucinated confidence, silent format drift, prompt injection through retrieved content, degradation on the long tail your demo never touched. Failure modes are the actual curriculum here.
"Run this securely inside our own environment" must not be the sentence that ends your project. Private networking, secrets handling, data residency, logging that does not quietly exfiltrate customer data into a vendor's console. This is where most demos die.
Notice that none of it is novel research and all of it is buildable in your own time, on a problem you already understand, which is exactly the kind of thing that survives an interview because you can answer follow-up questions about it.
The half that isn't code
You can be technically excellent and still fail this job, because a large part of it is translation.
In a single week you might talk to a client's platform team, their security team, a product manager, a domain expert and an executive. Five descriptions of the same problem, none of them matching, and at least two of them wrong in ways that only become visible after you build something. Turning that into software is the work. It is not a soft skill sitting beside the engineering, it is the engineering, and the most common failure is a technically correct system that solves a problem nobody actually had.
Write down each stakeholder's description of the problem in their own words. Resist harmonising early. The contradictions between them are the real specification, and they disappear the moment you paraphrase.
Usually not the person who called the meeting. Ask what they do today, manually, and time it. That is your baseline, and it is the only honest measure of whether you improved anything.
Then read it back to the room. This single act surfaces more disagreement than a month of design docs, and it is far cheaper to have that argument before the build than after.
Nothing reconciles five conflicting descriptions faster than a working thing everyone can react to. Ambiguity survives discussion. It does not survive a demo.
Why services engineers are undervaluing themselves
Legacy code. APIs that lie. Auth nobody wants to touch. Databases carrying ten years of decisions made by people who left. Requirements that change halfway through a sprint. Clients who describe the same problem five different ways. Systems that technically work and nobody uses.
If you have done enterprise or services work, you have lived inside every one of those. That was mostly a complaint right up until AI moved out of the chat window and into real systems. Now it is the qualification, and the mapping is close to one-to-one.
Undocumented legacy systemsThe integration surface of every real deployment. Models are useless without the data locked inside those systems, and the person who can safely read them is rare and expensive.
Clients who change their mindsRequirements discovery under ambiguity, which is the defining condition of the role rather than an interruption to it.
Security reviews and compliance gatesThe stage where most AI pilots die. Having already survived one, in a regulated environment, is a differentiator you probably do not put on your CV.
Working on-site with non-technical usersExactly the John Deere skill: sitting with domain experts, extracting judgment they cannot articulate, and turning it into labelled examples and an eval set.
Shipping things nobody usedYou have seen adoption fail firsthand, which is the failure mode this entire role was created to prevent. Most people optimising for benchmarks have not.
Where this actually stands
Be careful with the enthusiasm. The external Indian market is small, most of the headline numbers are internal conversion, a good share of the postings are mislabelled, and the entry-level end of the services lane pays what services has always paid. Anyone selling this as an easy jump to ₹40L is selling you an average for experienced practitioners.
But the demand side is not subtle either. Gartner expects more than 85% of technology vendors to have launched a programme like this by the end of 2026. In the United States there are, by one estimate, roughly 17,000 people doing this work and about 2,000 who have repeatedly delivered real value with it. Every one of those numbers is a bet that supply goes up. It has not yet.
None of it is a new invention, by the way. Palantir built this model twenty years ago on government contracts, and in 2009 put as many as 120 forward deployed engineers inside JPMorgan. For years afterwards it employed more of these engineers than conventional software engineers. The model is old. Everyone else just finally needed it.
If you are a software engineer looking for a way into applied AI, that gap is the opening. Not because the title is fashionable, but because you may not have to throw away what you already know.
You may just need to apply it a lot closer to the problem.