The forward-deployed engineer — the FDE — has become one of the most talked-about roles in AI. Ask ten people what it means and you'll get ten different answers. That's not because anyone is wrong. It's because the role is in the middle of escaping the company that invented it, and in the process it's becoming something much bigger than a job title at a software startup.
I want to trace that arc: where the FDE came from, why AI changes what it is, how it differs from the roles it's often confused with, why the same title means different things at different companies — and why I think, within a few years, forward-deployed engineering won't be a software-industry curiosity. It'll be a strategic capability inside nearly every enterprise.
Where the forward-deployed engineer came from
The FDE is a Palantir invention. The insight behind it was almost embarrassingly simple, and almost nobody was willing to build a company around it: the best way to deliver real value to a customer is to send someone to sit with them. Not to demo, not to gather requirements and disappear — to be on-site, embedded, working alongside the customer to understand what their actual problems are, and then to solution directly against those problems.
That's the forward-deployed engineer. A generalist-technologist who deploys into the customer's world, learns the business from the inside, and builds. It worked because proximity beats specification. The person closest to the problem, with the ability to ship, delivers more than any amount of remote requirements-gathering ever could.
But there's a caveat that matters enormously for where this is heading, and it usually gets dropped: at Palantir, all of that solutioning was about data. The FDE was deploying onto a data platform, and every problem they solved was framed as a data problem — integrating it, modeling it, building data-driven decisions on top of it. The role was invented, but it was invented in service of one specific horizontal layer: data.
That's the connection that makes the FDE suddenly relevant far beyond Palantir. Palantir created a new class of technologist — the embedded, solution-oriented engineer — and proved it could deliver disproportionate value. What's changed is the layer.
AI is a horizontal layer, and that's why the role travels
Data was horizontal. Almost every enterprise problem could be reframed as a data problem, which is exactly why an FDE deploying onto a data platform could add value across wildly different customers and industries.
AI is horizontal in the same way — arguably more so. It isn't a vertical product for one department. It's a layer that can be applied to nearly anything: enterprise applications, products and services, internal operations. And the place it's compounding fastest right now is agentic engineering — applying models and harnesses to the work of building software itself.
That's why the forward-deployed engineer translated so cleanly from Palantir to the AI labs and the broader AI market. The pattern — embed, understand the business, solution against real problems — is the same. What's swapped underneath it is the horizontal layer the engineer is deploying on top of. It used to be data. Now it's AI. The role didn't need to be reinvented; it needed a new substrate, and AI is a bigger substrate than data ever was.
It's not a solution consultant, and the difference is the point
The FDE gets confused with a role that enterprise B2B SaaS already made popular: the solution consultant, or sales engineer. The comparison is understandable, and there's real overlap — both are technical, both sit close to the customer, both solution. But they are not the same role, and the difference is worth being precise about.
A solution consultant or sales engineer is, by design, tethered to a product. They're experts in their platform — its API architecture, its user interface, the surface area of what it can and can't do. Their job is to map the customer's needs onto that specific product. The product is the fixed point; the customer's problem gets shaped to fit it.
The forward-deployed engineer inverts that. They go in as a generalist, closer to the end-to-end business, without a single product they're obligated to bend everything toward. The customer's problem is the fixed point, and the solution gets built around it. That freedom from a single product's constraints is precisely what lets an FDE understand the business more holistically — and it's what makes the role feel different to everyone who's worked with one.
Why the same title means different things at different companies
Here's another reason you get ten different answers: the FDE's role changes with the company's stage.
Run through the startup t-shirt sizes — seed, Series A, Series B, all the way to an IPO-scale company — and the FDE looks different at each one, because the company's center of gravity moves. Early on, before the revenue engine is really turning, forward-deployed engineers tend to live close to the product team. They're embedded with the first design partners, and their real job is to tighten the feedback loop back into core product. What they learn on-site becomes the roadmap.
Once the revenue engine starts working, the same role drifts toward go-to-market. The FDEs align more with sales, deploying to close and expand accounts, to make deployments succeed so they renew and grow. Same title, different orbit — product gravity early, go-to-market gravity later.
So when someone tells you confidently what a forward-deployed engineer "does," the honest answer is: it depends where the company sits on the spectrum from product to go-to-market. That's not vagueness. It's the role faithfully tracking what the business needs most at each stage of its maturity.
The bigger claim: this stops being a software-company role
Everything so far describes the FDE inside software companies. But I don't think that's where the story ends. I think the more important shift is that forward-deployed engineering is about to escape software companies entirely.
Every organization that wants to become AI-native — an agentic organization — is going to need a forward-deployed engineering capability of its own. Not to sell software, but to deploy AI into its own services and its own internal operations. And we have a clean historical analogy for how this plays out: the data analytics era.
Think about what happened with business intelligence. BI went from a specialty to a capability every team needed. Companies of every size invested in a stack to support it — data lakes at the bottom, data visualization layers at the top, and everything in between. The larger organizations went further and stood up data analytics and data science centers of excellence: dedicated teams that served dashboards, insights, and models out to every other function in the business. Analytics stopped being a department and became a shared, horizontal capability.
I'd argue forward-deployed engineering orgs are going to follow the same path across the enterprise economy. As businesses deploy AI over the coming years, these teams will show up everywhere — and they'll be deeply strategic.
What these teams already look like
This isn't a prediction about a distant future. It's already starting. People are being hired into these roles and promoted into them from within. The titles are still stabilizing — applied AI lead, AI deployment leader, VP of agentic systems, and their cousins — but the shape is consistent. And this is only the beginning.
These teams become the organization's Swiss Army knife for AI. They run the experiments, find what actually works, and turn scattered AI enthusiasm into shared, reliable capability for every other team. They're the connective tissue between what's possible with AI and what a business actually does with it.
Notice that this is the same forward-deployed pattern — just pointed inward. Instead of deploying into an external customer, these engineers deploy into other business units, arriving with core agentic capabilities and solutioning against that unit's real problems. More inward-facing than outward-facing, but forward-deployed all the same. The substrate is AI; the method is Palantir's; the destination is your own org chart.
The core deliverable: skill packages for a use-case domain
If you want to pin down what these teams actually ship, it's this: skill packages scoped to a use-case domain. The FDE org's job is to break down real work in a domain, translate it into the enterprise AI system or agentic product, and package that work as skills — so the capability can be reused instead of rebuilt every time.
It's easiest to see through two examples.
Inside a SaaS company, an FDE org points its attention at onboarding and implementation flows. It asks: what skills, what workflows, what integration paths can we build at the edges of our standard product — the seams where the product meets each client — to accelerate onboarding, reduce integration effort, or expand the surface area of value the product addresses? The output is a set of skills that live at those edges, closing the gap between a general product and a specific customer's world faster than professional services ever could.
Inside an enterprise running the usual functions — sales, service, marketing, finance — the FDE org does the same thing pointed at internal workflows. It builds packages of skills that zero in on how each function actually works and accelerate it directly: the finance close, the service escalation path, the marketing campaign build, the sales motion. Each function gets skills tuned to its own workflows, not a generic assistant bolted on top.
The standard pattern underneath both is identical. The FDE org decomposes the work, incorporates it into the AI system, and packages it as skills — and those skills behave like plugins. They're the extension layer that sits between the raw agentic capabilities and the deployment surface where the work actually happens, turning a general capability into something that does a specific job in a specific domain. That packaging — not one-off automations — is what compounds, because a skill built once for onboarding or for the finance close gets reused, versioned, and improved instead of reinvented.
The primitives add up to an agent
The skill package is the starting point, but it's not the whole toolkit. Look at how the work actually gets distributed and it comes down to a small set of primitives — the same ones Anthropic and OpenAI compose their own products from, and the same ones a company can assemble for itself:
- Skills — domain work, decomposed and packaged so it's reusable instead of rebuilt.
- MCP — bundle skills and tools behind a server, and the package stops being a folder you copy around and becomes something any agent in the company can connect to. Distribution turns into a connection.
- Tools and APIs — wire tools to your internal services, and the skills stop being advice and start being able to act — reaching into the systems where the work actually lives.
- The harness — the surface that holds the model, the skills, and the tools together and puts them in front of a person.
Now stack those primitives up. A model, held in a harness, carrying skills and tools, with the tools reaching into your APIs and the systems underneath them.
That isn't a metaphor for an agent. That is an agent.
Which means the deliverable was never really "skills." It was agents — and the forward-deployed engineering org is the team that develops a mastery of these primitives in order to build and distribute agents across the company. Skills, MCP, tools, APIs, the harness: that's the vocabulary. Fluency in it is what lets the team turn a business's real work into agents and get those agents into the hands of the people who do that work.
Where AgentGraph fits
This is the work we do. AgentGraph runs a network of forward-deployed engineers on our platform, and we help companies build out this capability — formalize it, staff it, and grow it.
Most organizations doing this today have one or two people in a pod, quietly proving the pattern works. We believe those pods are going to grow into something much larger and much more strategic. The companies that build this capability deliberately — that treat forward-deployed engineering as a center of excellence rather than a side experiment — are going to hold a real competitive advantage over the ones that don't.
The forward-deployed engineer was invented to deliver value through data. In the agentic era, it becomes the way nearly every organization delivers value through AI. If you're figuring out how to stand up that capability inside your own company, let's talk.