The Model Was Never the Hard Part
What the Forward Deployed Engineer boom keeps missing
September 14, 2026
Every AI company is hiring the same person right now.
They call it a Forward Deployed Engineer. The posting is always the same — embed with the customer, turn their mess into something the model can actually use, ship it into production.
The listings went up eightfold in a year. The salaries run past $350,000.
I read a dozen of them last month and kept thinking the same thing.
I’ve had that job for thirty years. We just never had a name for it.
And here’s the part the frenzy is about to learn the hard way.
The model was never the hard part.
I've Had That Job for Thirty Years
Read a Forward Deployed Engineer posting closely and it stops sounding like a job description. It starts sounding like a memory.
Embed with the customer. Sit with the people who own the problem. Translate a business mess nobody can quite articulate into something a system can act on. Integrate with whatever they already run. Ship it where it counts — production, not the demo.
That isn’t a new role. That’s my last thirty years in enterprise data, written in a fresher font.
I’ve spent those years inside large enterprises across financial services and wealth management, manufacturing and telecom equipment, utilities, retail, media and publishing, high-tech, and pharma — different industries, different systems, the same room every time. The work was never glamorous. It was reconciliation: sitting with data that three systems disagreed about and turning it into a single version everyone could trust. And, harder, one that meant something to anyone who didn’t already know the backstory.
That last part is the whole story. Hold onto it.
The title is new. The work is not.
Six Names for the Same Job
Here’s the part the frenzy forgets.
I’ve watched this job arrive under a new name every few years.
It came as the body shop — bodies onsite, billed by the hour. It came as the systems integrator, the onsite-offshore model I spent much of my career inside: a senior team at the client, a bigger team offshore, a program sponsor clearing the path. It came as managed services, which promised — like the FDE now — to be paid for outcomes instead of hours. It came as product professional services — Cisco’s, Oracle’s, the arms that sat next to a partner channel they both fed and undercut. It came as the captive, built in-house to keep the work close.
And now it comes as the Forward Deployed Engineer.
Every one was announced as something new. Every one was the same shape: technical people embedded at the point of action, a sponsor with the authority to open doors, and success defined — on paper — as an outcome instead of a deliverable.
What’s actually different this time is real but small. The FDE collapses the old chain — no onsite analyst handing specs to an offshore team, just one senior engineer who decides and builds at the coalface. And inside a product company, the FDE feeds what they learn back into a product. Those are genuine. They are not new physics.
You can watch the two worlds converge in real time. The integrators are standing up their own FDE practices. The AI labs are standing up their own integration arms. Cisco ran partner-and-competitor against its own channel decades ago; it’s the same play with a model behind it instead of a router.
I’ve watched this arrive six times. The layer underneath never moved.
The Model Was Never the Hard Part
I learned this the expensive way.
A while back I took a pipeline that ran on a large commercial model and rebuilt it on a small open-source one — something I could stand up on hardware I could hold in one hand. Everyone expected the output to fall off a cliff.
It barely moved.
What moved the output was never the model. It was everything around it. What you fed it. Whether the record going in actually meant what it claimed to mean.
That’s the lesson every Forward Deployed Engineer is about to relearn on someone else’s timeline. You are not hired to pick the model. You are hired to make the customer’s reality legible enough that a model’s answer is worth trusting.
And the customer’s reality is a mess. It’s always a mess.
Swap the model all you like. The mess is still there when you’re done.
What the Pipelines Left Behind
Walk into any large enterprise, in any industry, and the story rhymes.
A single source of truth that turns out not to be single. An ETL layer faithfully carrying yesterday’s errors into tomorrow’s warehouse. An analytics layer that’s always late — not because the queries are slow, but because nobody can agree on what the data underneath them means.
Then the agent arrives, and you learn the mess was never the real problem.
The data never carried its meaning.
For as long as I’ve done this, the pipelines moved values, not meaning. The number, the code, the string — but never why the record existed or what you were meant to do with it. That context never traveled in the pipeline. It lived in someone’s head — the analyst who just knew, the engineer who’d seen it before. And it worked, because there was always a human at the end to supply what the data couldn’t.
An agent has no one to ask.
It can’t inherit tribal knowledge or read meaning off a colleague’s face. It needs the business context carried in the record itself — what this is, where it came from, what it’s allowed to do — in a form it can read. That’s the bar now. Not clean data. Data that means something. Call it a customer record in retail, a product master in high-tech, a material master in pharma, a transaction at a bank — the noun changes with the industry; the gap doesn’t.
You can’t prompt your way to meaning the data never carried.
Deep and Broad at the Same Time
Here’s the part that makes me doubt the whole boom.
To actually close that gap, an FDE has to be two people at once.
Deep enough in the domain to know what a record means and what a wrong call costs — why the finance team bypasses the workflow at quarter-end, which of four identical-looking customer records is the one the business actually runs on. And broad enough in engineering to turn that judgment into something that runs in production.
Deep and broad. At the same time. Most people are one or the other.
The broad half, you can train. Engineering, integration, the agentic tooling — that’s what the FDE academies teach and the thirty-thousand-consultant programs certify. It scales.
The deep half doesn’t. Domain judgment is accreted, not taught — years of sitting with a business until you know where the bodies are buried. It’s the same tribal knowledge that never made it into the data. You cannot bootcamp it, and you certainly cannot mass-produce it.
Which is what makes the numbers the tell. Microsoft is standing up six thousand of these. Accenture is training thirty thousand. You do not train thirty thousand people to have judgment. You train them on tools and call it judgment, and the depth quietly averages down to nothing.
I don’t know for certain whether deep-and-broad is trainable or structural — whether the effective FDE is a skill we haven’t learned to teach yet, or a rare fusion that never comes at scale. Thirty years in, my honest bet is structural. The best ones I’ve known were not trained into it. They were built by time.
You can staff an army. You cannot staff judgment.
Why the Model Keeps Changing and the Problem Doesn't
Follow the money and each version fails the same way.
The integrator is paid by volume — a mess that persists is billable. The product-services arm is paid for dependence — it prices proximity to the roadmap. The product company’s FDE has the better incentive, to generalize so the next job needs less of it, and hits the same wall anyway, because the decision that’s missing belongs to the customer, not the vendor.
Even the captive — the in-house team, the one paid by and for the client — only removes the vendor’s bad incentive. It doesn’t remove the client’s own. An internal team gets starved at budget time exactly as fast as an outside one gets declined.
In-house doesn’t fund the work. It just moves the decision inside the building.
The Boom Is a Symptom
I don’t think the Forward Deployed Engineer boom is a hiring trend. I think it’s a diagnosis the industry hasn’t finished reading.
Every posting is a company discovering that the model was the easy part — and that the hard part, data that means something and judgment deep enough to encode it, is the one thing money can’t summon on demand.
So they do what every decade does. They give the same job a new name, throw talent at the seam, and move on before the layer underneath catches up with them.
It works, for a while.
Then the talent hits the layer. The same way I did thirty years ago. The same way it will hit the next army, under the next name.
Because none of it — not the title, not the headcount, not the model — touches the actual decision. Someone has to sit down and decide what the data means, and hold every system to it. That work is slow, unglamorous, and demos poorly, and it is the first thing a business run to the quarter stops paying for.
Inference as a capability can never solve incompetence.
About the Author
Raghu Vishwanath has spent thirty years in the trenches of enterprise data — across financial services, manufacturing, utilities, retail, high-tech, and pharma — turning messy business reality into systems software can actually act on. He is Managing Partner at Bluemind Solutions, a product engineering firm specializing in MRO master data governance, and writes about software engineering, AI, and building platforms that last.