# What forward deployed means
A job title that was one company's internal jargon three years ago is now the most contested role in AI. What it actually is, why it came back, and what it should leave behind.
- Published: 2026-09-18
- Type: Perspectives
- Topics: transformation, sovereign-ai, enterprise-context
- Canonical: https://hellofig.io/blog/what-forward-deployed-means
**In short.** A forward-deployed engineer works inside the customer's institution, on its systems, and is accountable for software running in production rather than for a recommendation. The role came back because AI does not work until it is wired into an institution's context, and that wiring is the work. This year the largest AI companies have hired thousands of them. The question that separates good forward deployment from bad is not talent but ownership: whose asset does the work become. At Fig the engineers deploy the platform we build, route across every lab, and leave the institution owning what they built.
---
Three years ago "forward-deployed engineer" was internal vocabulary at one data company. This year it is the most sought-after title in enterprise AI. Researchers estimate the five largest AI companies have hired more than 9,000 forward-deployed engineers in the last eighteen months, alongside four acquisitions of firms founded by people who learned the model at its source. Base pay for the role at the frontier labs is reported at $160,000 to $280,000 for mid-level engineers in San Francisco, more than almost any engineering job outside research.
The reason is not fashion. MIT's study of enterprise AI deployments found that 95 percent of pilots produced no measurable impact on profit and loss, and its authors were clear that the models were not the problem. The problem was getting them into the work. Forward deployment is the industry's answer to that finding, and like most answers adopted in a hurry, it is being copied in form more often than in substance.
This piece is about the substance: what the role actually is, why it came back, what the market looks like now, and the one question that decides whether an institution comes out of a forward-deployed engagement stronger or more dependent.
## What the role is
A forward-deployed engineer works inside the customer's institution, on the customer's systems, and is accountable for software running in production. Each clause matters, and each distinguishes the role from something it is often confused with.
| | Consulting | Software plus professional services | Forward deployed |
| --- | --- | --- | --- |
| Where they work | On site for the engagement | Remote, ticket by ticket | Inside the institution, in its meetings and systems |
| What they deliver | A recommendation | A configured product | Software running on real work |
| Accountable for | The quality of the analysis | The implementation scope | The outcome in production |
| When they find a gap | A new phase | A change order | A fix in the product or the build |
| Who made the promise | A partner who leaves | A salesperson who is not there | The same people doing the work |
That last row is the original insight behind the model, and it is still the most important one. In ordinary enterprise software the person who promises what the product will do is not the person who has to make it true. Forward deployment collapses the two. The engineer who says it will work is the one who stays until it does.
What they actually do all day is less glamorous than the title suggests and more valuable. Every institution runs on knowledge that no system holds: which of three customer records is the real one, why the approval chain has an exception in one region, which spreadsheet the finance team trusts, what the senior operator does when the standard process fails. Call it the institution's dark matter. The forward-deployed engineer's job is to find it and turn it into something software can act on: an [ontology](/blog/what-an-ontology-is-for) of the objects the business runs on, a [decision model](/blog/agents-need-your-decision-model) of who decides what, integrations to the systems that hold the pieces, and the agents and applications that use all of it. One description of the role that has stuck is to act as if you are the CEO, but with zero authority. It is a good description. The engineer has to understand the whole institution and change nothing without the people who own it.
The work is turning what an institution knows into structure software can act on. The structure is what stays.
## Why it came back
For two decades the rule in enterprise software was that services were a tax. Investors wanted gross margins near 80 percent, which meant a product that customers could install and configure themselves, and anything that required people on site was treated as a sign the product was not finished.
AI broke that rule, because the product does not work until it is wired into an institution's context, and the wiring is specific to every institution. A model that can do almost anything does almost nothing useful until someone connects it to the right records, teaches it the approval rules, and measures it against the standard the institution actually applies. That work cannot be self-serve, because the knowledge it depends on is not written down anywhere.
Andreessen Horowitz described the resulting economics as trading margin for moat: spend margin on deployment now, because what gets built in the process is hard to displace later, the way the implementation work of the last platform shift underpinned ServiceNow's 79 percent and Workday's 75 percent gross margins in 2024. Palantir's own results are the proof that the trade can pay at scale. Between the second quarters of 2023 and 2026, its year-over-year revenue growth went from 13 percent to 93 percent and its operating margin from 2 percent to 47 percent. Forward deployment is not the opposite of a software business. It is how you build one when context is the product.
## What the motion looks like now
In September 2026 there are three kinds of forward-deployed engineer in the market, and they differ less in skill than in what their employer sells.
**The model lab's engineer.** Embedded to deploy one lab's models into the customer's systems. Usually excellent on the model, and structurally limited to one answer about which model to use. When a different lab's model is better for a task class, which happens monthly, the engineer is not the person who will say so.
**The services firm's engineer.** The large integrators have rebranded delivery teams as forward-deployed, and the labs are now competing with them directly for the same budget. Broad, experienced, and working with someone else's product, so when the product falls short the gap becomes a change order rather than a fix.
**The platform's engineer.** Embedded to deploy a platform their own company builds, so the gaps a rollout uncovers get fixed in the product rather than worked around, and the next customer benefits. This is the model we run.
Much of the public argument about forward deployment this year is about which of these is more righteous, and we do not need to settle it. But underneath it is a practical question every institution should ask of any company that sends it forward-deployed engineers, and it is the one that decides whether the engagement leaves the institution stronger.
**Whose asset does the work become?** A forward-deployed pod spends months turning an institution's dark matter into structure. If that structure lives in the vendor's configuration, trains the vendor's models, or cannot be moved, then the institution has paid to transfer its know-how to a supplier, and the better the engineers were, the more it transferred. If the structure is documented, exportable, and the institution's own, then the engagement has built an asset. The individuals can be equally talented in both cases. The difference is the contract and the architecture, and it is the same distinction we drew between [owning and building](/blog/what-to-build-and-what-to-buy).
## How we run it
Fig's forward-deployed engineers work in pods embedded in the customer's environment, on the platform the company builds. The engagement follows the work rather than a methodology deck.
**Start from the data and one live workflow.** The [audit](/transformation) baselines how a consequential workflow runs today and what it costs. Nothing is built before there is a number it has to beat.
**Model the context before building on it.** The pod works in the room with the people who own the workflow and models the objects, actions, owners, and thresholds it depends on, from the systems that already hold most of them. Access and governance questions get solved in that room rather than filed as tickets.
**Build what only this institution needs.** Integrations to the systems of record, including the ones without an API. Agents and workflow logic for roles nobody else has. Bespoke internal tools and customer-facing surfaces where the workflow needs them. Everything else is the platform.
**Measure it.** The [eval set](/blog/why-evals-matter) is assembled from the workflow itself, with reviewer corrections as the labels, and nothing widens without clearing it.
**Stay model-agnostic, on the evidence.** Because the pod is not selling one lab's model, the question of which model runs which task class is answered by measurement, and when a narrow, high-volume task justifies it, the pod [post-trains a model](/blog/should-i-train-my-own-model) on the institution's own examples.
**Hand it over.** The institution's engineers and administrators work alongside the pod from the first week. The share of the work the pod does falls as theirs rises, and when the pod steps back, the capability stays, along with every integration, agent, eval case, and piece of context, in the institution's own library.
Illustrative. A good engagement is measured by how little it is needed at the end, and by what it leaves behind.
## What it is worth to an institution
The reason to bring in forward-deployed engineers rather than buy a product and hope is that the value of AI sits in the institution's specifics, and someone has to do the work of reaching them. What that work produces is measured against the baseline on four levers, and one asset.
**Alpha.** What differentiates an institution is its know-how: how it underwrites, how it serves, how it decides. A forward-deployed engagement done right captures that know-how into structures the institution owns, where it compounds with every workflow added. Done wrong, the same know-how compounds for a supplier. This is the asset, and it is the point of the [sovereign AI](/blog/sovereign-ai-the-operating-playbook) argument we have been making all month.
**Cost.** The bill goes down rather than just the number of steps. Routine work runs on efficient models and frontier reasoning is reserved for where it earns its price, commodity plumbing is rented rather than rebuilt, and the institution does not have to hire a scarce and expensive AI engineering team of its own to get there.
**Time.** Most cycle time in an institution is waiting: for a handoff, an approval, a record re-keyed between systems. Those are exactly the seams an embedded team can see and a remote one cannot.
**Revenue and control.** Faster, better work where it meets customers, and new work that was not possible before. And from the first day, approvals on anything irreversible and a record of everything that ran, so the institution can widen what it trusts on evidence.
## Key takeaways
- A forward-deployed engineer works inside the institution, builds software rather than recommendations, and is accountable for the outcome in production. The person who promises it is the person who delivers it.
- The role came back because AI does not work until it is wired into an institution's context, and that wiring cannot be self-serve. Trading margin for moat is how software businesses get built when context is the product.
- This year the model labs, the integrators, and the platforms all send forward-deployed engineers. They differ less in talent than in what their employer sells.
- The question that decides the outcome is whose asset the work becomes. The right answer is the institution's, in a form it can read, move, and build on without the people who built it.
The best forward-deployed engagement is the one an institution no longer needs at the end, and is glad it had.
