The Dirty Secret of Forward Deployed Engineering

Are you a forward deployed engineer, or are you hiring one? Natalie Meurer opens with those two questions. They identify two sides of the same problem: engineers and employers are using a job title whose responsibilities can differ dramatically between teams.

Meurer approaches that problem as Sierra’s head of agent engineering, after roughly two years at the company. Her path began with tech policy at Georgetown’s School of Foreign Service, followed by learning to code and joining Palantir. From 2016 to 2021, she worked on privacy, infrastructure, and forward deployment, primarily with law enforcement and defense customers. After business studies at Stanford, she joined Sierra in 2024—on a team then called the deployment team.

The name bothered her because it did not describe what the team was building. In July 2024, about six months after joining, she published Meet the AI agent engineer. Her initial distinction was useful: agent engineering was a subdiscipline of AI engineering with the same customer accountability as forward deployed engineering, but with its own technical domain. As agent engineering gained currency, harness engineering began emerging as a possible specialization within it. The vocabulary kept expanding.

That proliferation leads to the talk’s provocation: forward deployed engineering “doesn’t exist.” The work certainly exists; the trouble is that the label describes so many kinds of work that it no longer specifies a coherent discipline. Its popularity in AI makes that ambiguity more consequential. To understand what a forward deployed engineer actually does, follow the responsibilities that accumulated under the title—from platform operations to customer outcomes.

The Palantir job postings that attracted Meurer in 2016 led with location. Where a contemporary engineering advertisement might emphasize languages and technical skills, these emphasized the forward deployed part: sitting with customers, on the ground. Much of Palantir’s ecosystem consisted of on-premises deployments, so physical proximity was part of delivering the software.

The comic stereotype is a new graduate parachuting out of a helicopter while fixing a runtime error. The early job was more recognizably DevOps: platform stability occupied much of the work. Meurer’s own onboarding assignment was to deploy Palantir’s software on an EC2 instance. Before an engineer could make the product useful, the installation had to work.

Her illustrative customer email captures the operational reality: someone has unplugged the instance again, and the engineer needs to come in at two in the morning. Customer accountability initially meant restoring availability. The product’s immediate bottleneck was not another feature; it was a running system.

Looking back to around 2012 in Meurer’s chronology, greater platform stability exposed the next problem. Palantir sold data integration software, but software without integrated data was like a movie theater playing nothing. In the analogy, the theater was not standing in 2008; by 2012, it stood, but there were no movies to watch.

The customer’s response to a functioning platform was that the data still lived in 20 different places. Forward deployed engineers had to connect those sources. Much of that integration work used variants of Java; Meurer also recalls Palantir’s client being written with Java Swing. The job now included DevOps plus data integration, rather than replacing operations with a new specialty.

Integration also required understanding what the records meant in the customer’s environment. Meurer describes Palantir’s ontology here as a taxonomy for the data. For example, one source can call a customer key customer_id while another calls it account_id. Mapping both into one customer object requires understanding whether they actually identify the same business entity. Proximity to the customer mattered for that decision as well as for deployment.

By 2016, custom solutions added another responsibility. Engineers built applications for known customer problems, often as Slate dashboards. Meurer describes Slate as a drag-and-drop builder, comparable to Retool, that mapped components on a page to data sources. Once the data was available, the next question was how to make it useful. The engineers who understood that data were well positioned to answer.

In her account, the Slate era gave way to Foundry and a broader focus on moving from data to decision-making. That progression exposed a limitation of dashboards: displaying information does not necessarily complete the customer’s workflow. Meurer’s lesson is that dashboards without writeback to the data source lose usefulness over time. A useful operational application must support acting on the data, not just looking at it.

Around 2020, as Palantir approached its IPO, sending engineers to Finland, Canberra, or every other customer location was not a sufficient scaling strategy. Customers needed to do more of the work themselves. Enablement became another part of the role, alongside platform stability, integration, and custom solutions.

Meurer cites Airbus’s Skywise work as enabling thousands of Airbus engineers to perform forward deployed engineering work on Foundry. That is her account of the enablement effort, rather than a measured training result. She then points to AI FDE, introduced after her departure, as using large language models for similar work. AIP boot camps represent the teaching side of the same progression: forward deployed engineers or deployment strategists help customers learn the software. She invokes Alex Karp running a boot camp as an example.

These were overlapping responsibilities, not clean replacement eras. The total set of jobs grew, producing the kind of generalist training that Meurer credits with helping Palantir alumni become founders. For hiring, that suggests a more informative question than whether someone has held the title: which vintage of FDE are they?

Her wine analogy gives the earliest vintage “hints of panic.” The years and boundaries are open to debate; their practical value is distinguishing the work a candidate has actually done. A title alone does not tell you whether someone’s strongest experience is operating installations, modeling data, building applications, or teaching customers.

By 2026, the label appears across the AI industry. Meurer points to GCP hiring customer engineers or FDEs, OpenAI’s corporate deployment push—represented by the OpenAI Deployment Company announcement—and Aaron Levie’s posts about the importance of this work. But widespread demand does not make the job a single discipline.

Her satirical composite job posting asks for eight years as a staff engineer, six years in direct sales, four years as a solutions architect, and, ideally, prior teaching experience. It captures how hiring can turn accumulated responsibilities into an implausible candidate specification. After roughly two to two-and-a-half years hiring deployed roles herself, Meurer recognizes the pressure to ask one person to cover all of them.

Customer accountability is the continuity beneath the changing job description. An engineer restoring availability, integrating data, building a custom solution, or enabling a customer is responsible for making the software work for someone. That shared responsibility explains the role better than any particular language, framework, or deployment location.

What happens to this division of labor when an engineer can prompt a background coding agent and quickly get useful code back? Forward deployed engineers already translate customer signals into product needs: more stability, better integration, or a missing workflow. Coding agents extend their ability to act on those signals. They can move beyond conversations and prototypes to building end-to-end solutions.

Meurer reports a complementary change at Sierra: product engineering is becoming more client-facing. The two roles approach the same relationship from opposite directions. Forward deployed engineers bring customer understanding into the product; product engineers increasingly bring product expertise directly to customers. Good engineers in either role need to think about both together.

The convergence adds responsibilities rather than making operational work disappear. Product engineers—and infrastructure engineers—still need to understand how software gets deployed. At the same time, cheaper code changes the commercial question: what should customers pay for? Meurer turns to work from Emergence Capital and Sierra’s head of go-to-market operations, Elliot Greenwald, whose Outcomemaxxing develops the pricing argument.

Sierra’s stated pricing principle is that customers should pay a software platform for the value it delivers. Applying that principle depends on whether the product can be credited with the outcome. When attribution is weak, charging for a result is difficult; seat pricing has long provided a way to sell access without claiming responsibility for the final result.

The framework introduces a second dimension: agency or autonomy to achieve the outcome. Attribution asks whether the result can be connected to the product; autonomy asks how much of the work the product can accomplish. Agents can move software upward and rightward on those dimensions, toward doing the work and being accountable for its result.

Payments to OpenAI or Anthropic illustrate usage pricing: consumption is measurable even when the downstream outcome is hard to attribute to the model service. In customer experience, completing a sale or resolving an inquiry can provide a more direct outcome. Meurer predicts that most pricing in this market will move toward outcomes; that forecast depends on the product’s ability to achieve and substantiate those results.

Combine engineers who can contribute directly to the product with a business that charges for results, and the unresolved question becomes concrete: who guarantees the outcome? Meurer identifies that responsibility with forward deployed engineering. The role connects the product’s capabilities to the customer’s actual result.

That changes her original taxonomy. In 2024, agent engineering looked like a distinct, outcome-focused specialization—a flavor of forward deployed engineering. Now she sees product engineering, agent engineering, AI engineering, solutions engineering, and customer engineering converging on the same responsibility. Her qualified claim is that everything is forward deployed engineering, or at least trending that way.

The work still includes enablement, DevOps, solution building, data integration, building agents, and deploying them into production. Each activity contributes to delivering something for a customer, and Meurer argues that pricing should reflect the associated outcomes. The title may lack a coherent technical boundary, but the obligation it expresses remains useful.

That is the force of her closing paradox: “forward-deployed engineering is dead” and “long live forward-deployed engineering.” A narrowly bounded discipline is giving way to a broader expectation that engineers own customer results. Sierra, she adds, is hiring across those forward deployed engineering roles.