The rise of AI forward deployed engineers

What's old is new again

Forward-deployed engineering is all the rage for AI startups nowadays. Just the other day, we overheard the following exchange on a first date at Jalebi Street in San Francisco:

“So what you’re doing is like sales engineering?”
“No, it’s more like a Palantir-style forward deployed role!”

The phrase forward deployed engineering has its roots in military operations (i.e., forward-deployed forces) and Palantir popularized it in the late 2000s, largely because they were working with defense contractors and government agencies. In the software context, forward-deployed effectively means a software engineer who’s working on-site with a customer, becoming an expert in their domain and problems, and customizing product functionality to meet the customer’s exact requirements. When working with extremely high-value, security sensitive customers, this makes perfect sense.

Source: GPT-5.

But as you’ve probably seen on the internet in the last few months, forward-deployed engineers are everywhere in AI now — especially if you’re trying to sound cool on a first date! At a high level, we totally understand why this is the case. As we learn more about our customers’ needs at RunLLM, we’ve learned that building agents that justify a 6+ figure price tag is going to require a lot of customization. As we’ve discussed before, with AI, you’re paying for work done rather than access granted, and every company has their own way of working so the expectations for how that work looks will vary significantly. We’ll discuss this in detail below, but having a highly technical engineer is necessary to manage that process today.

Unfortunately, we’re also probably seeing a misapplication of this trend as well. Not every business requires or justifies a forward-deployed engineer, and if you’re not careful, you’re going to be setting the wrong expectations with customers. When should (and shouldn’t) you think about forward deployment? There’s a few questions we think you should be asking yourself — let’s dive in!

What is different about AI?

There’s a lot about AI that’s just traditional software, and there’s a lot that’s new. As you’re reading the rest of this blog post, you might find yourself thinking that the economic arguments aren’t really all that different from the way enterprise software worked 10 or 20 years ago — you’re totally right.

The key difference is the point we referenced briefly above: Your customers are no longer buying access, they are buying work. To sell that work effectively, the burden’s on you to do the work the way the customer expects. After all, traditional consulting roles are the ultimate form of forward deployment: You’re getting a dedicated team working with you for an extended period of time. Working the way your customers work sounds simple, but complexity can vary.

Some of that customization is easy — e.g., follow this template for your responses — but some of it will require much deeper agent customization and SaaS integration. For example, at RunLLM, our agents learn how to investigate technical issues by following the examples set by our customers’ engineers; that means teaching the agent how to analyze log data or when to make a pull request.

The interesting thing about AI is how you actually customize the agents to do what you want them to do. It’s one thing to build an integration to pull the right information in. It’s harder to get the right information at the right time, and of course the holy grail is building an agent that can autonomously make decisions about what to do and when. At the current level of AI maturity, that’s not going to be accomplished with a one-size-fits-all solution, so your engineers are going to have to do a lot of customization.

What, actually, is forward deployed engineering?

Many of you are probably asking why this is any different from what’s typically referred to as sales engineering and solutions architecture? The obvious answer is that forward-deployed engineering sounds way cooler, and when we have a hot new trend like AI, we need to make sure that our job titles sound as cool as possible.

Jokes aside, there really isn’t that much difference between traditional enterprise sales engineering and the forward deployed terminology being thrown around today. In the 2000s, Palantir’s FDEs were genuinely embedding themselves into their customers’ organizations for months or quarters at a time, and that investment (in the tens of thousands of dollars) was justified by the fact that contract sizes were in the millions.

We have no objection with cool sounding titles, but it’s worth being clear about what the investment actually is. Today, what we’re really talking about is using technical resources to customize agent behavior for a customer. This is something that should probably take days or weeks rather than months or quarters; it is still a significant investment from an expensive technical resource, but it doesn’t quite require actual embedding. Depending on who you’re talking to, you should be careful with your vocabulary to manage expectations.

What kind of business are you building?

With the definitions out of the way, the economics are the next big question. Software engineers are obviously some of the most valuable and expensive resources you have at your organization. Of course, if you need to deeply customize the behavior of your agent, having someone with deep technical expertise will make that process much smoother than otherwise, but you need to make sure that the time investment from that person justifies the return.

If you’re selling 8-figure contracts, you can have a truly forward-deployed and embedded engineering model. If you’re selling 6- or 7-figure contracts, then you can absolutely justify spending some time and resources to make the customer successful within reason — in fact, it’s probably almost required with AI (more on this below). If you’re selling 4-figure or low 5-figure contracts, the math starts to make very little sense; at this point, you’re effectively selling a premium on engineering time, which starts to look much more like services revenue (i.e., consulting) than it does like product revenue. Companies like Pivotal have historically made this work, but it’s not the default model of success.

It’s worth pointing out here that in the early stages of a company, you should do whatever it takes — including probably spending more time than the size of the contract — to make a customer successful. We’ve done that too, and the point isn’t to say that you should be tracking every dollar. However, if you’re seeing that every customer engagement requires non-trivial technical resources, then you should be thinking about how to justify that investment or lessen the time required (or both!) in the long-term.

What are your customers’ expectations?

As we’ve discussed before, many customers just don’t know what to expect from AI agents today. Some customers are shocked we haven’t yet ended world hunger, and others are shocked that we can solve the simplest problem they have. Managing customer expectations is a critical part of both the sales and post-sales processes: What problems are you going to solve, how soon will they see results, and where are you continuing to invest in the product?

Your answer will be influenced by the types of companies you’re selling to, the complexity of the use cases they have, and which org within the company you’re selling to. Each combination of these factors will yield different results. Deals with teams that want things that “just work” with low complexity means you should be investing in self-serve product onboarding – and expect that they won’t tolerate long implementation timelines. Working with engineering teams, on the other hand, who will tolerate complexity but need the agent to do exactly what they want is a very different process. Unsurprisingly, the former will be a high-volume, low-ACV business, and the latter will be the opposite. Knowing where you land on that spectrum makes a huge difference, and it allows you to direct your investments towards self-serve vs. white-glove processes.

Customer Success + AI

Looking beyond the tactics of the sales and onboarding process, all of this points towards an interesting trend in AI, which is that customer success is shaping up to be something genuinely different than it was before. What hasn’t changed is that enterprise customers require time and attention — whether you’re selling a 7-figure CRM deal or an agent, you need to be able to prove to your customers that you can make them successful and earn their trust.

But with the pace of change in the industry, product velocity and partnership are just as important. Most enterprises aren’t just picking which startup they’re going to use for the next year — they’re looking at who’s going to keep up with the changes in the underlying technology, adapt to those changes as quickly as possible, and keep their customers up to speed with what’s going on. That also means that customers are throwing out “Why don’t you…” hypotheticals at an unprecedented rate. As a vendor, you need to be able to earn their trust that you’re going to work with them closely to implement and enable the right technology.

In other words, the nature of customer success is changing with AI agents. The speed of iteration and the rate at which customers expect value to grow are no longer on a multi-year timeframe. You need to be engaged regularly and showing value month-over-month — otherwise, customers will think you’re falling behind.