Someone on your team has probably forwarded you a forward-deployed engineer job post in the last few months, with a note asking whether you need one.
The trouble is that almost everything written about the role answers a different question. It's aimed at engineers deciding whether to take the job, with salary bands and interview prep attached.
If you run revenue or operations, the more useful question is whether the model behind the role is worth adopting, and what it would cost you in headcount, budget, and optionality.
So here's the model, the part that makes it expensive, and the three routes into it.
Key Takeaways
- A forward-deployed engineer is an engineer who works inside your environment rather than shipping you a product and leaving. The model came out of Palantir and spread through AI vendors who found that an API alone doesn't produce adoption.
- The role is scarce and priced accordingly. As of September 2026, OpenAI's San Francisco Forward Deployed Engineer posting lists $185K to $300K base plus equity and asks for 5+ years of relevant experience.
- Buying a vendor's deployment service isn't the same as hiring your own FDE. An engineer deployed by a vendor builds around that vendor's product, which is a reasonable trade until you want to change vendors.
- FDE, AI engineer, and GTM engineer usually focus on different problems. An AI engineer typically builds AI applications and models, an FDE adapts technology to work inside your walls, and a GTM engineer does similar work on the revenue side. Responsibilities can overlap.
- We already operate this way for revenue, building and running the work inside your HubSpot, Salesforce, or Clay account, improving it alongside your team, and documenting it so nothing is locked to us.
What Forward Deployed Engineering Actually Is
Forward deployed engineers work closely with customers to turn technical capabilities into working solutions in their environment. Their responsibilities can include integrations, deployment, debugging and feedback to the product team. The role varies by employer and engagement.
In practice, that often means joining your Slack, getting access to your systems, and shipping code that runs in your stack.
The model started at Palantir, which built it because its customers needed weeks of clearance before anyone could even run a demo.
Internally, Palantir called these engineers Deltas. Until 2016, the company had more of them than it had software engineers, which tells you the model was core to the business rather than a niche experiment.
On paper, that can sound a lot like consulting, and the two do overlap. Consultants implement and iterate too.
Embedding doesn't always mean a permanent desk in the customer's office or a single dedicated account. OpenAI's own FDE postings, for example, describe hybrid work with travel.
What usually sets the role apart is the feedback loop into a product. Everything the engineer learns inside one customer flows back to the product team, who generalize it for the next customer, and that loop is the reason vendors fund the role at all.
Bob McGrew was an early Palantir executive who helped pioneer the role, and later ran research at OpenAI. On Y Combinator's Lightcone podcast he covers:
- How Palantir invented the model, because its customers needed weeks of clearance before an engineer could even run a demo.
- How the Echo and Delta teams split the work between building the product and deploying it inside customers.
- Why AI companies are adopting the model now, having found that shipping an API does not produce adoption on its own.
Why Forward Deployed Engineering Is Suddenly Everywhere
AI vendors learned the hard way that shipping an API doesn't produce adoption.
The model works well in a demo, then stalls the moment it meets real data, real permissions, and a workflow nobody ever documented.
That gap between what a product can do and what a customer actually needs is where the forward-deployed engineering model lives, and it shows up well beyond AI.
Revenue teams hit the same wall when their CRM and data tools never get wired into how sales really works.
Whichever side you're on, somebody has to stand in that gap and close it, and it turns out that person needs to write code.
Once vendors realized that, they started hiring for the role.
It didn't take long for investors to notice and, in June 2025, a16z partner Joe Schmidt called it the hottest job in startups, in an essay arguing that AI companies should trade margin for moat by taking on implementation-heavy growth.
Then OpenAI went further in 2026 with an enterprise deployment program built around engineers embedded inside customer organizations. That's the clearest signal yet that this is a distribution strategy rather than a staffing trend.
The Catch Nobody's Writing About
All that demand has a price, and you feel it the moment you try to hire one yourself. As of September 2026, OpenAI's San Francisco forward deployed engineer listing sits at $185,000 to $300,000 base plus equity, and asks for 5+ years of relevant experience.
OpenAI's forward-deployed software engineer post is a separate role, and it asks for 7+ years of relevant experience.
Put together, you're hiring an engineer who can also run a room full of executives. Very few people fit that description, and you'd be competing for them against the best-funded companies in the market.
That's the obvious cost of hiring. The second one is quieter and takes longer to show up, and it applies when you buy a vendor's deployment service instead of hiring your own engineer. An FDE deployed by a vendor builds around that vendor's product, so the system you end up with assumes the vendor stays.
For core infrastructure you don't plan to replace, that's a fair trade. It gets expensive when you want to swap a tool two years later and discover the workflow was built around it rather than around your data. Call it the optionality problem. Both costs are worth weighing before you hire anyone or buy a deployment service, starting with whether an FDE is even the right kind of engineer for your problem.
FDE vs AI Engineer vs GTM Engineer
These titles show up in the same job searches, and on the revenue side the work can also come from a GTM execution partner. Each has a typical focus, although responsibilities often overlap.
| Role | What they build | Where they sit | Hire one when |
|---|---|---|---|
| AI engineer | The model, the evals, the inference pipeline | Inside the vendor, on the product team | You're building the AI capability itself |
| Forward deployed engineer | The integration that makes a product work in one customer's environment | Inside the customer, on their systems | A product you've bought isn't producing adoption |
| GTM engineer | The data, signal and routing layer underneath sales and marketing | Inside the revenue team, in the CRM and enrichment stack | Your stack holds the data, but nobody acts on it |
Even practitioners argue about whether the FDE role is actually new. On engineering forums like r/ExperiencedDevs, where developers keep asking what these openings really are, a recurring line is that a forward-deployed engineer is a technical consultant with better branding.
The counterargument, often in the same threads, comes down to commitment, though in practice how long an FDE stays with one account, and where they work from, varies by employer.
GTM engineering is where this gets practical for a revenue team, because it's the same model pointed at revenue instead of product. The engineer works inside your CRM and enrichment tooling, and the output is pipeline rather than a shipped feature. That's where we sit, as a GTM execution partner that uses technical implementation where the work requires it. If you'd rather bring in a team than hire, our breakdown of GTM agencies covers who does this work.
As for the AI FDE, it's the version of the role that has grown fastest, because AI deployments need more integration work than anything that came before them. The title is new, but the job is the old one with a model attached.
Hire, Build, or Partner
Once you know which role your problem calls for, there are three routes into the capability. The right one depends on where the problem actually sits.
| Route | What it costs | What you get | The trade |
|---|---|---|---|
| Hire an FDE | A senior engineering salary and equity, plus recruiting time and someone to manage the role | Permanent capability in-house, aimed wherever you point it | You're competing for a scarce candidate against better-funded buyers |
| Build the capability | Existing headcount, retrained, plus the tooling and ongoing maintenance | Full ownership, no vendor assumptions baked in | It comes out of the roadmap, and the learning curve is real |
| Partner with a team that operates this way | A scoped project, or an ongoing engagement where the partner keeps running the work | Experienced people building, running and improving the work inside your stack | You're trusting a vendor, so scope, access and success measures matter more than price |
Hiring makes sense when the work is permanent and central. If forward-deployed engineering is going to be a standing function, owning it beats renting it.
Building makes sense when you already have engineers who understand your data and the gap is time rather than skill. Whether it costs less depends on their current workload, who manages the work and who maintains it afterwards.
Partnering makes sense when you need experienced people on the work without adding headcount. That can be a bounded build, or a partner that stays to run and improve the work with your team.
The questions to ask any partner are what they will own, how progress will be measured, and whether the work lives in your accounts, documented, whoever runs it. That last answer is what protects you from the optionality problem.
Forward Deployed GTM, the Model Applied to Revenue
The useful idea for GTM is proximity to the work. The people designing the process should understand how the client sells, work with its real data and stay close to what happens after launch.
That is how Frontal works. We become an extension of the client's team and take ownership of the agreed execution across GTM Services, Ads, Content Engineering and RevOps.
For one client, that may mean building and running outbound. For another, it may mean paid campaigns, content and CRM workflows working together. We use the client's tools, document what we build and improve the work using campaign performance and sales feedback.
You can start with one service or bring several together around the same accounts and goals. GTM Services covers account selection, messaging, outbound and acting on buying signals.
Ads covers paid campaigns, audiences and creative, with reporting that ties spend to pipeline. Content Engineering turns your expertise into content the right buyers find. RevOps keeps CRM data, routing, reporting and attribution reliable for marketing and sales.
On the outbound side, for example, the work can start with a review of recent closed-won accounts, such as your last 50. What those accounts share becomes an ICP matrix, and the matrix defines the total addressable market worth building against.
From there, accounts get tiered, in one common setup into three bands, and scored against buying triggers such as funding rounds and key hires. When a signal fires, the account gets enriched and scored, and a specific sequence runs.
All of it runs on the same account list and CRM data, and that matters more than it sounds. Marketing in HubSpot, sales in Salesforce, and RevOps reconciling by hand in Clay are three answers to the same question, and the reconciliation is the work nobody budgeted for.
The goal is qualified pipeline and a better-run go-to-market operation. The engineering supports that goal. We've done this work for 250+ B2B companies.
Throughout all of it, experienced operators own the targeting, messaging, campaign approval and optimization, which is the part that separates this from the automated outbound filling your inbox. If you want to go deeper on the ads side, our ABM agencies breakdown covers the layer that runs against those same accounts.
What Forward Deployed GTM Looks Like in Practice
Here's what that looks like with named clients and defined metrics. Every number below is checkable on our case studies rather than simply asserted here.
| Client | Result | The work behind it |
|---|---|---|
| AirOps | $7.83M qualified pipeline and $1.52M closed-won revenue over 10 months, with no additional SDRs | A coordinated account-based program inside AirOps' HubSpot, with pipeline qualified by AirOps' own criteria |
| Teikametrics | $300K+ pipeline in nine months and 100+ hours saved monthly | Outbound automation we built with their team and kept improving through an ongoing collaboration |
| Design Pickle | From around 10 demos a week to 58 demos in 14 days | Meeting generation, counted as booked demos over a two week window |
Every one of those was built inside the client's own stack, so nothing sits in an account of ours that a client would lose access to.
The tooling is worth naming too, since it's the same stack the work runs on. Clay comes first, followed by Instantly, Smartlead, HeyReach, OutboundSync, HubSpot and Salesforce, with signals from RB2B, PredictLeads, UserGems and Common Room.
On the Clay side specifically, we're a Clay Elite Studio Partner, and our Clay agency breakdown covers who else builds at that level.
Is Your Company Ready for a Forward Deployed Approach?
The model fits best when a few things are true, and none of them require a staffed RevOps team or a particular funding stage.
| Better fit signal | Why it matters |
|---|---|
| The product has demonstrated demand | Campaigns can build on a real buying reason. |
| The team can explain its customers and sales process | We can combine that knowledge with research and performance data. |
| There is a clear execution gap | The engagement has a specific job to do. |
| Someone can provide access, approvals and sales feedback | We can launch and improve the work together. |
| Scope and success measures can be agreed | Both teams know what Frontal owns. |
The most common reason to wait is a sales team without room to take the meetings. A system that produces conversations nobody has time to take is an expensive way to generate guilt.
FAQs About Forward Deployed Engineering
What is forward deployed engineering?
It's a delivery model where engineers work closely with customers inside their environment, building against real data and real constraints rather than handing over a product and a manual. The approach started at Palantir and spread through AI companies that found an API alone didn't produce adoption.
What does a forward deployed engineer do?
They work closely with customers to turn technical capabilities into working solutions in that environment, which can include integrations, deployment, debugging and feedback to the product team. The role varies by employer, and job posts typically ask for several years of engineering experience plus the ability to run a room of executives.
What's the difference between an FDE, a GTM engineer, and an AI engineer?
An AI engineer typically builds and operates AI applications, models or the infrastructure behind them. A forward-deployed engineer typically adapts and implements technology inside your environment. A GTM engineer does similar work on the revenue side, in the CRM and enrichment stack, and the output is pipeline. Responsibilities can overlap, and practitioners sometimes call the FDE a technical consultant with better branding.
Should we hire an FDE or partner with an agency?
Hire when the work is permanent and central enough to justify a senior engineering salary and a long search. Partner when you need experienced people on the work without adding headcount, either for a bounded build or to keep running and improving it. Ask any partner what they will own, how progress will be measured, and what you keep if the engagement ends.
What is an AI FDE?
The same role aimed at AI deployments specifically. It has grown fastest because getting a model into production takes more integration work than earlier software did, covering data access, permissions, evals, and workflow, none of which an API solves on its own.
What is forward deployed GTM?
The same model applied to revenue. Instead of an engineer embedding to make a product work, a team works as an extension of yours, inside your existing tools, and takes ownership of agreed sales and marketing execution, then keeps running and improving it.
When is a company ready for a forward deployed approach?
When the product has demonstrated demand, the team can explain its customers and sales process, and there's a clear execution gap. It also helps to have someone who can provide access, approvals and sales feedback, plus agreed scope and success measures. A staffed RevOps team or a particular funding stage isn't required.
Bring the Forward Deployed Model to Your GTM
You don't have to win a bidding war for a forward-deployed engineer to get the model working on your revenue. That's the partner route from earlier, and it's the one we run.
We work as an extension of your team, starting with the work you need most, inside the HubSpot, Salesforce, or Clay account you already pay for. We keep running and improving it with you, and everything is documented, so the system stays yours whoever runs it. No optionality problem.
We won't promise a meeting count. We'd rather be judged on the pipeline in your CRM.
Book a 30-minute call to tell us where execution is getting stuck, and we'll discuss the work we could own and how we'd measure progress.
