What does a forward deployed engineer actually do?

Forward deployed engineer is one of the hottest titles in AI in 2026. Salesforce calls it “today's hottest role”. Product companies and consulting firms are both adopting it. The definition is less settled than the enthusiasm.

An FDE might help a customer deploy a software platform, build a custom agent, discover a new product opportunity, or do several of those things in the same engagement. Much of that sounds familiar to anyone who has worked in technical consulting.

So what has changed? AI is making it possible to build more software around individual businesses, while product companies are taking on more of the work required to make that software useful. The FDE title sits where those two developments meet. Understanding it means looking at how consulting and product development are changing, and where their economics still differ.

One title, several kinds of work#

A forward deployed engineer works directly with customers to make software useful in their environment. The role combines engineering with enough knowledge of the business to decide what needs building.

Beyond that, the mandate varies. On the South Park Commons panel, Calvin Lee describes Ramp's FDE team as a way to win enterprise customers while protecting the core roadmap. Elsewhere, the work can be a way to discover the roadmap in the first place.

Natalie Meurer's account of the role's history traces it through infrastructure, data integration, applications, and customer enablement. Accountability to the customer is more consistent than the particular technical work.

That responsibility is familiar territory for an engineering consultancy. The title also no longer tells us whether someone works for a product vendor: Anthropic's alliance with DXC explicitly includes training forward deployed engineers inside a consulting and services business.

FDE describes an approach to the work more reliably than it describes a distinct business model. To understand the business, we need to ask what the team delivers, what remains specific to the customer, and what can be delivered again.

Why AI brings product companies into the workflow#

In The FDE Playbook for AI Startups, Bob McGrew connects forward deployment to product discovery inside enterprises. When the category is new, working within the organization helps reveal which workflow is worth solving and what a useful product would need to do.

We expect cheaper implementation to make more of that discovery economically possible. A team can try a narrower workflow without first committing to months of software development.

But faster implementation also makes it easier to mistake a working demonstration for a finished engagement. The code may be ready before the team has agreed which exceptions are allowed, who approves consequential actions, or who handles a failure halfway through the workflow.

In his interview with Altimeter, Colin Jarvis describes evaluation as a starting point for deployment, alongside deterministic checks for constraints that need to hold reliably. That work gives users evidence they can inspect when deciding whether to trust the system. Jarvis, 9:14–10:20

Those decisions still require knowledge of the customer's work. A stronger coding agent can help implement and test them, but it does not supply an organization's missing agreement about acceptable behavior.

Where customer work becomes a product#

Nominal provides a useful example of that boundary. It had a customer whose engineers wanted to analyze drone flight data in its platform. Getting the data ready required scripts running on their laptops. The customer wanted Nominal to handle that step.

In the panel, Jason Hoch describes how the team addressed it: they built a way to upload a container containing the data-transformation logic. The first implementation served that customer, but the capability became something Nominal could sell to others. Panel, 16:31–17:54

The important decision in the Nominal example was where to draw the boundary. A customer's transformation logic could remain specific to its data while the mechanism for running that logic became a shared capability. Other customers could bring their own transformations without needing an entirely new implementation.

That boundary takes judgment. Generalize too early and the team may spend months building flexibility nobody needs. Keep every fix local and the company accumulates a collection of customer-specific systems that someone has to maintain.

It also takes an owner. Someone needs to support the shared capability, define its limits, and make it available to future deployments. A script copied between projects provides a head start, but it also leaves each team responsible for its version.

Sierra describes a deliberate approach to this work: its agent engineers build canonical components for common behaviors and extend them for particular deployments. That is an example of a company organizing reuse, rather than merely hoping it will emerge from delivery. Meet the AI agent engineer

A consultancy can organize itself this way as well. Maintained components, accumulated domain knowledge, and repeatable delivery methods can make its next engagement easier. Calling a team forward deployed tells us little unless we can see how those improvements happen.

When customers keep buying the engineers#

The difficulty is that successful delivery can conceal a weak product.

On the panel, Hoch describes a failure mode in which customers depend on the embedded engineers and leave when those engineers are withdrawn. The relationship is valuable, but the software has not become sufficient to sustain it. Panel, 25:51

There can be a good business in supplying an ongoing expert team. The problem arises when a company treats demand for that team as evidence that it has built a repeatable product.

Jarvis raises the corresponding tension inside the supplier. In the same interview, he describes firms that intend to build products but keep being pulled toward immediate services revenue. Another custom project pays today. Improving the platform competes for the same people, with a less certain return.

A large contract does not settle that conflict. It can fund useful discovery or commit the team to maintaining another isolated system. Both can look like growth at the time of signing.

For comparable deployments, we would look at how much engineering effort they require, including support after launch. Are repeated requests becoming supported capabilities? Can customers make routine changes without the original engineer? Does the next deployment benefit from the previous one, or mainly inherit its maintenance burden?

The comparison needs to be fair. Entering a new industry may require substantial discovery again. Jarvis also distinguishes product bets from engagements pursued for research learning. An experiment can be worthwhile before a reusable capability exists. What matters is being clear about what the investment is expected to produce, then checking whether it did.

What matters to the business buying the work#

The supplier wants to build something it can sell again. The customer wants its problem solved on acceptable terms. Those interests often align, but they deserve separate attention.

A vendor's FDE can bring deep product knowledge and direct access to the people who can change the platform. That is valuable when the product is a good fit. The vendor also has an incentive to frame the solution around its technology.

An independent consultant can be engaged to compare alternatives, integrate across suppliers, or build a capability the customer owns. Independence still needs to be established in the actual relationship; a consultancy's partnerships can influence its advice too.

At HARTRO, we start with the workflow and the result the business needs. The engagement should make clear what the customer is buying and what happens after the initial build. Who owns the integration and its business rules? Who responds when it fails? Can the customer's team change the workflow, and which changes require the supplier?

A consulting business can succeed by repeatedly applying its expertise to different customer problems. A product business needs a growing share of that value to come from capabilities it can maintain and deliver across customers. AI gives both more room to build tailored systems. The FDE title captures their growing overlap; it does not remove the need to decide which business is being built.