前沿部署工程的起源：DevOps与平台稳定性（2008–2012）
在建立这种客户界面的技术边界之前，我们需要理清前沿部署工程师（Forward Deployed Engineer: 派驻客户现场、直接对业务结果负责并编写代码的工程角色）的历史演变。演讲者 Natalie Meurer 在加入 Sierra 之前，曾于 2016 到 2021 年在 Palantir 担任基础设施工程师和前沿部署工程师。在 2008 年左右的早期阶段，前沿部署工程（FDE）的本质更接近于 DevOps（Development and Operations: 软件开发与运维合一的实践体系）。由于当时 Palantir 的系统大多需要在客户本地（on-prem）环境进行部署，工程师必须物理上驻扎在客户现场。当时的平台稳定性极其脆弱，Natalie 回顾自己刚加入 Palantir 时的入职项目，仅仅是将软件部署到一个 EC2 实例上。早期的工作充斥着大量的平台维护和救火任务，比如在凌晨两点收到客户邮件，告知由于有人不小心拔掉了服务器的电源，导致实例断线，需要 FDE 立即接入并排查运行时问题。
Original English Source
>> Thanks guys for coming. I know right after lunch, this is like prime time like sleepiness. I'm curious just to get a sense for the audience. Who here is a forward deployed engineer? Okay, who here is hiring for a deployed engineers? Okay, helpful. Anyone else in between? You can raise your hand just like if if I didn't cover it. Okay. I see you. Double double hand raise. Um well, I'm Natalie Mier. I am the um head of agent engineering at Sierra. I've been at the company about 2 years. I'll tell you a little bit about that. But honestly, I'm here to talk about forward deployed engineering. So, we're actually going to spend a little bit less time talking about Sierra and a lot more time talking about the history of forward deployed engineering and and the dirty secret, I like to call it, of the domain. And you all can tell me how controversial it is. So, um just a little bit about me, which will give you a sense for sort of how I'm coming at this domain, at the whole domain of forward deployed engineering. I actually started off as a policy nerd. So, I was at Georgetown. Um I studied uh in the School of Foreign Service there. And so, I was obsessed with basically tech policy. I um learned to code and then swindled my way or earned my way, depending upon your perspective, into a job at Palantir, where I spent 2016 to 2021. And um there I worked on the privacy team and I was a an infrastructure engineer and also a forward deployed engineer with law enforcement and defense primarily. So, I I've seen forward deployed engineering up close and I'm going to talk a lot about the history of not just my time at Palantir, but actually the time that predated me to talk about basically the origins of the entire discipline. And then I actually wanted to get a business degree of all things, so I went to Stanford. And now I'm at Sierra from 24 to to 26. And one of the things that I think is is quite interesting and when I started at Sierra, actually a little known fact is that I joined the deployment team. and at the time I hated the name. I I thought this is not what we're doing and B it sort of is a nonsensical name so to speak and so I actually wrote an an an article in July of 2024, so about 6 months after I started, um about 2 years ago now, on this concept of the agent engineer. And the idea was that agent engineering was actually a subdiscipline of AI engineering which we're of course here to talk about. And the vision was that agent engineering had the same level of customer accountability as forward deployed engineering but was actually a domain onto itself. And I think since then, you know, in the past 2 years we've actually seen a lot of folks talking about agent engineering as a discipline and now we're actually seeing harness engineering as sort of a new discipline sort of is almost a subset of agent engineering. And so if you're confused, that's sort of what this talk is about. And so the dirty secret of forward deployed engineering, I won't make you wait until the end, is it doesn't exist. It is a term that it is meant to describe so many things that it sort of means nothing at this point. But nonetheless, it's sort of the hottest job in AI. And so what I hope to convince you of over the next, let's say, 15 minutes is A that this is true and B that this doesn't matter. And so um I'm going to dive in and we're going to start with tracing the history of forward deployed engineering from Palantir. So we're going to start in 2008. We're going to basically come back to the present and then I'll share with you at least my perspective on what forward deployed engineering is today, why you should want to or not want to be a forward deployed engineer, and why we're actually all forward deployed engineers in the end. Um so first off, I I'd like to start in 2016 and then we'll go a little back in time. And I actually pulled basically Palantir job postings in 2016. This is when I started and what drew me into Palantir was effectively this concept of a forward deployed software engineer and this was an emphasis on the forward deployed part. I mean, they're leading. These days you lead with, you know, you speak a certain language, you have these skill sets. They were leading with location. And there's a reason for that that we'll get to, but but forward-deployed literally meant sitting with customers, being on the ground. And in part, as we'll talk about, this was because so much of Palantir's um ecosystem was on-prem deployments. And so, when we think of forward-deployed engineering though, we kind of think of this. And so, um this is sort of the prototypical forward-deployed engineer right out of college um parachuting out of a helicopter um and of course, you know, fixing some sort of runtime issue um in the air. But in practice, forward-deployed engineering actually started as something more akin to DevOps. And so, platform stability really constituted the bulk of the job early on. And so, when you think about um what forward-deployed engineering actually was, don't worry about understanding this code on the right, but it just gives you a sense for what what folks were actually doing. In fact, my onboarding project at Palantir was actually deploy the software on an EC2 instance. And so, that was literally the job. And it was a a large part of the job, and so much so that um basically the job felt like this, which is basically an email from the customer telling you that someone mistakenly unplugged um the instance again. Hey, could you look into it? By the way, it's 2:00 a.m. and you need to go in. Um and so, in practice, a lot of the early forward-deployed engineering was was really focused on DevOps.数据集成的演进与本体建模（2012–2016）
在解决了最初的部署稳定性问题后，具体的工程重心转向了数据集成。到了 2012 年，随着 Palantir 平台本身日趋稳定，FDE 的工作性质发生了关键变化。数据集成软件在没有集成数据的情况下是毫无用处的，就像“一家什么电影都不放映的电影院”。当时的销售策略面临着巨大挑战，因为客户的数据往往零散地分布在几十个不同的源头。为了解决这一痛点，FDE 承担了双重角色：DevOps 加上数据集成。工程师必须深入理解客户复杂的 IT 环境，将碎片化的原始数据进行清洗、抽取，并在系统内抽象成统一的本体（Ontology: 描述实体及其相互关系的语义数据模型），即为该数据建立分类体系。当时这些集成逻辑大多使用 Java 编写，甚至 Palantir 的客户端也还是基于 Java Swing 开发的。在这个阶段，FDE 的核心价值在于建立坚实的数据底座，使上层分析软件得以运转。
Original English Source
And come 2012, the the Palantir platform got a lot more stable. And Palantir built data integration software. So, quick show of hands, everyone here probably knows, but who here knows what data integration software is? Great. Anyone think data integration software is really useful without data? Okay. Oh, okay. One All right. I'm curious to hear your take after. Um So, um so I like to think of data integration software without integrated data as a movie theater that's playing nothing. It's like, why show up, you know? And so, this is basically what Palantir was selling without forward deployed engineers. A, the movie theater wasn't standing in 2008. By 2012, you actually don't have data in it, right? You don't have movies playing. And so, you sort of have this basic, um you know, comic explaining this this process, which is, "Hey, great. We have this data integration software, isn't it useful?" Right, but my data's in 20 places, and now you actually have a forward deployed engineer that needs to go in and integrate that data. And most of this was written in, you know, variants of Java back in the day. Um as was actually Palantir's client, fun fact, in Java Swing, if anyone here has had the privilege to to use that. Um So, so basically, forward deployed engineers now have this dual role, right? DevOps plus data integration. And so, they wanted to to deeply understand the customer's environment to to model that data appropriately. And what Palantir uh did then and now still does call an ontology, which is sort of a famous Palantir um term of art. But you can think of it as a taxonomy for that data.自定义方案与看板构建（2016–2020）
在数据集成管道打通后，接下来的系统反馈挑战在于“如何使数据对业务真正有用”。在 2016 年左右，FDE 开始专注于针对已知业务问题构建自定义解决方案（Custom Solutions）。这在当时主要表现为构建 Slate 看板。Slate 是 Palantir 平台内部的一个拖拽式界面构建工具（类似于 Retool），允许工程师将页面上的前端组件直接映射到后端数据源。因为 FDE 是最理解底层数据结构的人，所以他们也是最适合将这些数据转化为决策辅助界面的人。这随后过渡到了 Palantir 目前的核心产品 Foundry 时代，其核心理念即为“从数据到决策”。在此期间，行业得出了一个痛点教训：一个无法将决策“写回”（write back）底层数据源的单向看板，其业务价值会随时间迅速衰减。因此，如何闭环数据流、在界面上直接触发业务写入，成为了这一时期 FDE 解决的核心技术难题。
Original English Source
And then 2016 rolled around, and you have custom solutions. So, folks are building effectively solutions to known problems. Um and usually that took the form of a Slate dashboard. Has anyone here heard of Slate? This was sort of an internal Okay. All right. Um so, Slate was basically um a drag-and-drop builder. It actually still exists as part of Palantir's platform. It allowed you to map, similar to Retool actually, um map components on the page to data sources. So, now you have the data, and then the question became, "Okay, how do we make it useful?" And the the person or the individual or the group that was most well situated to make that data useful was the the individuals that most understood that data, which were the forward deployed engineers. And so, um the this basically era of of Slate actually gave way to an era of Foundry, which is Palantir's main platform today. And the era of Foundry was effectively all about um making data useful. So, Palantir had this phrase of uh going from data to decision-making, which was was sort of the core problem. One of the things they found, a spoiler alert for anyone building a dashboarding platform, is that a dashboard that doesn't write back to the data source isn't that useful. That these things would decay over time and actually not be as useful as they could be.客户赋能、规模化与通用人才培养（2020–2024）
临近 2020 年上市，Palantir 面临着一个典型的商业化悖论：不可能依靠无限派驻工程师到赫尔辛基或堪培拉等世界各地来维持公司业务的增长。为了打破人力瓶颈，公司开始转向客户赋能（Enablement），将 FDE 的职责定义为教会客户自己使用平台。以 Palantir 与空客合作的 Skywise 项目为例，其核心就是赋能数千名空客内部工程师在 Foundry 上自行完成本属于 FDE 的数据建模和分析工作。如今，这种模式演化为了通过 AIP（Artificial Intelligence Platform: 包含大语言模型能力的数据集成与业务决策平台）和 AIP 训练营（AIP Bootcamps），利用 LLM 辅助用户完成类似的工作。这种多维度的实操历练，使得 FDE 成为了培养全栈通用人才的极佳温床。FDE 必须在技术深度、客户沟通、业务理解之间反复横跳，这也正是许多 Palantir 校友在离开后能够成功创办初创公司的底层原因。
Original English Source
Fast forward to 2020, you know, Palantir is on the verge of IPO. And they also need a solution that doesn't involve shipping people out to Finland or Canberra or choose the kind of location on the earlier slide of your preference. And um they actually wanted to empower customers to do more of this work themselves. And so, this is where Palantir really started to become a platform. And the job of forward deployed engineering still involved the first three, but it also involved enablement of those customers. So, if you look at the work that Palantir's done with Airbus, for example, in Skywise, that was focused on enabling thousands of Airbus engineers on the Foundry platform to do work of the forward deployed engineer. And these days, they actually have a platform uh since I left called AIFTE that's focused on leveraging uh large language models to do similar work. So, this is the timeline, and you'll see that it's not one thing. And so, this is a a picture of uh Alex Karp, and I think we might have lost the photo um over over here, but of Alex Karp basically running an AIP bootcamp. So, this is basically where the forward deployed engineers or the deployment strategists would go in and actually teach customers to use the software. So, what's interesting about this is these weren't discrete eras, right? The total FTE jobs to be done actually increased over time. Maybe they peaked at one point, but they actually grew over time. And so, now we have a world come 2020, 2024 where the role of FDE sort of doesn't mean anything quite yet or it means everything, right? It's actually the best training ground for generalists. And in fact, this is why I would say that Palantir has seen such success Palantir alums founding companies is because it's actually training you on all of these different facets of the role. And so I have an idea that I like to think of that you all can ask your next candidate if you're interviewing for for engineering role. Which is what vintage of FDE are you? Are you the 2008 vintage of platform stability with hints of panic. 2012, 2016 2020 or even you know today. What is what is the forward deployed engineer of today? And so that I like to call this the FDE vintage and you might debate the years and debate the details, but just like fine wine, I think there's a particular vintage of an FDE.AI时代的FDE复兴与角色合流（2026+）
进入 2026 年，FDE 的角色正在全行业范围内经历一场大复兴。谷歌云（GCP）正在大力招聘客户工程师，OpenAI 也建立了专门的团队以推进企业级 AI 的落地，Aaron Levie 等行业领袖也在社交媒体上频繁发声。然而，今天的 FDE 角色所要求的技能复杂度前所未有地提高——仿佛需要工程师同时具备 8 年的 Staff Engineer 资历、6 年直接销售经验以及 4 年解决方案架构师的背景。
然而，在 AI 时代，当代码可以通过编码智能体（Coding Agents: 能够自主执行软件开发任务的 AI 助理）以极低成本快速生成时，FDE 的实操边界发生了根本性重塑。前沿部署工程师可以利用 AI 智能体直接搭建端到端的解决方案。同时，产品工程与前沿部署工程的界限正在模糊：优秀的产品工程师必须直接面对客户以获取最真实的系统反馈，而前沿部署工程师也能直接将代码贡献回核心产品中。
Original English Source
So welcome to 2026. Here we are and FDE is absolutely everywhere. So I'm sure you all have heard Google recently announced with GCP an effort to hire customer engineers or FDEs. Open AI created a new unit with a massive investment to aid the corporate AI push. You have folks like Aaron Levie basically posting on X as as well as many others about just how important this work is today. But if you think as about what we just saw, the work isn't one thing, right? So forward deployed engineering is actually many things all at once. And in fact, today if you look at basically what it takes to be a forward deployed engineer, you were to combine all the job postings into one, you'd probably see something like this. You know, I don't know how many of you have been a staff eng for eight years with six years of direct sales experience and four years as a solution architect. Also, I don't know if you've taught in schools prior because that would help as well. And this is actually what it feels like hiring for these deployed roles as I've done for the past, you know, 2 years, 2 and 1/2 years or so. Um, but this is actually what's being asked of forward deployed engineers today. And so you think about the the dirty secret that it doesn't exist and actually it it either doesn't exist or maybe it actually exists too much. Hard to say. Um, and part of this, I think, and part of sort of um, I think the importance of the role is that across all of those different aspects of the role, the one continuity point is that you actually have every single forward deployed engineer accountable to the customer, whether that be for devops, for enablement, whether that be for custom solutioning, data integration. These are all forms of solutions or customer accountability. And when that happens though, I I ask the question, you know, what happens to engineering broadly, even outside of forward deployed engineering, when code becomes cheap to produce? When it becomes really quick to fire off a prompt to a background agent and get something pretty great on the other end. And one way to think about this is forward deployed engineers being accountable to customers and trying to translate that signal into the product, either to make it more stable or to drive more data integration. And so what this allows you to do as a forward deployed engineer today is actually be way more impactful in product development. So forward deployed engineers can now not just talk to customers, not just prototype, but actually build end-to-end solutions with coding agents. But I think something more interesting is happening that we're seeing at Sierra, which is actually the lines are blurring. So product engineering is also becoming more client-facing. And so if you're a good product engineer, if you're a good forward deployed engineer, you should be thinking about the product and the customer both together. And so one of the reasons that folks are talking about forward deployed engineering as so essential to where we are at this point in time is that it's actually converging. Forward-deployed engineering is in some ways actually getting larger than we ever thought it was before. So, it's actually stacking more skills on top. And if you're a product engineer, even an infra engineer, you should also be thinking about DevOps, right? How do you actually deploy the software?结果导向型定价与工程的未来趋势
最后，商业模式的演变正在彻底改变软件工程的评估体系。传统的软件销售依赖于席位制定价（Seat-based Pricing），即客户为软件使用人数付费。而 Sierra 倡导并践行的是结果导向型定价（Outcome-based Pricing），客户只为软件真正交付的业务成果（如成功解决一次客户咨询或完成一笔交易）付费。在基础模型提供商（如 OpenAI、Anthropic）占据主导地位的当下，虽然有些采用按 Token 数量收费的使用量导向定价（Usage-based Pricing），但对于企业级 AI 应用而言，未来的终局一定是结果导向。
在结果导向的商业模型下，如何保障业务结果的达成成为了生死存亡的关键。Natalie 曾于 2024 年提出智能体工程（Agent Engineering）是专注于结果交付的 AI 工程子领域。而在 2026 年的今天，这一视角被进一步拓宽：一切工程都在向 FDE 靠拢。无论是产品工程、智能体工程、AI 工程还是解决方案工程，其终极目标都是为了代表客户在生产环境中交付可量化的业务价值。“前沿部署工程已死，前沿部署工程万岁。”