Two years ago I joined HappyRobot as the first FDE hire, before the role was even called FDE. Since then I've seen the company scale to 60 FDEs and to a $1.2B valuation. In that time, "FDE" went from a word I had to explain in every interview to one of the hottest titles in tech. Every agentic startup now wants a forward-deployed team. Almost none of them have thought clearly about why.
What changed when we went from SaaS to AI agents
SaaS was about digitizing the way we do work. Salesforce gave you a digital interface: a place for people to put in data, collaborate, and then route that data along defined paths. The work itself stayed human. Because the work stayed human, the software could be standardized (to the greatest extent; Salesforce and ServiceNow do have systems integrators and configurators). Every company's sales team basically does the same motions, so the same product (for the most part) fit everyone.
AI agents don't work that way, because agents don't organize the work. They do it. And every company does its work slightly differently. Different SOPs, different edge cases, different definitions of "done." An agent that handles sales escalations for one customer has to behave differently for the next, because "escalation" means something different at each company.
Take escalations, specifically. Many enterprises use Salesforce to track their pipeline. But each one fills out different fields, follows different conventions for what belongs where, and wants an issue routed to a different person depending on what kind of problem it is. They're all using the same SaaS platform. They are not doing the same work. It's the same reason you get onboarded when you join a new company, even if it's the exact same Gmail and the exact same Salesforce you used at your last job, how the team actually uses those tools is completely different. That's what agents are trying to replicate.
That difference doesn't live just in the LLM prompt. It lives in the whole workflow, tools, prompts, and the actions those tools trigger, all wired together. Change one tool's logic and the prompt has to change with it. You can't tune these pieces independently, which is exactly why this can't be a self-serve config panel on day one. Someone has to sit inside the customer's actual process and build the thing that fits it.
Why FDEs
And the person building those agentic workflows can’t just be anyone. That someone has to be AI native. Getting agent behavior right, where to use deterministic logic, where to let the model decide, how to structure the workflow so it actually holds up, and yes prompting and running evals is an empirical, iterative process. It takes reps. FDEs get those reps daily, building agents for a living. That's the whole case for the FDE-led motion: you need people who not only understand the specific business processes but who have built enough agents to have real intuition for what will and won't work.
Here's where most companies get it wrong. They stop there. The FDE builds the thing, the customer is happy, the contract expands, and the FDE moves to the next customer and does it again. It feels like success. It's a services business wearing a software valuation.
Palantir gets brought up a lot here, because Palantir made the FDE motion work, but in a different time and a different market. They entered in 2004, into industries that were nearly impossible to break into, at a time when writing software was niche and nobody else was running the embedded-engineer playbook. That combination let FDE-as-moat work.
That window closed a few model releases ago. Software is getting easier to write every quarter. So now, for the complex use cases, why would a customer trust an upstart's FDEs over Palantir’s? And for the simple use cases, the customer can probably build it themselves with today's AI coding tools. Pure FDE-as-service gets squeezed from both sides.
What a successful FDE motion looks like
The way out is treating FDEs as an extension of product, not a substitute for it. At HappyRobot, we built a UAT testing tool for one customer because they needed it. That tool is now how we run UAT with every customer. We built retry and context-persistence logic for one deployment, once we saw it working and understood the nuances, we built it into the product for good.
Even the best FDE’s are bounded by how many problems one person can touch. Getting faster at bespoke builds doesn't remove that ceiling. The only way past it is customers building their own agentic workflows using your tool, i.e. using everything FDEs have already fed back into your product. If your FDEs are the only people who can ever configure your product, you're not a platform. You're a services company with better branding, and you have the same ceiling as any other consultancy.
If you're building one of these companies, here's how to win, treat your FDEs as technical product managers who can code, productize and as needed, sell, not just implementers. If they're not thinking about scalability while they build, you're wasting them. Track how much of your product gets built or configured by customers themselves, as a percentage of what your FDEs build, that number should be climbing. Track how long similar deployments take, that should be dropping, because that's what frees FDEs to take on more complex and higher impact work. And track revenue per FDE. It should be rising, and if it is, it means both your sales and your product are actually getting better, not just your headcount.
There's a simple test for whether this is actually working
Every deployment should make the product a little better. A better product should make the next deployment a little faster and the people building on/with the product should be growing exponentially. If you can't point to specific ways last quarter's deployments changed this quarter's product, the loop is broken, you're not running a flywheel, you're running a treadmill.
The companies that win this next wave won't be the ones with the most FDEs. They'll be the ones who leveraged FDEs correctly.