FDE中国

The Pulse: Grok’s CLI caught uploading all your local files to the cloud

Mon, 07 Sep 2026 12:04:12 +0000

做交付这些年，这件事里最让我后怕的不是上传本身，而是 xAI 用一个远程 feature flag 就悄悄停掉了数据收集——这恰恰证明你在安装时做的任何安全审计都可能随时失效：今天能关，明天就能再开。所以企业里跑任何 agent CLI，都不该指望“设置项”保护数据，唯一可靠的防线在网络出口：让 agent 运行在隔离沙箱里，egress 白名单只放行模型 API 端点，任何指向对象存储的流量一律掐断。我们给客户部署 AI 工具的铁律就是，配置会说谎，防火墙不会。

还有一层原文没展开：对中国出海和跨境团队，这件事的性质远不止安全事故。整个仓库连同 git 历史、.env 凭证被打包进美国的 GCS 存储桶，一旦代码里含有客户 PII 或受监管业务数据，触碰的就是数据出境合规红线，对应的是数据安全法和个人信息保护法层面的追责，不是道个歉、换个供应商就能了结的。另外提醒在窗口期用过 Grok CLI 的团队：泄漏的密钥没有“撤回”一说，你也无法验证云端那份 bundle 是否已删除，唯一正确的动作是把接触过的凭证全部轮换——包括那些早已提交进 git 历史、你以为删掉了就没事的旧 token。

给读者一条可执行的建议：把这次独立研究者验证用的金丝雀文件方法变成团队的标准动作——任何新 AI 编码工具引入之前，先在一个垫了 canary 标记文件、挂着 mitmproxy 抓包的沙箱仓库里跑一遍完整任务，看流量真实去向，而不是相信文档怎么写。半小时的测试，能帮你省掉一次全公司规模的密钥轮换和一份合规问询。

—— FDE中国 · 实战派

# The Pulse: Grok’s CLI caught uploading all your local files to the cloud

来源：2026-08-19T14:21:33.000Z

Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from a previous The Pulse issue. Full subscribers received the article below four weeks ago. If you’ve been forwarded this email, you can subscribe here.

Last week, xAI (Elon Musk’s AI company, now part of SpaceX) released the Grok 4.5 model, built by Cursor (an acquisition), trained on SpaceX GPUs, and branded “Grok.” It’s a pretty good model; benchmarking as close in coding capability to Opus 4.8 and GPT 5.5 – while being 60-70% lower cost.

Grok 4.5 can be used via API, but is easiest used via the Grok Build coding CLI. So, that’s what many devs did. Some of them have noticed something really weird: the CLI is uploading all their local files in their working directories! Here’s an independent AI safety researcher known as ‘Cerblab’ documenting what is happening (emphasis mine):

“xAI’s official Grok Build coding CLI (grok), on a normal consumer login, does three things worth documenting precisely:It transmits the contents of files it reads — including a .env secrets file — to xAI, verbatim and unredacted. The secret appears in two channels: the live model turn (POST /v1/responses) and a session_state archive uploaded and accepted (HTTP 200) via POST /v1/storage — the endpoint the binary routes to the grok-code-session-traces GCS bucket (see section 5).It uploads the whole repository — every tracked file’s content plus git history — independent of what the agent reads. Grok packages the workspace and uploads it via POST /v1/storage. Proven directly: on a real codebase, with the prompt “reply OK, do not read any files”, Grok uploaded the entire repo as a git bundle (POST /v1/storage → 200); git cloning the captured bundle recovers a file the agent was told not to open — src/_probe/never_read_canary.txt — with its unique marker verbatim, plus the full git history (appendix uploaded_repo.bundle). And it scales: on a 12 GB repo of never-read random files, /v1/storage moved 5.10 GiB, all HTTP 200 (truncated mid-stream), while the model-turn channel moved just 192 KB — a ~27,800× ratio that pins the upload to the codebase, not to what was read. No storage upload failed; the only non-200s were a model-usage quota (402/429) on /v1/responses and one unrelated 404 — not a storage size cap.The storage destination is a Google Cloud Storage bucket, grok-code-session-traces (not AWS S3) — named verbatim in the binary and in a captured metadata.json (gs://grok-code-session-traces/…). I did not find this mechanism surfaced in the CLI’s install/quickstart materials (not an exhaustive docs audit — §7), it is active by default, and disabling “Improve the model” does not turn it off (/v1/settings still returned trace_upload_enabled: true; §6).

None of this proves xAI trains on the data — that is a policy question addressed in [section] 6. What is proven is transmission, acceptance, and storage.”

There’s so much wrong with this approach! To name a few:

Sending your codebase over the context window is not normal. All AI agents send over their context window to the server that runs the LLM. That’s where tokenization happens and the context is appended to the session. This means that other AI agents send over some part of the code that they read in their context window.

No need to send over the source code to index it. Indexing the codebase is important for efficient code lookup, and we covered how Cursor does this in a privacy-conscious way by indexing a user’s codebase locally, creating embeddings, and sending those embeddings to the server. Cursor’s server does not store any of the user’s codebase though. Except that Grok CLI transferred all users’ codebases to a cloud bucket! Given Cursor and Grok are now combined as part of SpaceX, it’s a real head scratcher why the Grok CLI isn’t doing what Cursor always has.

Sending over unencrypted .env files is reckless. Local .env files store secrets, database access tokens, service access tokens, and more. These are sensitive pieces of information that need to be handled with care. If transmitted, they should be encrypted at the very least. Grok / SpaceX storing them on the GCP storage bucket – likely unencrypted – is flat-out unacceptable and reason enough for any sensible company to ban usage of Grok CLI.

No good reason to upload git history. Sure, seeing Git history could be helpful when training an AI model.

It’s malicious to not tell devs anything about it. Developers using Grok CLI haven’t been asked to opt into this data upload, nor notified of it. Most evidently had no idea this has been happening, and are understandably furious after Cerblab’s writeup went viral.

SpaceX throws devs “under the bus”

Caught red-handed, Grok CLI disabled file uploads with a remote feature flag. AWS engineer Wes Eklund started tracking upload functionality with the CLI, finding that the uploads suddenly stopped due to a feature flag being flipped by the Grok team, pausing data collection.

But the code functionality to stream all local files to the server, unencrypted, remained present in the CLI, even in later updates. Read an in-depth analysis by Wes.

SpaceX’s official response was pretty laughable, not explaining why .env files and .git history were uploaded, and adding that enterprise customers with zero data retention (ZDR) enabled were the only ones unaffected by underhanded, secret uploading of users’ local files:

My initial reaction is what a condescending response by SpaceX, swiftly followed by the question: does Grok CLI even have enterprise customers? It might be few, given how reckless the team evidently is by uploading unencrypted secrets! SpaceX CEO Elon Musk chimed in with a post that seemed to be almost trolling angry users. He wrote:

“SpaceX policy regarding data retention.

It is actually helpful for debugging issues if we can retain some amount of data, so allowing this would be appreciated, but your privacy settings are always respected.”

This makes it worse because SpaceX has been secretly uploading far more data than is “useful for debugging!” Uploading the git history and sensitive .env files is not, in any way, useful for debugging. Also, Grok/SpaceX did not upload “some amount of data”; it uploaded every last file it could find in your local folder.

The developer community is justifiably upset to read SpaceX and Musk pretending that Grok has only uploaded scraps of data purely for debugging purposes. This time, even fans of SpaceX and Grok are speaking out against Musk and his company’s behavior. AWS engineer Wes Eklund:

“Elon, firstly, huge fan of everything you work on. Completely understand the need for some trace data to improve customer experiences.

From what I’ve researched, it seems to be much more than just trace debugging issues. It seems to be entire code repos with sensitive information just collected entirely.

Your Google Cloud blob storage must have petabytes of code repos from us.

Not ideal.”

Sam Altman pushes Grok to open source Grok CLI

OpenAI CEO, Sam Altman, also posted, using a term Musk often employs when commenting on things he disapproves of in society, and hinting at the benefits of Codex which doesn’t upload your whole local filesystem, or mess with .env files and the git history. The Codex harness is open source, so secretive file-upload functionality would be visible in the source code:

Musk clearly read it and responded a few hours later:

A day later, (15 July), SpaceX did indeed open source Grok CLI. Altman’s comment seemingly hit home. Also, SpaceX has stated it is deleting data from its servers, writing:

“We disabled default retention for all Grok Build users starting on July 12th. Additionally, we are deleting all coding data that was previously retained, ensuring every user’s preferences are respected. With these steps, Grok Build goes beyond other major coding products to protect user privacy.”

The open sourced repo is rushed, unsurprisingly. Kernel engineer Elliot Arledge used the repo and reported what he found:

“Out of the box, cargo test --workspace doesn’t compile. 190+ errors, all one bug class: cross-crate test helpers hidden behind #[cfg(test)], which Bazel’s per-target test builds tolerate but Cargo doesn’t, because a dependency is never compiled in test mode. The default-bazel feature is declared in ~20 manifests and wired to nothing. Ungating the benign helpers and putting the signing-key test seam behind a dev-dependency-only feature gets the suite running for the first time on the published tree: 24,663 passed, 28 failed, and every one of the 28 is a pre-existing bug the broken build had been hiding (tests reading your real ~/.claude/settings.json, a tool missing from the registry, macOS /var symlink breakage, one Theme::current() race).

Questions for the team:

Did anyone try downloading this repo and running it before publishing?”

In fairness, it’s clear from the outside that the dev team was instructed to open source the repo ASAP, and did just that. I would expect improvements to allow the developer community to compile the repo and run tests will come later.

On a side note, I wonder what the mood within Grok is. A mandate to open source the product – that was not built to be open sourced! – and doing it in a couple of hours hints what it’s like to work there. Some folks doubtless would find it thrilling and a big challenge, while others likely find it pretty stressful having the “Eye of Sauron” (the CEO) upon them!

Enjoying this article? Subscribe to my newsletter to get issues like this in your inbox. It’s a good read and the #1 software engineering / AI engineering newsletter on Substack.

Can companies trust Grok now?

To hand it to Grok/SpaceX, the last 24 hours of this incident saw some impressive execution. In contrast, everything that took place beforehand screams “amateur hour”:

Did no one in teams that wrote the functionality to upload the complete local codebase raise concerns that this would be unacceptable to devs?

How did uploading secrets without encryption not raise alarm bells?

Why greenlight any of it without opt-in and do it in a secretive manner?

For sensible companies generating revenue with software, vendors who are allowed to access their codebase are limited to those that can be trusted. Grok has demonstrated it is unprepared to handle codebases with security fundamentals in mind.

There’s now frantic backpedaling and rapid open sourcing, but my impression is that this is simply because Grok/SpaceX was caught red-handed, and understands the risk of losing enterprise contracts caused by this flagrant breach of trust. This is why SpaceX’s communication mentioned that enterprise customers with zero data retention have not been impacted!

Trust is earned in drops and lost in buckets; SpaceX/Grok will likely learn this. By secretly uploading codebases and secrets, Grok CLI revealed itself as an untrustworthy coding agent that’s a risk to use. Meanwhile, all the major competitors – Claude Code, Codex, OpenCode, Gemini CLI – have never violated user trust this way.

Grok CLI can rebuild trust, but it’ll likely take years of no security-related incidents to prove they are an open source-first product (that they were not, just a day ago!), and also demonstrate that they care about “normal” developers, and not just enterprise clients with ZDR turned on.

This incident is a good reminder of why planning and process can slow shipping speed, but increase revenue generation. I would wager that the Grok team has shrunk SpaceX’s enterprise subscription prospects for the foreseeable, in the name of saving a few hours on security reviews, learning what other coding harnesses do with codebase uploads, or even just asking the Cursor team!

I predict Grok/SpaceX will have to offer very high usage limits inside the Grok CLI to convince devs to take a risk on running this software on their system. And they will have to undercut OpenAI and Anthropic API pricing massively for any security team to greenlight use of a CLI that just last week was sending .env secrets unencrypted to their GCP buckets.

Of course, SpaceX/Grok will be just fine as it has the capital to fix things. It will now just be a lot more expensive and time-consuming to fix something that was likely caused by a few engineers wanting to make debugging easier!

Read the full The Pulse issue, or check out this week’s The Pulse. The full issue additionally covers:

New trend: concern about massive increase in code review load. Top of mind for engineering leaders: what to do about the ever-growing code review load, and how devs are starting to review code less thoroughly than before? Many questions, but few proven solutions. Send comments about what you see working.

Are more devs at enterprises upset about enterprise pricing by AI labs – and does it matter? I got a message from a reader baffled to learn their company pays 20-30x the price for tokens than their own $20/month Claude Code / Codex subscription. It may show how valuable AI coding tools are.

Linux creator: AI “clearly useful.” Inside the Linux kernel maintainers group, the discussion veered onto whether Linux should consider banning AI contributions, similar to how some FOSS projects have done so. Linus Torvalds weighed in and made it clear that AI is useful, everyone should decide whether to use it, but no one is allowed to tell others what tools to use. Given AI is an increasingly capable tool, it would be foolish to not use it as such.

Read the full The Pulse

Subscribe to my weekly newsletter to get articles like this in your inbox. It’s a pretty good read – and the #1 software engineering newsletter on Substack.

原文链接

一支完整的企业FDE团队，应该配置哪些角色？

Sat, 05 Sep 2026 14:01:09 +0000

这套编制在纸面上很完整，但放到真实的报价单旁边，第一个翻车点是钱。一支六到八人的小队跑一个季度，全成本轻松过百万，而国内企业AI项目大多仍按传统软件逻辑一口价签单，合同额根本养不起满编。于是角色被悄悄兼职化，评测工程师往往是第一个被牺牲的——“上线后再补质量”几乎成了行业默认，而模型一升级效果就回退的坑，多半就是从这个缺口开始的。换句话说，缺编制的背后常常是缺毛利，先算账再组队，比按图索骥招人更接近真相。

第二个翻车点在客户侧。原文要求镜像团队“有时间、有决策权”，这在制造业和政企客户里恰恰是最稀缺的东西：真正懂流程的骨干不会为外部项目腾手，你最后拿到的常常只是“有空开会的人”。一线的判别信号很朴素——客户IT两周内连测试账号都开不出来，或者业务Sponsor连续三次派下属参会，这个项目大概率只会停在“技术可以做”。做跨境和供应链项目还有一个隐性成本高地：关务、物流、财务对同一个“异常件”的定义都不一样，数据负责人若只是挂名，你的黄金测试集从第一天起就是歪的，后面所有评测精度都是假象。

所以我的建议很具体：下一个项目立项时，把镜像团队的六个接口写进项目章程，明确每人每周投入小时数和关键决策时限（例如数据权限两周内开通、UAT按合同周期锁定），任一条落空即触发范围与排期重谈。这比上线后才发现没人签字验收，便宜太多了。

—— FDE中国编辑 · 实战派

# 一支完整的企业FDE团队，应该配置哪些角色？

来源：FDE前线 · 2026年9月2日 12:19

很多企业组建 FDE 团队时，第一反应是找几个“既懂模型、又会写代码、还能跟客户沟通”的全栈工程师。

这种配置做出 Demo 往往很快，进入生产却容易失速：业务价值没人持续确认，客户需求不断膨胀，数据接口卡在 IT 部门，模型升级后效果回退，上线后没有监控，业务人员也没有真正改变工作方式。

问题不在于工程师不够强，而在于团队把本应由多个角色承担的责任，全压在了少数“英雄型 FDE”身上。

2026 年 5 月，OpenAI 在介绍 Deployment Company 时，把 FDE 的工作概括为在企业内部设计、构建、测试并部署生产系统，连接模型与客户的数据、工具、控制机制和业务流程。工信部最新文件同样使用的是“前线部署工程师团队”，并要求其扎根用户现场、保障场景落地。

两个表述都指向同一个事实：企业 AI 交付从来不是一个人的工作。

一支完整的 FDE 团队，需要同时对业务价值、生产质量和能力复用负责。自制图。

FDE 团队没有唯一标准编制。金融、制造、零售与政务项目的人员数量不同，同一个角色在 PoC 阶段也可能由一人兼任。真正不能缺的是三类结果责任。

第一，能否把模糊问题变成值得投入的业务场景，并把范围、指标和验收方式说清楚。

第二，能否把 Agent、RAG 或工作流接入真实数据和生产系统，在权限、评测、监控、回滚与人工接管机制下稳定运行。

第三，能否推动业务人员持续使用，并把连接器、Skill、测试集、行业模板和失败经验沉淀下来，让下一次交付更快、更便宜。

如果团队只能完成第一种结果，它更像咨询团队；只能完成第二种结果，它更像项目开发团队；做完上线就撤场，则很可能重新退回人工流程。完整的 FDE 体系必须把三种结果连成一个循环。

前线小队负责结果，后方平台负责复用，客户镜像团队负责组织落地。自制图。

二、前线小队：6—8人对交付结果负责

标准生产项目可以配置一支 6—8 人的前线小队。人数不是硬指标，关键是下面六类责任都要有明确负责人。

1. Echo／行业解决方案负责人

Echo 负责进入业务现场，理解客户真正如何工作，重新定义问题并识别高价值场景。核心交付物不是一份泛泛的调研报告，而是业务流程图、场景优先级、价值假设和行业对象模型。考核重点应放在场景价值、客户信任以及方案能否跨客户复用。

Echo 这一名称可以在 Palantir 当前招聘体系中看到，其 Deployment Strategist 岗位被归入 Echo，职责包括深入客户工作流、定位最重要的问题并与工程师共同交付。国内团队未必需要沿用名称，但必须有人对“做什么、为什么值得做”负责。

2. FDPM／前线部署产品经理

FDPM 把业务目标翻译为可交付范围，管理里程碑、客户预期、测试用例、验收标准和风险清单。传统产品经理往往围绕通用路线图工作，FDPM 则直接面对一个客户的真实环境，对部署结果负责，并把现场反馈送回核心产品。

这个称谓目前仍在形成中，市场上也会出现 Deployed Product Manager、Field Product Manager 等变体。无论叫什么，团队都需要一个人持续控制范围，避免每次客户反馈都变成插队需求。

3. FDE技术负责人

技术负责人连接客户架构和内部产品，对模型选择、总体架构、数据边界、集成方式与上线策略作出端到端决策。他不应成为所有代码的唯一作者，而要保证关键技术决策一致，知道哪些能力应该定制、哪些必须沉淀为平台。

4. Delta／AI应用工程师

Delta 是主要构建力量，通常配置 2—3 人，负责 Agent、RAG、工作流、Prompt、前后端与业务应用。Palantir 当前将 Forward Deployed Software Engineer 岗位归入 Delta，其职责从高层系统设计、原型开发一直覆盖应用构建和数据集成。

Delta 的考核不能只看代码量，应关注任务成功率、迭代速度、代码质量以及现场反馈能否快速转化为产品改进。

5. 数据与系统集成工程师

企业 AI 的大量时间消耗在数据库、API、ERP、CRM、身份权限和遗留系统上。这个角色负责数据管道、连接器、权限映射和接口文档，对数据质量、接口稳定性与连接器复用率负责。若项目只依赖人工复制数据，再强的 Agent 也无法进入真正的业务闭环。

6. AI评测与质量工程师

他负责黄金测试集、自动评测、回归测试、长尾错误和 A/B 测试。Anthropic 在 2026 年发布的 Agent 评测实践中强调，评测应贯穿整个生命周期：自动化测试用于发布前快速迭代，生产监控发现真实分布变化，人工审查再用于校准主观质量。

早期项目中，评测职责可以由资深 Delta 兼任，但“由谁定义成功、谁阻止质量回退”必须写进团队分工。

标准项目以 6—8 名全职成员为中心，平台、安全与客户成功可共享支持。自制图。

三、后方团队：决定FDE能否从项目制走向规模化

前线小队之外，还需要一支服务多个项目的后方平台与产品化团队。它们不一定每个项目全程驻场，但责任不能缺席。

平台工程／SRE负责部署、可观测性、扩缩容、成本、回滚与故障响应。Google SRE 的 Production Readiness Review 会检查架构依赖、指标监控、应急响应、容量和变更管理。对企业 Agent 来说，这些要求还要增加模型版本、Token 成本、工具调用轨迹和人工接管率。

安全与合规负责人负责数据访问、隐私、身份权限、审计、第三方模型风险与兜底边界。NIST AI RMF 要求组织明确 AI 风险责任、上线前测试、生产监控，以及申诉、覆盖、事故响应和退役机制。安全不应在上线前最后一周才进场，而要从场景设计阶段决定哪些数据能看、哪些动作能做。

客户成功／组织变革负责人负责培训、采用计划、运营数据与扩展路线图。系统上线只是起点，只有业务人员把它纳入日常流程，项目价值才会从“可用”变成“被使用”。早期这项职责可以由 FDPM 兼任，战略客户应配置专人。

产品／知识工程负责人负责把现场经验抽象为 Skill、连接器、模板、行业本体、评测集、Playbook 和失败案例库。OpenAI 当前对 FDE 管理者的要求中，明确包含把有效实践编码为工具、方法和产品路线输入。这个角色决定 FDE 是不断重复定制，还是形成越交付越快的复利。

现场发现问题，项目验证能力，平台沉淀资产，资产再加速下一次交付。自制图。

四、客户侧必须建立一支“镜像团队”

供应商人员再完整，也无法单方面完成企业 AI 交付。客户至少需要六个明确接口：业务 Sponsor 确认优先级并推动跨部门协同；业务流程负责人提供真实规则和异常；IT 或架构负责人负责系统接入与上线审批；数据负责人确认口径、质量和访问权限；安全合规负责人审批日志与风险边界；一线种子用户参与试用、UAT 和后续推广。

这里最关键的不是把人名填进通讯录，而是确保他们有时间、有决策权，也愿意共同承担验收结果。

如果只有客户 IT 部门参与，业务负责人长期缺席，团队通常只能证明“技术可以做”；如果只有业务部门参与而 IT、安全没有尽早进入，项目会在演示之后卡在账号、接口和上线审批。

外部 FDE 与客户业务、IT、数据、安全和种子用户组成联合交付机制。自制图。

五、不同项目规模，怎样安排人数

轻量 PoC：3—4 人。 Echo 或 FDPM 负责价值与范围，一名技术负责人控制架构，一至两名 Delta 完成原型，数据、安全和平台专家按需评审。目标是验证价值和技术路径，不能把 PoC 代码直接当成生产方案。

标准生产项目：7—10 人。配置完整前线小队，SRE、安全、客户成功与产品化角色由后方共享。这是单部门、单核心流程比较稳妥的形态。

战略客户或复杂行业：10—15 人以上。 Echo 与 FDPM 应分别专职，Delta 按 Agent、应用、集成等方向分工，评测、安全、SRE 和客户成功独立配置，同时设置项目总监和高层 Sponsor。金融、制造、医疗、政务以及多供应商项目尤其需要内部技术锚点，确保核心架构、资产和责任始终有人掌握。

岗位可以合并，责任不能消失；项目越接近生产，质量和治理角色越需要前置。自制图。

六、别只考核“按时上线”

FDE 团队的指标至少要覆盖四组结果。

客户价值包括任务完成率、处理时长、成本变化、用户使用率和满意度；工程质量包括评测覆盖率、系统可用性、故障恢复时间、权限控制和人工接管能力；资产沉淀包括 Skill 与模板产出、连接器复用次数、跨项目节省工时和反馈采纳率；商业结果包括从 Land 到 Expand 的周期、续费率、场景扩展率、单客户交付成本和项目毛利。

早期团队可以把工程师大部分精力放在交付，但必须预留稳定的资产沉淀时间。随着团队成熟，复用指标的权重应逐步提高。否则项目越多，高手越忙，交付成本反而越高。

同时衡量价值、质量、复用与商业结果，才能避免FDE退化为免费售前或定制外包。自制图。

最后：最小的完整配置是什么

如果把这套团队压缩成一句话：1 名 Echo 定义问题，1 名 FDPM 推动范围与组织，1 名技术负责人控制架构，2—3 名 Delta 完成构建，数据与评测角色保证输入和质量；SRE、安全、客户成功、产品与知识工程在关键节点进入，客户侧再提供一支拥有决策权的镜像团队。

PoC 阶段可以把最小核心压缩为 Echo、FDPM、资深 Delta 与产品／知识工程四类责任，由少数人兼任。但进入生产后，数据集成、评测、SRE、安全和客户成功必须补齐。

判断一支 FDE 团队是否真正完整，可以连续问三个问题：它能否把模糊业务问题推进到生产上线？能否让业务人员真正使用并产生量化价值？能否让下一次同类交付明显更快、更便宜？

只做到第一项，是一支项目交付团队。三项都能做到，才是一支真正的企业 FDE 团队。

如果你正在搭建 FDE 团队，欢迎关注「FDE前线」。我们会继续拆解岗位分工、交付流程、评测体系和企业 AI 生产化方法。

参考资料

• OpenAI launches the OpenAI Deployment Company[1]

• OpenAI：Manager, Forward Deployed Engineering[2]

• Palantir：Deployment Strategist[3]

• Palantir：Forward Deployed Software Engineer[4]

• Anthropic：Demystifying evals for AI agents[5]

• Google SRE：Production Readiness Review[6]

• NIST AI Risk Management Framework[7]

• 工信部办公厅关于开展人工智能应用服务商培育专项行动的通知[8]

引用链接

[1] OpenAI launches the OpenAI Deployment Company: https://openai.com/index/openai-launches-the-deployment-company/
[2] OpenAI：Manager, Forward Deployed Engineering: https://openai.com/careers/manager-forward-deployed-engineering-new-york-city/
[3] Palantir：Deployment Strategist: https://jobs.lever.co/palantir/e0ab8226-b928-4e3a-bf87-08fe7b1ea595
[4] Palantir：Forward Deployed Software Engineer: https://jobs.lever.co/palantir/1bb19522-3936-4adc-9ced-c3df8b5900b9
[5] Anthropic：Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[6] Google SRE：Production Readiness Review: https://sre.google/sre-book/evolving-sre-engagement-model/
[7] NIST AI Risk Management Framework: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
[8] 工信部办公厅关于开展人工智能应用服务商培育专项行动的通知: https://www.miit.gov.cn/zwgk/zcwj/wjfb/tz/art/2026/art_6fbc038bf15c445ab53b2a94a3f9d4e4.html

本文全文转载自 FDE前线（2026年9月2日 12:19 发布）：阅读原文。

内容由 FDE中国收录整理，排版经自动清理、未改动原文本义；文首「编辑说」为 FDE中国编辑原创观点。如权利人需要删除或更正，请通过联系我们页面告知，我们会尽快处理。

FDE正在从一个岗位，变成一条产业链

Fri, 04 Sep 2026 15:17:04 +0000

原文把「架构关系」这层讲透了，但一线上最容易翻车的环节没有展开：不是选型和PoC，而是评测与退出。谁写评测集，谁就实际控制验收——当厂商热情提出「帮你们搭好评测框架」，那就是客户交出基线的时刻。我经手过的项目里，翻车大多不是做不出系统，而是交接期没人接班：运行手册半年不更新即作废，客户内部骨干早在项目中途就被抽走，「退出」最终变成事实上的永久订阅——供应商退不出，客户也换不起。

还有一个原文没碰的硬约束：跨境合规。这条产业链成立的前提，是客户上下文能向上回流、变成伙伴与厂商的复用资产；可一旦交付跨了境，数据出境评估、PIPL和GDPR会把这股向上的流直接切断——评测样本、日志、上下文图谱在法律上根本不能离开客户环境。于是所谓「伙伴永久持有」的harness，在每个市场都得重长一遍，复利大打折扣。中国企业出海与外资在华做AI交付，这个约束必须在架构设计第一天就摆上桌，而不是等安全评审时才发现资产回不去。

给你一条可执行的建议：下一个FDE项目签约前，把三件事白纸黑字钉死——评测集与领域本体的所有权归客户，上下文回流的脱敏范围与出境白名单写进数据处理协议，退出验收的标准定为「客户内部团队独立运行满90天」。这三条谈得下来，你才分得清对面是把交付当渠道的玩家，还是真打算让你握住自己架构的长期伙伴。

—— FDEChina编辑部 · 实战派

# FDE正在从一个岗位，变成一条产业链

来源：FDE脑洞局 · 2026年8月31日 08:08

FDE研究档案 10｜云厂商、伙伴、服务商与企业内部的架构关系

这期只研究一个问题：当越来越多公司把工程师嵌进客户现场，它们是在扩一个岗位，还是在争企业下一轮技术架构的入口？

—— AFN

57天里，四家公司给出了四种很整齐、统计口径却完全不同的信号。

6月30日，AWS宣布投入10亿美元，建立专门的Forward Deployed Engineering组织，把数千名专家嵌入客户团队。当天发布的伙伴说明又把这套模式扩到咨询伙伴：伙伴组建独立团队，工程师先通过AWS定义的技术门槛，早期由AWS深度参与，之后逐步独立交付。

7月29日，微软在FY2026第四季度财报电话会上宣布成立Microsoft Frontier Co.，计划向客户嵌入6000名行业与工程专家。微软称，过去一年已经用这套模式在164家客户完成330多个项目；同一段发言还把Novo Nordisk项目的交付团队称作FDE团队。

8月20日，AI专业服务商Blend披露，目前有500名Forward Deployed AI Engineer，计划到2027年增至750人。6天后，金融数据平台FINBOURNE启动首批30人的FDE项目，工程师会进入客户的运营和技术团队，处理遗留系统、数据孤岛、治理、审计与控制。

这四组数字不能相加。AWS披露的是投资与组织规模方向，微软说的是一组行业与工程专家，Blend给出当前人数与扩张计划，FINBOURNE说的是首批团队。把它们写成“7280名FDE正在进场”，算术很省事，研究就没了。

人数之外，AWS把FDE和“架构关系”写在了同一套伙伴机制里。

伙伴说明说得很直白：先交付出结果的伙伴，会赢得客户未来的架构关系。它还列出了每次项目要留下的东西：领域本体、评测框架、MCP服务、Agent运维工具，以及记录架构选择、评测标准和行业模式的上下文图谱。

领域本体、评测和上下文图谱，描述的是一套交付机制，已经超出了个人职责清单。

FDE正在变成厂商获得企业架构关系的一条交付渠道。

FOUR MOVES

四家公司分别在动哪一层

AWS的动作最接近“把交付能力做成渠道”。

它一边扩自己的FDE团队，一边把生产方法、技术门槛和早期陪跑交给伙伴。伙伴要组建独立、经过AWS认证的工程团队；项目中形成的交付工具归伙伴长期持有，后续可以在别的项目复用。AWS提供产品、方法和标准，伙伴提供客户关系、行业知识和交付覆盖。

过去的云渠道常见动作是转售、实施、迁移和托管。这里多了一层：伙伴与云厂商共同进入业务流程，做出能运行的Agent系统，再把经验变成自己的交付资产。

微软把“结果型工程”抬到了公司级组织。

6000人不能直接写成6000名FDE。微软的原话是“行业与工程专家”，官方也没有在这段披露中给出岗位构成、全职人数、地区分布或到岗节奏。不过，它把组织命名为Microsoft Frontier Co.，把工作方式定义为与客户共同设计、共同创新并持续改进AI系统，还用FDE团队解释其中一个项目。

它至少说明，嵌入客户不再只是少数产品团队的特殊打法，正在变成大厂可规模化调度的组织能力。

Blend在把FDE做成人才供给与服务产能。

公司计划通过自建ForwardAI Academy、全球招聘和定向收购，把500人的队伍扩到750人。这条扩张路径覆盖训练、筛选、编组和进入客户环境，再用项目结果支撑下一轮扩张。

Blend同时披露了PoC转生产和NPS数字。本文不采用这些数字证明效果，因为它们来自公司自报，公开页面没有提供逐项目样本、统计方法和独立复核。

FINBOURNE走的是垂直软件路径。

它从投资管理行业的数据、对账、交易流程、治理和审计切入。首批30名工程师被要求坐进客户组织，成为运营与技术团队的延伸。项目负责人此前长期负责专业服务和新客户实施。

这类FDE离行业流程很近。销售平台功能的同时，它还会参与平台怎样进入旧系统、控制怎样写进架构、数据怎样持续对账。垂直软件由此往专业服务生长，专业服务也开始带着产品和Agent往回走。

四家公司走的路不同。共同点是：FDE开始同时承担产品落地、客户交付、伙伴扩张和行业知识回流。

ARCHITECTURE RELATIONSHIP

订单结束以后，架构关系还在继续

企业采购一个模型席位，厂商拿到的是订单。FDE把模型接进采购、客服、研发、风控或投资数据流程，厂商才进入企业的依赖关系。

这段关系至少包含五样东西：业务流程怎样拆，数据从哪里来，系统能拿什么权限，什么结果算通过，上线以后由谁维护。

谁持续参与这些决定，谁就更容易影响下一次模型选择、云资源使用、数据架构、安全控制和合作伙伴名单。即使合同到期，项目中留下的评测集、领域本体、连接器、运行手册和架构决定也会继续影响后续选择。

这就是“架构关系”比一次项目更值钱的地方。

AWS的伙伴机制把这件事写得尤其清楚。每次交付都要形成可复用的harness，伙伴永久持有；AWS工程师前期深入参与，等模式稳定后，再转向帮助伙伴扩张。于是，一次项目同时产生三类回报：客户得到生产系统，伙伴得到可复用交付资产，AWS得到云上架构和产品使用。

渠道的分发单位也会跟着变。

传统渠道常以许可证、线索或实施项目为分发单位。FDE渠道分发的是一条能运行的业务流程。模型、云、数据服务、安全工具和运维能力，沿着这条流程进入企业。

服务费只是表面那一笔钱。后面还连着云消耗、产品采用、续约、扩场景和技术路线。

TWO FLOWS

这条产业链有两股流，争的是中间那层资产

— FDE产业链位置图：模型与平台、云厂商伙伴、专业服务、企业内部FDE之间的两股流与架构关系

从上往下流的是模型、平台、工具、方法、认证和生产标准。厂商希望这些东西经过伙伴和服务商，进入更多客户的真实流程。

从下往上流的是客户上下文：遗留系统的限制、权限冲突、评测失败、行业规则、异常处理和一线使用反馈。它们会回到交付团队，再进入伙伴的复用资产或厂商的产品路线。

中间被争夺的是架构关系，以及项目留下来的资产归属。

AWS说伙伴永久持有交付harness。客户又需要在项目结束后拿到系统、知识图谱、运行手册、架构文档和可以独立操作的内部骨干。两边都合理，也天然存在张力。

伙伴想积累跨项目复用的行业方法，平台希望现场反馈回到产品，企业则要保留自己的数据、评测、权限和切换能力。同一份“上下文”里，哪些能抽象复用，哪些只能留在客户环境，不能靠一句“共同创新”带过。

产业链真正形成以后，合同里最难谈的可能不再只是人天和模型单价，而是四件更具体的事：谁定义生产标准，谁拥有交付资产，谁可以把经验带到下一家客户，谁在供应商退出后继续承担运行责任。

FOUR POSITIONS

四种FDE，名字相同，位置不同

模型与平台公司的FDE：把现场失败送回产品

这类FDE最靠近模型、云服务或垂直平台的产品路线。

它的优势是能直接调用产品团队、改变接口、补工具、建立参考架构。把客户做上线是一份产出，识别反复出现的问题、把相应能力做成产品默认值，是另一份产出。

判断这类FDE做得好不好，可以看两类证据：客户系统是否稳定进入生产，现场失败是否真的变成了评测、工具或产品改动。

风险也很明确。产品公司既提供能力，又参与选型和验收，容易让自己的技术路线变成默认答案。客户需要保留独立基线和替代方案。

FINBOURNE这类垂直平台FDE也在这一层。它带回产品的内容包括技术反馈，也包括投资管理行业的控制、审计和数据语义。

云厂商伙伴体系里的FDE：把生产方法复制出去

这一层要检验的是：云厂商能否把生产标准交给伙伴，又不把标准稀释成一张证书。某个工程师驻场多久，反倒是次要问题。

AWS的做法给出了几个可检查的部件：独立编组、工程师准入、早期共同交付、统一生产门槛、项目资产复用，以及伙伴逐步独立。

这类FDE做成以后，云厂商获得规模，伙伴获得能力和客户资产。做不成时，它会退回熟悉的老路：重新贴牌的实施团队，材料上写着Agent，现场仍按人头排期。

所以，伙伴FDE最重要的证据要看独立交付后留下了什么。下一次同类项目能否少走一段路，才说明方法开始复用。认证人数回答不了这个问题。

专业服务公司的FDE：把行业上下文变成生产系统

Blend代表的是另一种优势：它不必绑定单一模型或云，可以用行业知识、数据工程和客户关系承接复杂改造。

专业服务公司离遗留系统和组织协同更近，也更容易覆盖多个厂商。它们的难题在商业模型里。FDE通常比传统顾问更贵，项目又需要长期进入生产；如果每个客户都从零开始，人数越多，成本也越诚实。

因此，这一层能不能形成利润，要看项目知识能否转成评测、连接器、领域模型、部署工具和运营方法。Blend计划用学院、招聘和收购扩人，解决的是供给规模；交付资产能否复用，决定规模能不能变成效率。

企业内部FDE：保住最后的授权与接管能力

企业内部未必把岗位叫作FDE。平台工程、企业架构、AI产品、数据、安全和业务运营团队，都可能承担其中一部分工作。

它们和外部FDE最大的区别，是站在责任终点。供应商可以搭系统、给建议、做评测，企业内部团队仍要决定数据能不能用、Agent能不能写入、异常由谁接管、版本什么时候回滚，以及结果是否足以进入下一轮预算。

AWS把客户独立接管写进了FDE项目设计：客户工程师从观察者变成共同建设者，再成为独立操作方。这个过程恰好说明，成熟的外部FDE需要一个能接管系统的内部对应层。

内部没有这层能力，外部FDE很容易成为事实上的架构负责人。企业有一支能定义接口、保管评测和执行退出方案的内部队伍，模型公司、云厂商和服务商才会在清楚的边界里竞争。

THREE GATES

岗位扩张不等于产业链成立

我会用三道门判断这次变化有没有走到“产业链”。

第一，能力能否脱离明星个人被复制。AWS的准入与伙伴编组、Blend的学院和FINBOURNE的行业团队，都在回答供给问题。只靠少数高手救火，仍然是一门手艺。

第二，每次项目是否留下可复用资产。AWS已经明确列出本体、评测、MCP服务、运维工具和上下文图谱。其他公司如果只有人数增长，没有项目资产，规模越大越像传统人力生意。

第三，客户能否独立接管并保留选择。系统、文档、评测、权限、日志和内部负责人都要能交回企业。否则“嵌入客户”很容易变成更深的供应商依赖。

三道门里，前两道决定FDE能不能规模化，最后一道决定这条产业链是不是健康。

MONEY & POWER

钱和权力会沿着交付重新分配

以下推断来自四家公司的组织动作，不是它们披露过的经营结果。

模型与云厂商可能愿意承担更高的前期工程成本。FDE做成一条生产流程以后，收入不只来自本次服务，还可能来自长期的模型调用、云资源、数据与安全产品。对它们来说，FDE可以同时是交付成本、产品研究和获客成本。

专业服务公司会被迫回答一个更难的问题：项目结束以后，除了发票，还留下了什么可复用的东西。能把交付资产用于下一次项目，它就有机会摆脱纯人天；每次仍从零开始，FDE只是更贵、更难招的驻场工程师。

垂直软件公司则可能借FDE扩大产品边界。原来只卖一套系统，现在开始参与数据迁移、控制设计、流程改造和持续运营。产品更贴近客户，退出也会更难。企业要提前谈清楚数据、架构文档、评测与替换接口。

企业内部FDE会获得更多预算与议价权。它不一定自己做完所有工程，但要能把外部供应商放进同一套基线、权限和验收框架里。谁掌握这层接口，谁就不必把每次厂商更换都做成一次组织失忆。

USE THE MAP

用《FDE产业链位置图》判断自己交付的是什么

图里的四个位置，不是职业等级，也没有谁天然更高级。

如果你在模型与平台公司，最该积累的是“现场问题怎样进入产品”的证据；如果你在云伙伴体系，要证明方法离开原厂工程师以后仍能稳定交付。

专业服务公司要证明项目资产可以复用。团队很能熬，不算交付资产。企业内部团队则要证明自己能定义基线、管理权限、接管异常并保留供应商切换能力。

这张图也可以拿来检查一个FDE岗位。

看它的钱从哪里来，生产标准由谁定，项目资产回到哪里，最后的运行责任落在谁身上。四个问题答完，岗位在产业链里的位置通常就清楚了。只看招聘标题，容易把产品团队、咨询顾问、集成工程师和企业架构负责人装进同一个纸箱。

FDE会不会成为一条产业链，不由扩招人数决定。

当模型与标准、规模交付、行业集成和企业责任开始由不同组织承接，又能通过同一套生产资产连接起来，产业链才真正出现。

这会把FDE的稀缺性推向另一个位置。会写代码、能驻场只是入场券。更难替代的是：你能不能让一次客户交付变成下一次可复用的方法，同时让客户仍然握着自己的架构、证据和退出权。

SOURCES & LIMITS

方法、来源与证据边界

本文以2026年6月30日至8月26日四家公司公开材料为主样本，用于观察FDE组织怎样进入云厂商、伙伴网络、专业服务与垂直软件。样本不是全球FDE公司清单，也不代表四种组织已经取得相同的商业结果。

本文使用四类信息：

已核实公告事实：公司明确披露的日期、投入、人数口径、组织安排和工作方式；

公司自报计划：Blend到2027年的扩张目标、各家公司对项目效果或交付优势的描述；

作者判断：架构关系、两股流、四种产业位置和三道门；

尚未验证：实际到岗人数、逐项目ROI、独立验收结果、FDE业务收入与利润率、客户长期留存及供应商切换成本。

微软的6000人不能直接等同于6000名正式岗位名称为FDE的员工。AWS的10亿美元是支持专门FDE组织的投资口径，不能拆成招聘预算或已经发生的支出。Blend的500人与750人来自公司公告，FINBOURNE的30人是首批项目团队；这些数字都不是审计后的人力统计。

公开来源：

AWS Partner Network：Introducing Forward Deployed Engineering for Partners：10亿美元FDE组织、伙伴模式、AWS定义的工程门槛、伙伴独立团队、交付harness与架构关系表述。

About Amazon：AWS invests $1 billion to embed AI forward deployed engineers with customers：专门FDE组织、数千名专家、客户团队嵌入方式、客户自立、交付物与伙伴投入。

Microsoft FY2026 Q4 earnings call：Microsoft Frontier Co.、6000名行业与工程专家、164家客户、330多个项目和FDE团队表述。

Blend：Blend to Grow Forward Deployed AI Engineering Force to 750 by 2027：当前500人、2027年750人目标及学院、招聘、收购三类扩张方式。人数和效果均为公司披露。

FINBOURNE：FINBOURNE launches Forward Deployed Engineering programme：2026年8月26日启动、首批30人、客户团队嵌入、遗留系统与治理控制范围。

你所在的FDE团队，项目结束后最容易被带走的，是人、方法，还是客户的架构关系？

我是 AFN，一名做了一年多 FDE、仍能独立回消息的活人。

原文链接

案例复盘：客户成功职能从 0 到 1 的 V1 搭建法

Fri, 04 Sep 2026 00:11:17 +0000

客户成功从 0 到 1，先招对人、再搭系统、后加指标。

方法论里最实用的是参考值：CSM 配比按客户分层起步——战略客户 1 人对 5-10 个客户、企业级 20-25 个；指标只从两件事起步，席位使用率三段等式的客户健康度与续约率；入驻流程 V1 用共享表格加模板化十步流程就够，必含启动会与需求收集。这些数字让「搭 CS 团队」从理念变成可排期的事。

要提醒国内读者：文中配比与激励设计以订阅制 SaaS 为底色，国内 toB 常以项目制验收与年度服务费续签为主，续约率要换成复购或增购口径再用；另外首批 CS 员工会成为部落知识的单点，经验不同步沉淀为模板与 SOP，人员流动时交付能力会直接受损。

交付团队可以先抄三段等式：按购买、部署、使用三个数给每个客户算健康度，每周盯一次低使用量客户。

—— FDEChina编辑部 · 实战派

一、背景

案例来自 First Round Review 对 Atlassian 客户成功高级副总裁 Stephanie Berner 的专访。她此前领导过 LinkedIn 销售解决方案业务的客户成功团队，担任过 Box 客户成功管理高级总监，并在 Medallia 积累早期创业公司经验，多次从零搭建客户成功（Customer Success，下称 CS）职能。她的观察是：CS 早期几乎都由创始人或联合创始人兼管；当客户规模积累起来、创始人一半以上时间被「解决客户体验问题」占住时，就该把 CS 运营正式化了——这是在锻炼「搭组织」这另一块肌肉。

二、问题

第一批客户往往靠创始人亲力亲为地救火：最早招的一两名员工像消防员，客户问题接连冒出就一个接一个扑灭。客户数量上升后这种模式立即失灵——没有系统化收集客户反馈的通道，客户入驻的多步骤流程没有固化成文，公司对「要让客户获得价值需要做些什么」的理解会很薄弱；而业内对「何时该组建专门的 CS 团队」并无精确时间表，创始人需要在招聘画像、面试薪酬、汇报线、团队规模、起步系统与指标几个层面同时补课，任何一层缺位，CS 都发挥不了增长杠杆与跨职能连接的作用。

三、方案

Berner 给出的是一套可直接照做的 V1 搭建法（专访口径）。第一位招聘的画像取决于「你想为客户解决什么问题」：客户从购买到实施需要深刻理解零售工作流、会计职能等行业知识，就冲行业专家招人；抵达价值的过程涉及复杂集成、数据迁移等客户不该自己动手的后端操作，就冲技术技能招人。组织上，CS 优先考虑直接向 CEO 汇报；系统上先模板化两件事——支持工单与客户入驻流程；指标上只从客户健康度与续约率两件事起步。

四、实施过程

第一位招聘。Berner 倾向先招个人贡献者（IC），理想人选是做过管理者或有志于成为管理者的人；若已明确几个月内要大幅扩招，可先招管理者接手 IC 招聘，代价是战术性产出的滞后期更长。反复验证的特质有四类：动作快、对技术与客户都有强烈好奇心的速度感；作为面向产品与工程层反馈回路的沟通能力；有问题就去解决、有具体事例可查的行动偏好；天然的客户同理心——但不要过度加权，候选人必须能平衡客户利益与商业利益。

面试与薪酬。面试轮至少纳入一位创始人、产品或工程负责人、一位市场销售侧的人；必问题包括「讲一次发现问题并解决掉的经历」（行动偏好）、「上次绩效中收到的最有影响力的反馈」（自我认知）、「你接管团队会改变什么保留什么」（系统级思维）与「谈谈接受出色和糟糕客户服务的感受」（同理心）。薪酬用底薪加奖金而非纯提成，奖金挂钩续约率、增购或采用度等具体 KPI；她提示纯续约配额的风险——只按续约激励的团队无人在意客户是否真正获得价值，客户转眼开始流失。

组织与规模。汇报线优先向 CEO 汇报，让最接近客户体验的高层直接看清客户动态；「续约与增长并重、收入主要来自现有客户」时向 CRO 汇报才成立；她不建议向 CPO 汇报——CS 属于市场进入打法，与营收团队对齐才形成飞轮。CSM 配比参考值：战略客户（合同额通常超 50 万美元）1 人对约 5-10 个客户，企业级 20-25 个，中端市场 40-50 个，中小企业 80-120 个，再按技术复杂度与使用场景数量调整——必须从某个起点开始并愿意随时调整。

系统、指标与流失分析。先模板化两件事：支持工单（系统化收集并归类客户反馈）；客户入驻（V1 用共享表格加模板化十步流程，必含启动会与需求收集）。指标从两个起步：客户健康度用「购买席位、已部署席位、实际使用」三段等式衡量；续约率衡量价值交付，归属按「是否涉及详细谈判」在 CS 与销售间划界。NPS、CSAT 等留到后期——早期易被操纵且给不出行动项。流失发生时先记录再分析，向流失客户问三个问题（为何选别家、如何决策、有何替代），通常得到六到八条原因，分可控与不可控两类，聚焦可控项。

五、结果

这是一篇方法论专访，原文未披露某家公司套用该方法前后的量化对比，故按定性结果呈现（专访口径）：V1 搭建法把「搭 CS 职能」拆成了可执行的动作序列——首批招聘画像与必问题、底薪加奖金的激励设计、CEO 汇报线、CSM 配比参考值、两套起步系统、两个起步指标与流失三问；其有效性判断落在客户健康度与续约率能否驱动团队日常行动上。这套方法在她的多段 CS 从零到一经历中被反复使用与修正。

六、约束

方法的适用边界：CSM 配比是起始参考值而非标准答案，随年度合同价值、业务阶段、国家与语言数量、客户所需支持量浮动；激励结构取决于「CS 是否对续约成交负责」的二分法，照搬别人的奖金设计会驱动错误行为；首批招聘选行业专家还是技术强人没有统一公式，取决于产品与客户拿产品做什么。

七、可复用经验

对 FDE 交付的关联：FDE 负责把系统交付上线，CS 负责让客户持续从中获得价值，两者共享同一条「客户现场反馈闭环」。

用三段等式盯客户健康度。按购买、部署、使用三个数给每个客户算使用率，交付后据此主动找低使用量客户开启对话，而不是等投诉上门。
入驻流程从第一天就模板化。启动会加需求收集是最小骨架；缺少清单心态，规模上来后客户体验必然不一致——这对应 FDE 的交接与运维移交环节。
把流失三问当复盘工具。「为何选别家、如何决策、替代选项」同样适用于 FDE 项目的复盘与未成单项目的回访，把原因分为可控与不可控再行动。
招聘题直接迁移。行动偏好、接受反馈、系统级思维三问，用于 FDE 团队面试同样成立——现场岗位尤其需要能接受反馈的人。

中国语境差异：文中配比与激励以订阅制 SaaS 为底色，国内 toB 常以项目制验收与年度服务费续签为主，「续约率」需换成复购、增购或续签口径再落地。

八、来源

原文：The Founder’s Guide to Building a V1 of Customer Success，First Round Review（Stephanie Berner 专访），review.firstround.com；
口径说明：本篇引述与参考值均为专访口径，未经独立核实。

案例复盘：美团用 Agent 评测思路管理 31 万行 AI 重构

Fri, 04 Sep 2026 00:11:15 +0000

用评测思维管 AI Coding，顺序比工具重要。

最值得抄的是那条主线：先「人人对齐」，再「人机对齐」。团队先对分层、建模、依赖边界形成共识——「1 个『独裁者』好过 10 个『民主者』」——再把共识固化为 always 级 AI Rule 与 Skill。排查阶段的做法同样可复制：专家圈定高危边界、AI 做穷举扫描，有限投入就摸清 3 个 P0、2 个 P1 技术债，还顺带定位了 10 个隐蔽的性能隐患。

要提醒成立前提：零排期重构的前提是你能支配自己的需求池，受客户节奏约束的交付场景里，「顺带」的部分往往排期一紧就先被砍；拉齐标准的强角色是单点，人一撤共识就开始蒸发，关键规范要有第二责任人。质量兜底也别只压在 CR 上——机械迁移里人眼抓得住风格、抓不住行为漂移，等价性验证要跟上。

本周就能做的一步：把团队对分层与建模的共识写成一页纸，先让人人对齐，再谈 AI Rule。

—— FDEChina编辑部 · 实战派

一、背景

案例主体是美团内部一个负责 Agent 评测业务的团队（公司技术博客口径）。其 Agent 评测系统长期承载多个核心业务场景，同时承担数据生产、流程编排、质量控制与多人协作：底层支持 6 种多模态数据评测，上层有多种核心任务视图与精细化业务动作，配套十余种质检机制。系统从 2025 年 6 月的不足 5 万行代码扩展到 31 万行，保持月均 16 个需求（80% 业务需求加 20% 技术需求）的高负荷迭代；团队一年左右规模增至 3 倍，成员背景覆盖高并发、机器学习离线训练、管理后端与实习生，且 90% 以上的代码由 AI 辅助编写。

二、问题

团队复盘直指一个反直觉的事实：AI Coding 不会自动收敛复杂度——没有统一规范约束时，不同人用 AI 写出的代码风格各异，系统反而加速腐化。三个痛点集中爆发：业务模型扩展能力不足，几乎每新增一种业务形式都要新增代码，形成「烟囱式」开发；长期「按需求建包」让 Controller 等复杂逻辑揉在一个包里，31 万行体量下的「面条式代码」让日常开发牵一发而动全身；团队一年扩张 3 倍、背景多样，再叠加 90% 以上代码由 AI 生成，若不建立硬性规范，系统将以极快的速度产生不可控的腐化与新债。而业务处于探索期，需求又急又模糊——既不可能停下来做专项，也不能放任新债生长。

三、方案

团队把本职工作里的 Agent 评测方法论迁移到工程治理，核心是一条标准对齐主线：「人人对齐→人机对齐」。先由一位强有力的角色拉齐产品、运营、算法、QA 等所有角色的工程标准——「1 个『独裁者』好过 10 个『民主者』」；再把共识固化为 AI 可执行的约束：工程分层规范、业务域模型规约与仓储层规约落地为 always 级 AI Rule，前置到预 CR 环节约束编码过程；围绕「编排类」与「能力类」的职责边界做组内统一，共识沉淀为编码时渐进式加载的 Skill。顺序至关重要：团队没有先形成共识时，同一份规范会被不同人解释成不同版本，AI Rule 写得再好也是一纸空文。

四、实施过程

重构沿三个阶段推进（公司技术博客口径，2026 年 2 月至 4 月）。

阶段一：定义问题（2 月）。面对看不完的 31 万行代码，团队采用「专家经验定向 + AI 辅助排查」：核心开发圈定高危排查边界，AI 负责穷举扫描，快速摸清业务模型缺陷、数据库查询性能隐患、状态管理与索引等技术债，共梳理出 3 个 P0 与 2 个 P1 技术债；工程师还借 AI 在短时间内定位了 10 个隐藏极深、肉眼极难发现的性能隐患。

阶段二：制定 AI 友好规范（2 月底完成）。把规范从文档落地为 always 级 AI Rule，并前置到预 CR 环节，帮助研发在提交前完成基础规范校验；针对最容易产生分歧的领域职责划分，将「编排类/能力类」的组内共识沉淀为 Skill。

阶段三：渐进式重构与质量兜底（3-4 月）。其一，工程分层与解耦：把面条式代码迁移到 Starter / Application / Infrastructure / Common 四层架构，先由重构主 R 亲自完成两个最复杂包的迁移并沉淀标准化迁移 SOP，其余成员按 SOP 指导 AI 完成剩余包迁移，快速完成十余个核心包的结构迁移。其二，零排期重构：把技术债拆解为业务需求的「顺带动作」，借核心功能迭代落地全新业务模型、借功能升级完成质检业务模型全量迁移，没有申请一天专门的重构时间。其三，质量保障：引入 Pre-PR 机制，提交前先用 AI 多轮自查修复规范类问题；人工 Review 从「你写得对吗」转向聚焦技术方案符合性与业务逻辑；用高阶模型审查低阶模型产出，并用不同厂商模型互审以扩大覆盖面；测试确定「人工主导、AI 辅助」路线——全自动生成用例的路线因缺乏全局业务认知、易漏隐性高危场景而被放弃，团队 100% 的需求由研发兼任测试。

五、结果

以下均为公司技术博客口径，未经独立核实。重构在不停止业务交付的前提下完成：十余个核心包完成工程结构迁移；核心数据模型与质检业务模型完成平滑升级与全量迁移（兼容多条业务链路与多视图、多区域的交叉验证）；技术债梳理以有限投入定位 3 个 P0、2 个 P1，并发现 10 个性能隐患，全程没有申请专门的重构排期。文中同时给出两条定性判断：「经验」的价值正从「能看全」转移到「能判断什么重要」；工程师的重心从「写代码」转向「设计并维护一个能让 AI 可靠产出代码的工程环境」。

六、约束

这套打法的成立条件值得看清：零排期重构的前提是团队能支配自己的需求池，能把技术债拆进高优需求「顺带」消化，且拆解精度依赖很强的技术判断力；标准对齐依赖一位强有力的拉齐角色，这本身构成单点；规范的价值在 90% 以上代码由 AI 生成的场景才被充分放大；Pre-PR 与 AI CR 要求团队接受人工 Review 的角色重定义——这是流程改造，不只是引入工具。

七、可复用经验

先人人对齐，再固化 AI Rule。顺序不能反：团队对分层与建模没有共识时，任何 Rule 都会被解释出多个版本。适用前提：有能拍板拉齐标准的角色。
主 R 打样、SOP 分发、全组并行。让最熟的人先跑通完整样板，把步骤沉淀为 AI 可执行的 SOP 再复制，比人人摸索快且稳。
技术债拆为需求的顺带动作。适合能支配需求池的团队；受客户节奏约束的交付场景，建议给顺延的债务项设升级机制，避免台账空转。
CR 前移。AI 提速后 CR 会成为新瓶颈，Pre-PR 自查让人工 Review 聚焦业务语义，这一步不能省。
测试人工主导、AI 辅助。全自动用例生成已被该团队实践证伪，Human-in-the-loop 更稳——与 Agent 评测领域「人机一致率达标才可信」的门槛一脉相承。

中国语境差异：文内场景是大厂自有业务团队；对外部客户交付的 FDE 项目，AI Rule 与规范还要同时适配客户侧代码库约束与安全审批，落地时需多留一层适配成本。

八、来源

原文：用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践，美团技术团队博客，tech.meituan.com，2026-05-07；
口径说明：本篇数据（31 万行、月均 16 个需求、90% 以上 AI 生成、3 个 P0、10 个性能隐患等）均为公司技术博客口径，未经独立核实。

案例复盘：Anthropic 的多智能体研究系统是怎么协作的

Fri, 04 Sep 2026 00:11:13 +0000

把「研究」这类开放式任务工程化的一手样板。

最有含金量的是委派接口：目标、输出格式、工具指引、任务边界四件套，再配上与复杂度挂钩的投入档位——简单事实查证用 1 个 Agent，复杂研究动用 10 个以上子 Agent。评估侧同样务实：约 20 个真实查询的小样本起步，LLM 裁判按五维量表打分，人工测试补抓内容农场偏好这类自动化查不出的问题。

原文对成本足够诚实，多 Agent 的 token 消耗约为普通聊天的 15 倍；但对国内交付团队更关键的是适用面判断——这套架构最适合高价值、可并行、只读的情报型任务，客户现场的写路径操作与强流程依赖场景不建议硬套。多 Agent 的错误还会级联累积，检查点、灰度部署这些生产化苦活才是复刻成本的大头。

先挑 5 个真实研究类任务做单 Agent 与多 Agent 对照，算清质量提升能否覆盖 token 开销，再决定要不要把这套架构写进交付方案。

—— FDEChina编辑部 · 架构师视角

一、背景

案例主体是 Anthropic 的研究（Research）功能：Claude 可以搜索网络、Google Workspace 以及各类集成来完成复杂任务，支撑它的是一套多智能体系统——由多个在循环中自主使用工具的 LLM 协同工作。Anthropic 在工程博客《How we built our multi-agent research system》中公开拆解了这套系统从原型走向生产的过程，以及系统架构、工具设计与提示词工程上的经验教训。本篇基于该文复盘这套系统的协作方式，并讨论它对 FDE 交付中研究类 AI 任务的参考价值。

二、问题

研究任务的难点在开放式：无法提前预测要走的步骤，不能为探索复杂主题硬编码一条固定路径——研究者会随新发现调整方法、追踪过程中浮现的线索，模型必须自主运行许多轮、根据中间结果决定下一步方向，线性的、一次性的流水线处理不了这类任务。同时，搜索的本质是压缩：从海量语料中提炼洞见，单个模型的上下文窗口装不下，串行式的逐条搜索又慢又浅。在广度优先、需要同时追踪多个独立方向的查询上，单 Agent 很快撞到极限。

三、方案

Anthropic 采用编排者-工作者（orchestrator-worker）模式：一个主 Agent 负责分析用户查询、制定研究策略，再把任务委派给并行运作的专门化子 Agent。每个子 Agent 拥有独立的上下文窗口，充当「智能过滤器」：并行探索问题的不同侧面，把最重要的内容浓缩后交回主 Agent 汇总成最终答案。与 RAG 的静态检索（取回与查询最相似的一组文本块再生成回答）不同，这套架构是多步搜索——动态查找信息、适应新发现、对结果做分析。分工同时带来关注点分离：各子 Agent 使用不同的工具、提示词与探索轨迹，降低路径依赖。

四、实施过程

把架构跑起来，工程量集中在四件事上。

任务分解与委派。主 Agent 把查询拆成子任务，每个子 Agent 要拿到四样东西：目标、输出格式、所用工具与来源的指引、清晰的任务边界。早期版本允许「研究一下半导体短缺」这类简短指令，结果是子 Agent 重复执行同一搜索——一个在查 2021 年汽车芯片危机，另外两个还在重复调查 2025 年的供应链。

工作量缩放与并行。Agent 自己判断不好该投入多少精力，团队把缩放规则写进提示词：简单事实查证用 1 个 Agent、3-10 次工具调用；直接对比用 2-4 个子 Agent、各 10-15 次调用；复杂研究动用 10 个以上职责明确的子 Agent。并行化同步跟上：主 Agent 并行启动 3-5 个子 Agent，子 Agent 并行使用 3 个以上工具，复杂查询的研究时间因此最多缩短 90%。

评估先行。从约 20 个反映真实使用模式的查询起步做小样本评估；再用 LLM 裁判按量表打分，覆盖事实准确性、引用准确性、完整性、来源质量与工具效率；人工测试补自动化遗漏——早期 Agent 偏好 SEO 优化的内容农场而非学术 PDF，来源质量启发式规则由此补进提示词。

生产可靠性。Agent 有状态、错误会累积，团队用持久化执行、检查点与重试逻辑让系统从出错位置恢复而非从头重启；部署采用彩虹部署，新旧版本并行、逐步迁移流量；生产追踪只看决策模式与交互结构、不看对话内容，以保护用户隐私。

五、结果

以下均为原文披露口径。在 Anthropic 的内部研究评估中，以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为子 Agent 的多 Agent 系统，比单 Agent 的 Claude Opus 4 高出 90.2%；典型场景是「找出标普 500 信息技术板块所有公司的董事会成员」，多 Agent 把它分解给子 Agent 后找到正确答案，单 Agent 缓慢顺序搜索、未能找到。在测试浏览型 Agent 的 BrowseComp 评估中，三个因素解释了 95% 的性能差异，其中仅 token 用量一项就解释了 80%。工程收益方面，并行化让复杂查询的研究时间最多缩短 90%。用户反馈口径：有用户称借此发现了未曾想到的商业机会、解决了棘手的技术问题，并节省了多达数天的工作量。

六、约束

这套架构的成立条件，原文写得很直接：多 Agent 系统的 token 消耗约为普通聊天的 15 倍（单 Agent 约 4 倍），要具备经济可行性，任务价值必须高到足以覆盖性能提升带来的成本。它适合重度并行化、信息量超出单个上下文窗口、需要与众多复杂工具交互的高价值任务；要求所有 Agent 共享同一上下文、或彼此存在大量依赖关系的领域并不适合——大多数编程任务可并行的部分就比研究少。工程侧还有两条现实约束：同步执行让主 Agent 等待每组子 Agent 完成，形成信息流瓶颈；Agent 的非确定性让调试必须依赖完整的生产追踪。

七、可复用经验

对中文 FDE 从业者与企业，这套案例中可直接迁移的做法（适用前提：交付中存在研究、情报、尽调类 AI 任务）：

委派即接口设计。给 AI 拆子任务时写清目标、输出格式、工具与边界——含糊指令在 Agent 与人身上都会造成重复劳动，这条同样适用于 FDE 向协作者派活。
给工作量定档位。按任务复杂度预设投入档位（几个子任务、几次调用），防止简单查询过度烧钱；国内客户对 token 成本敏感，档位表可以直接写进交付方案的成本模型。
评估先行、小样本起步。约 20 个真实查询加 LLM 裁判与人工抽检双轨，比等一套大而全的评估体系更快建立质量底线。
只读任务先行。多 Agent 架构先用于只读的情报型任务，写路径操作（改数据、动生产配置）暂缓——原文明确提示错误在 Agent 系统中会累积放大。

中国语境差异：国内企业交付常叠加数据不出域与权限审批约束，多 Agent 并行检索可能触碰权限边界，「Agent 能看什么」要先当作权限问题审一遍。

八、来源

原文：How we built our multi-agent research system，Anthropic 工程博客，anthropic.com；
口径说明：本篇数据（90.2%、95%、80%、15 倍、90% 等）均为 Anthropic 内部评估与原文披露口径，未经独立核实。

Recruiting Forward Deployed Engineers: 2026 Guide

Thu, 03 Sep 2026 17:58:12 +0000

这份指南真正值钱的不是薪资区间和寻源渠道，而是两个判断：文章认定 FDE 是头衔错配最严重的岗位——真做这份工作的人不顶着这个名字，而标准工程面试恰恰筛掉让这个角色值钱的特质；再加上 Palantir 那句「一个客户、许多能力」，把 FDE 与产品工程师的分野说透了。文中 95% 的试点失败率与 800% 的招聘增幅是同一枚硬币的两面：模型已经够好，死的全在最后一公里，这与一线项目的体感完全一致。

但把这份美国市场的说明书直接搬进中文环境，会栽在它没写的三处。一是人才地图不可平移：国内同款人才散落在 ERP/MES 实施顾问、系统集成商交付工程师和大厂 B 端解决方案团队里，照 JD 头衔去寻源只会招空，17 万美元起步的挂出价薪资带宽，国内预算体系也接不住。二是「嵌入客户现场」这个前提在跨境业务里最容易断：数据出境评估、客户等保要求、签证与驻场周期，任何一项都能让英雄式驻场变成三个月动弹不得——工程师进不去、数据出不来的跨境项目，我见过不止一个。三是运营侧的暗坑：FDE 的利用率被交付压力顶满之后，「把学到的东西带回核心产品」会沦为空话，两年后你得到的是一家挂着产品牌子的系统集成商。

行动建议：在对外开放这个岗位之前，先花一周盘点内部——把交付、实施、售前团队里能在客户环境写生产代码、又扛得住客户会议的人列成名单，用带真实脱敏数据的两天驻场模拟去验证。内部藏着的 FDE，往往比按美国指南抢来的人更快形成战斗力。

—— FDEChina编辑部 · 实战派

# Recruiting Forward Deployed Engineers: 2026 Guide

Recruitment Strategies
44
min read
Recruiting Forward Deployed Engineers: 2026 Guide

How to source, screen, and hire forward deployed engineers in 2026: the roles, real pay bands, where they hide, interview loops, and failure modes to avoid.

Yuma Heymans
Aug 6, 2026
Share:

The insider hiring guide to the fastest-growing engineering role of 2026: who forward deployed engineers really are, what they cost, where they hide, and how to land them before your competitor does.

Monthly job listings for forward deployed engineers rose more than 800% between January and September 2025 – PYMNTS. That single line explains why a role most recruiters had never heard of two years ago is now the hardest hire on the board at OpenAI, Anthropic, Palantir, Ramp, and roughly every applied-AI startup that has raised a Series A. The forward deployed engineer, or FDE, has become the person who decides whether a company’s AI actually works inside a customer, and there are nowhere near enough of them.

The trouble is that the FDE is the most miscast job title in technology right now. The people who are genuinely good at it almost never carry the label, the strongest candidates are already embedded in a customer deployment and not looking, and most hiring teams screen them with a standard software loop that rejects the exact traits that make an FDE valuable. A brilliant back-end engineer who freezes in a customer meeting fails at this job, and so does a polished consultant who cannot debug a production system, yet a normal interview process catches neither failure. Get the role wrong and you spend three months and a retained-search fee hiring someone who quits after their fourth week of travel.

This guide is the practical map for anyone who has to actually fill the role, written for recruiters and hiring managers rather than for people who want to become an FDE. It covers what a forward deployed engineer really is and where the title came from, why demand went vertical in 2025 and 2026, exactly who is hiring and how their models differ, what these people cost, the traits and backgrounds that predict success, where to find candidates who never use the title, how to write a job description and an interview loop that screen for both halves of the job, how to keep FDEs from burning out, when the role is the wrong hire entirely, and how AI agents are now reshaping both the FDE’s work and the hunt for them.

This guide is written by Yuma Heymans (@yumahey), who built HeroHunt.ai, the AI recruiter that sources engineers from more than a billion profiles. He spends his days on the exact problem at the center of this market, finding scarce technical people who never carry the obvious title, which is precisely why forward deployed engineers, a group that almost never calls itself that, are a case he knows well.

Contents
What a Forward Deployed Engineer Actually Is
Why FDE Hiring Exploded in 2025 and 2026
Who Is Hiring FDEs: The 2026 Landscape
What Forward Deployed Engineers Really Cost
The Profile: Traits and Backgrounds That Predict Success
Where to Find FDEs: Sourcing the Passive Pool
Writing a Job Description That Attracts the Right Half
The Interview Loop: Screening Both Halves
Closing, Retention, and the Burnout Problem
When an FDE Is the Wrong Hire: Limits and Failure Modes
How AI Agents Are Changing the Hunt
The Future Outlook: Durable Role or Hype Cycle
The Recruiter’s Playbook
1. What a Forward Deployed Engineer Actually Is

A forward deployed engineer is an engineer who embeds inside a customer, writes and owns production code in that customer’s systems, and stays until the deployment actually works, then carries what they learned back into the core product. That is the whole role in one sentence, and every hiring decision downstream flows from it. The FDE is not a consultant who delivers a slide deck, not a sales engineer who runs pre-sales demos, and not a back-end engineer who ships features from headquarters. They are a hybrid built to close the gap between what a product can do in theory and what it does inside one specific, messy, real organization.

The title was invented at Palantir, where the internal name for the role is Delta. In Palantir’s own framing, a Delta (a Forward Deployed Software Engineer) sits inside Business Development and deploys the company’s platforms to a single customer, while a Dev (a product software engineer) sits inside Product Development and builds Foundry and Gotham for everyone. Palantir describes the split memorably: a Dev’s focus is one capability, many customers, and a Delta’s focus is one customer, many capabilities – Palantir. The name itself is a holdover from Palantir’s early days, when each Business Development team was labeled with a NATO-alphabet letter, and it deliberately signals that a Delta is not a consultant: they build durable solutions the customer keeps improving, and they can push code back into the core products.

The concept goes back further than the current hype, and its origin story is worth knowing because it defines the temperament you are hiring for. Palantir CTO Shyam Sankar is credited with coining the term, inspired by a 2006 comment from CEO Alex Karp that at a French restaurant the wait staff are really part of the kitchen. Sankar named the model forward deployed engineering in 2007 – Pirate Wires. His description of the ideal FDE is still the sharpest one written: someone "crazy enough to get on a last-minute plane to Iraq," "smart enough to ship quality, same-day code," with an EQ "still high enough to talk to users (and maybe even enjoy it)." Hold that image, because it is three different people fused into one, and the fusion is exactly what makes the role scarce.

Palantir leaned so hard into the model that, up until roughly 2016, the company had more forward deployed engineers than it had traditional software engineers – The Pragmatic Engineer. The day-to-day rhythm of the job explains why it demands such an unusual person. One Palantir FDE described a typical week as a couple of days physically at the customer’s premises understanding their problems, then time back in the office writing code changes and reviewing pull requests. That alternation, between the customer’s world and the product’s codebase, is the defining texture of the role and the thing a standard engineering job never asks for.

To make the last mile concrete, picture what an FDE actually inherits on day one at a large customer. The model works beautifully in a demo, but the customer’s data is scattered across a mainframe, three SaaS tools, and a warehouse nobody fully understands, half the useful fields are unstructured free text, the security team will not allow anything to leave a private cloud, and the workflow the AI is meant to improve was never documented because it lives in the heads of four analysts. The FDE’s job is to turn that into a working, trusted deployment: wiring up retrieval against the real data, designing evaluations that catch a hallucination before a regulator does, building the agent workflows, and standing up the observability that tells everyone whether it is actually working. None of that is model research and none of it is generic back-end work, which is exactly why it takes a distinct kind of engineer and why the market cannot simply retrain existing developers into the role overnight.

The cleanest way to understand the FDE is by what it is not, because the distinctions are exactly where hiring goes wrong. Against a solutions architect, the FDE is far more hands-on and actually writes production code on the customer’s infrastructure rather than advising from a whiteboard. Against a sales engineer, the FDE contributes to the core product roadmap rather than running pre-sales. Against a normal software engineer, the FDE deliberately splits attention between the customer and the platform. The diagram below shows the three worlds an FDE straddles, and internalizing it is the first defense against writing a job description for the wrong person.

Where a Forward Deployed Engineer Sits
The overlap that makes the role hard to hire for

Customer domain
data, compliance, workflows

Forward Deployed
Engineer

Production engineering
ships code in the client stack

Product and model
prompts, RAG, evals, agents

A deployment that survives
contact with the customer

For a fast primer on what the role involves and why it is spreading, the talk below from Kevin Bai, who helped scale Palantir’s FDE function, later founded the FDE org at Rippling, and now works on Anthropic’s Applied AI team, is the single most useful 20 minutes a hiring manager can spend. It frames when an FDE is actually needed and how the function should be structured, which is precisely the calibration a recruiter needs before opening a requisition.

Forward Deployed Engineering 101: Kevin Bai
Source: AI Engineer (YouTube), 2026. Kevin Bai (ex-Palantir, ex-Rippling founding FDE, now Anthropic Applied AI) on what the role is and how to structure the function.
2. Why FDE Hiring Exploded in 2025 and 2026

The FDE boom is not fashion, it is a direct response to the single most important number in enterprise AI: roughly 95% of enterprise AI pilots deliver no measurable business impact, a finding from MIT’s NANDA project that circulated through every boardroom in late 2025 – MarkTechPost. The failures are overwhelmingly on the deployment side, not the model side. The model is good enough. What breaks is the last mile: fragmented data, legacy systems, compliance constraints, and workflows nobody documented. The forward deployed engineer exists to survive that last mile, which is why every company selling AI to enterprises suddenly needs a battalion of them.

The hiring data reflects a genuine vertical takeoff. Beyond the 800% surge in the first three quarters of 2025, Indeed’s postings data showed forward deployed engineer listings up roughly 729% year over year by April 2026, reaching a level about 5,230% above the January 2025 baseline, with Anthropic, OpenAI, Palantir, Stripe, and Google Cloud among the named hirers and advertised pay from about $170,000 to over $200,000 – Business Insider via AOL. Even the softer signal points the same way: mentions of forward deployed engineering in company documents rose about 17% in six months according to AlphaSense data cited by LeadDev – LeadDev. When a job title shows up in earnings calls and internal memos, the requisitions are not far behind.

Underneath the demand sits a wave of capital that has to convert into deployed software to justify itself, and that conversion is human. The scale of enterprise AI investment is the pressure behind the hiring, because every dollar of model spend eventually needs someone to make it work at a customer. The chart below, from Stanford’s AI Index, shows how steeply corporate AI investment has climbed, and the deployment gap is what turns that spend into FDE headcount.

Source: Stanford HAI 2026 AI Index Report (data: Quid). Enterprise AI investment climbed steeply, and forward deployed engineers are the headcount that turns that spend into working deployments.

The strategic idea that gave the trend a name is services-led growth, argued most influentially by Andreessen Horowitz, which in June 2025 called the FDE the hottest job in startups – a16z. The thesis inverts a decade of software orthodoxy. Pure product-led growth optimizes gross margin by keeping humans out of the loop, but for complex enterprise AI, the fastest path to revenue and to an unassailable moat is to put expensive engineers directly inside customers, absorb the messy integration work, and own the data layer nobody else can touch. You trade near-term margin for durable position. The a16z chart below contrasts the two curves and explains why sophisticated investors now reward the implementation-heavy model that looks worse on a spreadsheet.

Source: Andreessen Horowitz, Trading Margin for Moat (June 2025). Implementation-heavy, services-led companies trade early margin for a durable moat, which is why they staff forward deployed engineers aggressively.

For a recruiter, the practical consequence of this shift is that the FDE requisition is not a normal engineering req that happens to be trendy, it is a structurally different and structurally scarcer hire whose price is set by a bidding war between frontier labs and well-funded startups. The demand is real, it is durable for at least the next few years, and it is concentrated on a profile that the market has not produced in anything like the required numbers. Everything that follows in this guide is downstream of that imbalance, because scarcity is what sets the salary, dictates the sourcing strategy, and explains why these candidates behave nothing like the engineers you hired five years ago.

3. Who Is Hiring FDEs: The 2026 Landscape

The FDE hiring landscape splits into three tiers, and knowing which tier you sit in tells you who you are really competing with for talent. Tier one is Palantir, the originator, which still runs the largest and most mature forward deployed function and remains the template everyone else copies. Tier two is the frontier labs, principally OpenAI and Anthropic, which stood up dedicated FDE teams in 2025 to move their models from impressive demo to production reality inside strategic enterprise and government accounts. Tier three is the fast-growing field of applied-AI startups and enterprise platforms, from Glean and Sierra to Distyl, Decagon, Ramp, Databricks, Scale, Cognition, Mistral, and Harvey, each adapting the model to its own product.

The most useful distinction for a recruiter cuts across those tiers: product-led versus services-led. Product-led companies (Glean, Sierra, Decagon, Ramp) deploy their own platform, and their FDEs drive zero-to-one product surfaces and land-and-expand inside big accounts. Services-led companies (Palantir, Databricks, Distyl) own end-to-end delivery inside the customer’s stack. The frontier labs sit in between, delivering a model and API through a heavy layer of embedded engineering. This distinction matters because it changes the candidate you want: a services-led FDE lives closer to bespoke customer work, while a product-led FDE needs a stronger instinct for what generalizes back into the roadmap.

That distinction should change who you shortlist, not just how you describe the role. For a services-led team like Palantir or Distyl, the ideal hire is energized by going deep on one customer’s gnarly problem and does not resent building something genuinely bespoke, so you weight the screen for domain curiosity and stamina. For a product-led team like Glean or Sierra, the ideal hire instinctively asks which customer request is really a product feature in disguise and has the discipline to say no to one-off work that will never generalize, so you weight for product judgment. Hiring a deep-bespoke builder into a product-led role produces an engineer who drowns the roadmap in custom features nobody else can use, and hiring a product generalist into a services-led role produces someone who is quietly bored and gone within six months. The tier and the model together, not the title, define the person.

Palantir remains the reference point, and it still hires the role at volume across seniority levels, including new-grad requisitions with an estimated base of $135,000 to $145,000 on its careers board – Palantir Jobs. What makes Palantir strategically important to a recruiter is not that you will win candidates from it easily, because you usually will not, but that its alumni are the single most sought-after talent pool in the category, a point the sourcing section returns to. The company deliberately built a generalist, high-agency engineering culture, and the market now treats a former Palantir Delta as the closest thing to a proven FDE.

The frontier labs professionalized the role in 2025 and then institutionalized it in 2026. OpenAI runs a dedicated forward deployed team hiring across a long list of cities including San Francisco, New York, London, Paris, Munich, Seoul, and Tokyo, typically asking for five or more years of experience – OpenAI. Anthropic brands its version Forward Deployed Engineer, Applied AI, and describes it plainly: engineers who "work within customer systems to build production applications with Claude models," deliver MCP servers and agent skills, and travel 25 to 50 percent of the time to customer sites, with a Munich posting listing €205,000 to €220,000 and asking for four or more years in a technical, customer-facing role – Anthropic. Both labs went further in May 2026, standing up dedicated delivery vehicles: OpenAI reportedly created a majority-owned deployment company led by COO Brad Lightcap, and Anthropic launched a roughly $1.5 billion enterprise venture, with CFO Krishna Rao noting that "enterprise demand for Claude is significantly outpacing any single delivery model" – MarkTechPost.

The third tier is where the role is proliferating fastest and where the titles get creative, which is a trap for keyword-based sourcing. Glean hires a "Founding Forward Deployed Engineer" at $160,000 to $270,000 base, framed as zero-to-one product creation with founder-level autonomy – Glean. Distyl AI hires FDEs in San Francisco and New York at $150,000 to $250,000 plus equity to "own the behavior and performance of AI systems deployed for customers" – Distyl AI. Ramp posts a "Software Engineer, Forward Deployed" at $161,500 to $190,000 plus equity to build custom integrations for its largest accounts – Ramp. Sierra renames the role entirely, calling it an "agent engineer" who works with customers to design, build, and ship agents on its platform – Sierra. Add Databricks (an established services-led FDE function under Professional Services), Scale AI, Cognition (which calls it a "deployed engineer"), Mistral in Europe, and Harvey in legal, and the picture is clear: the role has jumped from a single company to the entire applied-AI economy in under two years.

The renaming is not a cosmetic detail, it is an active sourcing hazard, and it is worth translating for your whole hiring team before you start. Sierra calls it an agent engineer, Anthropic calls it Applied AI, Cognition calls it a deployed engineer, and Ramp files it under ordinary software engineering, which means a recruiter who searches only for the exact phrase forward deployed engineer will miss most of the market and, just as importantly, misjudge who they are losing candidates to. When you benchmark compensation, scope a requisition, or map the competition, collapse all of these labels back to the same underlying job. The companies use different words for one profile, and the candidates use different words again, so treating the title as the unit of analysis is the fastest way to build the wrong picture of your own market.

4. What Forward Deployed Engineers Really Cost

Forward deployed engineers are paid like scarce senior engineers plus a premium for the customer-facing half, and the first budgeting mistake is benchmarking them against a normal software salary. The honest headline is a wide band: advertised base pay for FDE roles in 2026 runs from roughly $135,000 for a new grad to $270,000 for a founding or senior hire, and that is before equity, which at startups and labs frequently rivals or exceeds base. LeadDev cites an average FDE base around $171,911, which is a reasonable midpoint to anchor on, but the spread around it is enormous and driven mostly by seniority and company stage – LeadDev.

The clearest way to see the base-pay landscape is to line up the advertised ranges from real 2026 postings, remembering that these span different seniorities from new-grad to senior. The chart below plots the midpoint of each posted base range. The point is not any single bar but the shape: entry sits near $140,000, and senior or founding roles cluster around $200,000 to $220,000 in base alone, with equity layered on top.

Advertised Base Pay for Forward Deployed Roles (2026)
Palantir (new grad)
Ramp
Distyl AI
Scale (senior)
Glean (founding)
Databricks (senior)
Employer (role level)
0
55000
110000
165000
220000
Base salary range midpoint (USD)

Total compensation, once equity is included, tells a more dramatic story at the top. Palantir’s FDSE-specific total comp on Levels.fyi runs roughly $171,000 to $295,000 with a median near $211,000, while Palantir software engineers overall show a median total compensation around $250,000 on a range of $145,000 to $426,000 – Levels.fyi. At the frontier labs the equity component pushes the ceiling far higher: OpenAI software engineer total compensation ranges from about $253,000 at entry to a median near $860,000 and past $1.1 million at staff level, and while those figures are for software engineers broadly rather than FDEs specifically, they set the gravitational field that a lab’s forward deployed comp is pulled toward – Levels.fyi. An FDE at a frontier lab is not paid like a consultant, they are paid like a scarce senior engineer who also happens to fly to customers.

Two structural features of FDE pay matter for how you build an offer. The first is that base and equity are separate negotiations with separate logic: base compensates the grind and the travel, while equity is the real wealth lever at a startup or lab, and a candidate leaving a big-tech salary for a Series A FDE role is trading current cash for a bet on the company. The second is geography, which is shifting in a way that helps some employers. New York has overtaken San Francisco as the center of FDE demand, holding about 35 percent of postings against San Francisco’s 11 percent per Uplers, which reflects how much of this hiring is enterprise-facing rather than pure research – Uplers. For a recruiter, that means the talent map for FDEs looks more like the map of enterprise software than the map of AI research, and it opens metros that a frontier research role would not.

The practical budgeting conclusion is liberating rather than intimidating for most employers. Unless you are a frontier lab, you are almost never competing head-to-head with OpenAI’s million-dollar packages, because those are reserved for a tiny population and are mostly equity bets on a specific company. Your real competition is the rest of the enterprise-software and applied-AI market, where a base in the $160,000 to $220,000 range plus meaningful equity, real ownership, and interesting customer problems is genuinely competitive. The mistake is to either panic at the lab numbers and give up, or to lowball against last year’s back-end salaries and wonder why strong candidates ghost you.

When you actually build the offer, the decision a strong candidate is weighing is rarely base against base, it is cash certainty against equity upside, and naming that trade-off out loud closes more of them than quietly nudging the salary. A senior engineer sitting on a $250,000 base at a big tech company will not move to a Series A forward deployed role for a lower base and a vague grant, but they will move for a slightly lower base plus a meaningful early-stage equity position, a real customer relationship to own end to end, and problems they find genuinely interesting, provided you make the equity concrete and the ownership believable. The employers who lose these candidates are usually the ones who presented the offer as a single salary number, apologized for not matching a lab, and never articulated the upside they actually had. Sell the whole package, be honest about which compensation universe you are competing in, and spend your energy on the levers you can genuinely pull rather than the one you cannot.

5. The Profile: Traits and Backgrounds That Predict Success

The single most important thing to accept before you screen a single resume is that the trait that makes a great FDE resists a standard rubric, which is why the role is, in one recruiter’s phrase, "scarce, expensive, and brutal to interview for" – The VC Corner. You are not looking for the best engineer or the best communicator, you are looking for the rare person who is strong enough at both that neither one collapses under pressure. Everything about the profile follows from that dual requirement, and the most common hiring failures come from optimizing one axis and ignoring the other.

The most useful trait list comes from First Round Review, drawn from ex-Palantir practitioners, and it is worth memorizing because it is more predictive than any keyword search. Strong FDEs show grit, described bluntly as a willingness to eat pain, alongside staff-level technical rigor, a habit of prolific building, genuine business curiosity, and a bias toward problem-solving over pattern-matching – First Round Review. That last one matters more than it sounds. A pattern-matcher applies a known playbook, and FDE work punishes playbooks because every customer is differently broken. The people who thrive are the ones who treat an ambiguous, undocumented mess as an interesting puzzle rather than a threat.

Background is a strong but counterintuitive predictor, and this is where a lot of hiring teams over-index on the wrong signal. The clearest positive signal is having been one of the first ten engineers at a startup, where ambiguity, customer contact, and full-stack ownership are unavoidable – The Pragmatic Engineer. Ex-founders who actually shipped and scaled something are a bonus for the same reason. The surprising anti-signal is deep, comfortable tenure at a big tech company: First Round reports that candidates who spent more than ten years at a FAANG company were effectively in a "no fly zone," because the traits that get rewarded inside a large, specialized org (deep focus on a narrow surface, reliance on internal tooling) are close to the opposite of what an FDE needs. Recent grads made up the bulk of Palantir’s early FDE roster, some with barely a year of experience, precisely because they had not yet learned a fixed playbook.

The dual requirement also defines the red flags, and both failure modes are symmetric. On one side is the brilliant engineer who cannot debug an unfamiliar production system under time pressure or who freezes in a room full of skeptical customer stakeholders. On the other is the polished, articulate consultant who interviews beautifully but cannot actually write and ship the code – Uplers. A recruiter’s job is to screen for both halves deliberately, because a process tuned to catch only one will pass candidates who fail on the other. The consultant-shaped candidate is especially dangerous because they perform well in exactly the parts of the interview that feel most like the job.

There is a subtler quality that separates good FDEs from merely charismatic ones, and it is worth training your hiring managers to look for: the willingness to tell a customer they are wrong. The best Palantir-style FDEs interrogate whether the customer’s proposed solution is actually right, and vocally propose alternatives backed with data, rather than simply executing whatever was requested – LeadDev. That is a specific kind of client-facing judgment, not general likeability, and it is the difference between an FDE who quietly builds the wrong thing well and one who changes the outcome of a deployment. Screen for the candidate who has a story about pushing back on a customer and being right, not just the one who is pleasant on a call.

A concrete way to picture the deciding trait is to imagine the same problem handed to two strong engineers. Told that a customer’s data pipeline keeps silently dropping records, the pattern-matcher reaches for the last framework that worked and starts implementing it, while the problem-solver first asks what the records represent, who would notice if they vanished, and what the customer actually needs the pipeline to guarantee, and only then writes any code. In a normal product role that difference is minor. In a customer deployment, where the approach that worked at the last client is often exactly wrong for this one, it decides whether the project succeeds or quietly rots. Grit is the other half of the same picture: the willingness to sit in a windowless room at a client site for a week untangling a mess that is not your fault, because that is simply what a working deployment requires. Screen for the candidate who has obviously done that and would do it again, not the one who describes the pristine engineering environment they need in order to be productive.

6. Where to Find FDEs: Sourcing the Passive Pool

Forward deployed engineers are a passive-sourcing problem almost by definition, and accepting that up front will save you months. As one specialist recruiter puts it, "the best FDEs aren’t browsing listings because they’re knee-deep in a customer deployment" – Paraform. Posting a job and waiting produces a pipeline of consultants who like the title and back-end engineers who want to travel less than the role requires. The candidates you actually want are employed, busy, and not looking, which means outbound sourcing is not one channel among several, it is the channel.

The deeper problem is that the strongest FDE-shaped people rarely carry the title on LinkedIn. An ex-Palantir Delta often shows up as "Software Engineer," a founding engineer as "Co-founder," and a consultant-turned-builder as "Solutions Architect." Searching for the literal phrase "forward deployed engineer" returns a thin, self-selected pool and misses the best candidates entirely – Uplers. Effective sourcing therefore keys on evidence of the work rather than the label: someone who shipped production code inside a customer environment they did not build, who has startup ambiguity in their history, or whose GitHub shows integration and data-pipeline work rather than pure library development. This is a semantic sourcing problem, not a boolean one, which is exactly why title-based search underperforms here.

A concrete example makes the gap obvious. A boolean search for the title "forward deployed engineer" on a major network might return a few thousand self-identified profiles, most of them clustered at the handful of companies that use the exact label. A signal-based search for the underlying profile, engineers who list a customer deployment they personally owned, a founding role at a company that no longer exists, or a move from a consulting firm into an engineering seat, returns a far larger and far stronger pool, most of whom would never surface for the title. The recruiters who win this search are the ones who stop hunting for the word and start hunting for the evidence, because the word is the one thing the best candidates reliably do not put on their profile.

That gap between the profile and the label is where modern AI sourcing earns its place, because a tool that searches on signals rather than exact titles can surface people a keyword filter never will.

HIGHLIGHT

HeroHunt.ai

The hardest part of FDE sourcing is that the strongest candidates never carry the title: an ex-Palantir Delta reads as "Software Engineer," a founding engineer as "Co-founder." HeroHunt.ai searches across more than a billion profiles on signals (production code shipped inside a customer’s environment, startup-founding history, a consulting-to-engineering move) instead of the literal words "forward deployed," then drafts the outreach automatically. The honest caveat worth stating plainly: an AI sourcer surfaces the engineering half of the profile, not the client-facing half. Whether a candidate can hold a room of skeptical bank stakeholders is still something only your interview loop can judge, so treat the shortlist as the start of screening, not the end.

Try HeroHunt.ai free
→

Beyond the tooling, the highest-yield channels are specific talent pools you can target deliberately. The gold-standard pool is the Palantir alumni network, which one recruiter describes as one of the densest and most loyal in tech, where a single referral often opens many more doors – Recruiting from Scratch. Beyond Palantir, the productive pools are backend engineers coming out of AI labs, enterprise solutions architects who miss writing code, and technical consultants from firms like McKinsey, BCG, or Accenture Federal who are tired of billable hours and want to build. Each of these groups contains people who already have half the profile and are a plausible bet on the other half.

Two operational realities make sourcing more efficient. First, referrals compound in this category more than most, so mining your own team’s former colleagues and asking every strong candidate for names is disproportionately effective given how networked the Palantir-and-startup world is. Second, a growing set of specialist recruiting networks now exists specifically for this profile, such as Betts Connect’s pool of go-to-market and deployment candidates and Paraform’s recruiter network, which has placed FDEs at Palantir, Rippling, Decagon, and Cognition – Betts Recruiting. These exist precisely because the strongest FDEs are not on job boards, and they can be worth the fee for a first critical hire. Whatever mix of channels you choose, budget realistically: a specialist search runs eight to twelve weeks, and contingency fees typically land around 25 percent of first-year salary, roughly $50,000 on a $200,000 package – Paraform.

7. Writing a Job Description That Attracts the Right Half

The FDE job description is the most common early mistake, because the instinct is to write an engineering req with a longer requirements list, and that instinct filters out exactly the people you want. The core rule from practitioners is to hire for traits, not credentials, and specifically to stop listing tools. A weak FDE posting reads like a back-end job and enumerates LangChain, Kubernetes, Pinecone, Docker, React, Go, and Rust as requirements, which signals to a strong generalist that you want a specialist and signals to the wrong candidates that a tool checklist is the bar – Uplers. The FDE will learn whatever stack the customer runs. What they cannot fake is the disposition to own an ambiguous, high-stakes deployment end to end.

A strong description centers on capabilities and situations instead. It describes the reality of the job (embedding with customers, debugging production systems you did not build, translating between a customer’s business problem and a technical solution) and it screens hard on ownership. The single best litmus line practitioners recommend baking into both the JD and the screen is deceptively simple: the customer is blocked, figure it out. That framing attracts the person who is energized by ambiguity and repels the person who needs a well-specified ticket, which is precisely the filter you want operating before anyone reaches a phone screen.

The JD also has to be honest about the two things that cause the most expensive mismatches later: travel and the services-versus-product split. If the role involves being onsite at customers 25 to 50 percent of the time, as most lab and enterprise FDE roles do, say so in the first third of the posting, not the last line. Recruiters who have run this search repeatedly warn that "60 percent travel that sounds fine in the abstract" is a leading cause of early attrition, and the fix is to make it concrete and interview against it upfront – Recruiting from Scratch. A candidate who self-selects out because of travel at the JD stage is a gift, not a lost lead.

There is a scoping decision the JD has to make on your behalf, and getting it wrong wastes an entire pipeline. "FDE" now spans at least three distinct flavors: the integration specialist who wires the product into customer systems, the post-sales implementation engineer who owns go-lives, and the product-embedded engineer who feeds the roadmap. Misalignment between the hiring manager and the recruiter on which flavor you are filling is a documented way to burn months of sourcing – Paraform. Decide before you write a word whether this person’s success is measured in customer deployments shipped, revenue expanded, or product improvements landed, and write the JD to that definition. The description is where you either recruit the right half of the market or quietly recruit the wrong one.

It helps to see the difference in actual language. A weak requirement line reads: five or more years building distributed systems, expert in Kubernetes, Go, and Terraform, deep experience with vector databases. A strong one reads: you have shipped software that ran inside someone else’s company and been the person the customer called when it broke, you are comfortable when the brief is a paragraph of ambiguity rather than a ticket, and you would rather learn a customer’s strange legacy stack than insist they adopt yours. The first version recruits a specialist who will be miserable the first time a customer changes their mind. The second recruits the person who is energized by the exact part of the job that cannot be automated. Go through your posting line by line and rewrite each requirement to describe a situation the candidate will face rather than a tool they must already know, and the applicant mix shifts before you have sourced a single name.

8. The Interview Loop: Screening Both Halves

The FDE interview loop has to do something a standard software loop does not: measure the customer-facing half without lowering the engineering bar. Companies that hire FDEs well replace the generic algorithm gauntlet with a loop built around ambiguity and communication, and the centerpiece is almost always an open-ended case rather than a LeetCode problem. Palantir’s own onsite is the clearest example, structured around rounds it calls decomposition and learning that have no real FAANG equivalent, alongside coding and system design, and it deliberately prohibits AI tools during the technical rounds – Exponent. The signal being measured is not whether the candidate memorized an algorithm, it is how they think when the problem is deliberately underspecified.

The decomposition round deserves special attention because it is the truest proxy for the job. The candidate is handed a vague, real-world problem and asked to break it into requirements, stakeholders, data models, APIs, workflows, and tradeoffs, and there is no single correct answer, only better and worse structure – Exponent. This is exactly what an FDE does in their first week at a new customer, and it exposes the two most important things at once: whether they can impose order on chaos, and whether they instinctively ask the customer questions before proposing a solution. The most common instant-failure red flag in these rounds is a candidate who leaps to a solution without clarifying what the customer actually needs, which is the same behavior that sinks a real deployment – Perspective AI.

A good decomposition prompt looks deceptively small and then opens into everything. Give the candidate a single sentence, such as a regional hospital network wants to use your product to automatically triage inbound patient referrals, and watch where they go. The strong candidate immediately starts asking rather than designing: who sends the referrals and in what format, what does triage even mean to a clinician versus an administrator, what happens today when it goes wrong, which decisions are safe to automate and which are legally fraught, and how would anyone know the system is working once it is live. The weak candidate starts drawing boxes for a solution to a problem they have not yet understood. You are not grading the elegance of the architecture, you are grading whether they instinctively treat an ambiguous customer request as a set of questions to answer before it is a system to build, because that instinct is the single behavior most predictive of whether they will thrive in front of a real customer.

The customer-facing half needs a dedicated round, not a vibe check tacked onto the debrief. The most effective format practitioners use is a teach-us exercise: the legal-AI company Ironclad, for instance, asks candidates to present a problem from their own career and teach the panel how they used technology to solve it, which surfaces communication, judgment, and depth simultaneously – First Round Review. A sharp companion question, recommended for probing real client judgment, is to ask the candidate about a time a customer was wrong about what they needed and how they handled it. The answer separates the FDE who has genuine stakeholder spine from the one who is merely agreeable, which the profile section flagged as a core distinction.

A Forward Deployed Engineer Interview Loop
Where it diverges from a standard software loop

Recruiter screen
travel + motivation

Technical screen
debug production code

Ambiguous case
decompose a vague problem

Customer role-play
teach and push back

Debrief
grit and ownership signals

Two design principles keep the loop honest and fast. The first is that the loop must adapt to how engineers now actually work: Sierra runs an explicitly AI-native onsite of Plan, Build, and Review, where the build stage is a two-hour independent session using whatever AI tools the candidate prefers, judged on production-grade output and end-to-end ownership rather than trivia, and framed around "hiring for strengths, not just an absence of weakness" – Sierra. The second is speed, because top FDEs hold multiple offers and a slow loop loses them. Google reportedly compressed its FDE hiring from four to six interviews over weeks down to as few as two interviews in two days, and Box CEO Aaron Levie has stressed that the role needs deep technical skill paired with real business acumen, which is exactly the combination a compressed but well-designed loop is trying to confirm – The Pragmatic Engineer. A four-part sequence of a collaborative kickoff, a take-home prototype, a solution presentation, and reference checks with former customer-facing colleagues can hit both goals without dragging.

9. Closing, Retention, and the Burnout Problem

Hiring an FDE is only half the battle, because the same intensity that makes the role valuable makes it a burnout risk, and attrition here is expensive to absorb. The travel is real, the customer pressure is constant, and the work oscillates between exhilarating zero-to-one building and grinding, capped customization that goes nowhere. Practitioners are candid that "forward deployed engineering is painful" and that much of the work is "necessary but not strategic," which is a recipe for churn if left unmanaged – First Round Review. Retention is not a perk problem here, it is a scope-design problem, and it belongs to the manager.

The most important retention lever is active scope management by the manager, not the FDE. The manager’s job is to continuously rebalance work and to break off tasks that have no path toward a real software upside, so that the engineer is not trapped in an endless cycle of one-off customizations that never generalize. When the ratio of strategic building to pure services work tips too far toward services, strong FDEs leave, often to found their own startups or move into leadership. Guarding that ratio deliberately is what keeps them, and it is a management discipline that has to be designed into the role rather than hoped for.

Counterintuitively, requiring onsite time can be a retention lever rather than a cost, because of what it does for the work itself. Practitioners note that what an FDE discovers onsite is often radically different from what was sold in the contract, and being present at the customer is what lets them find the high-leverage problems worth solving rather than grinding through a stale requirements document – First Round Review. The travel that causes burnout when it is aimless becomes energizing when it consistently surfaces interesting problems, so the framing and the selection of which trips matter is itself a retention tool. An FDE who feels their onsite time is discovering real problems stays far longer than one who feels shipped around to babysit go-lives.

Structurally, teams that retain FDEs plan for turnover instead of being surprised by it. That means running defined tours of duty so the intense phases have an end in sight, keeping a bench so no single engineer is the irreplaceable owner of a critical account, and writing the succession plan before it is needed. The framing that works is to treat FDE churn as a known cost to be modeled and buffered rather than a failure to be prevented at all costs, because some of your best FDEs will leave to start companies no matter what you do, and a team designed around that reality stays healthy while one that ignores it lurches from crisis to crisis.

In practice, a tour of duty can be as simple as a stated expectation that an engineer owns a hard account for nine to twelve months, after which they rotate onto core product work or a fresh deployment of their choosing, with the rotation promised up front rather than negotiated later under duress. That one structural promise does two useful things at once. It gives the intense phase a visible finish line, which is what makes people willing to sprint through it, and it forces the team to document and cross-train so the account does not collapse when the engineer moves on. Teams that skip this end up with heroic individuals who quietly become single points of failure and then leave anyway, taking the only working knowledge of a critical customer out the door with them, which is a far more expensive outcome than the rotation would ever have cost.

10. When an FDE Is the Wrong Hire: Limits and Failure Modes

The most valuable thing a recruiter can do sometimes is tell a hiring manager they do not actually need an FDE, because the role has hard limits and hiring into them wastes money and burns candidates. The sharpest guardrail comes from practitioners directly: "forward deployed engineering is definitionally an upmarket motion," and "you should not be doing this if you believe the end shape of your product is product-led growth freemium" – First Round Review. FDEs make sense for large, complex customers with bespoke needs and a product that is not fully self-serve. Deploy them against a self-serve SaaS motion and you have added the most expensive headcount on the team to a problem it does not fit.

Title inflation is the failure mode that most distorts the market and the hiring process. As one consultant puts it, many organizations now call an FDE "anybody who’s customer-facing and a little bit technical," which hollows out the meaning and makes sourcing on the title nearly useless – LeadDev. Palantir’s own leadership has been dismissive of the copies, with global commercial head Ted Mabrey calling many competitor imitations a half measure that were largely failing. For a recruiter, the lesson is to distrust the title on both sides of the table: on the candidate side because strong FDEs do not use it, and on the requisition side because a hiring manager may be describing a support engineer or a sales engineer while asking for an FDE.

There is a genuine intellectual tension in the role that shows up as a limitation, and honest teams acknowledge it. Critics point out that adding "expensive, hard-to-find humans to replace humans doesn’t seem very sustainable," a real critique of a model that sells automation while staffing up on services – LeadDev. There is also a customer-trust dimension, since embedding external engineers deep inside a client’s systems raises questions about exposing proprietary data and processes. These are not reasons to avoid the model, but they are reasons to scope it carefully, to be clear with candidates about the services-heavy reality, and to avoid overselling the role as pure cutting-edge product work when a chunk of it is integration grind.

Finally, beware the two hiring extremes that the profile section warned about, because they are the concrete ways this goes wrong in practice. Over-index on Palantir pedigree and you will pay a premium for a brand while ignoring equally strong founders and startup generalists, and you will lose candidates in slow loops to faster competitors. Over-index on raw coding ability and you will hire someone who cannot survive a hostile customer meeting. The a16z guidance for building these teams is a useful corrective: recruit curious, high-agency hustlers with industry exposure rather than credential-stacked specialists, align FDE and account-executive incentives without imposing sales quotas that create perverse behavior, and prioritize genuine in-person presence with customers – a16z. The a16z best-practices summary below distills the build-team playbook into one frame worth keeping in front of the hiring committee.

Source: Andreessen Horowitz, Trading Margin for Moat (June 2025). Best practices for building an early forward deployed engineering team.
11. How AI Agents Are Changing the Hunt

AI agents are reshaping FDE recruiting from both ends at once: they make it possible to find candidates who never use the title, and they compress the sourcing and screening work that used to eat a recruiter’s week. This is not a speculative shift. Talent leaders are moving fast, with 84% planning to use AI in 2026 and 52% planning to add autonomous AI agents to their teams, according to Korn Ferry’s annual talent-acquisition trends report – Korn Ferry. For a role as hard to source as the FDE, that tooling is not a luxury, it is the difference between a full pipeline and an empty one.

The adoption curve is steep and the productivity payoff is concrete. LinkedIn’s Future of Recruiting research found 37% of organizations now actively integrating or experimenting with generative AI in hiring, up from 27% a year earlier, with heavy users saving roughly 20% of their work week, about a full day, and 73% of talent-acquisition professionals agreeing AI will change how organizations hire – LinkedIn. That reclaimed day matters most on the hardest searches, and few searches are harder than an FDE requisition where the best candidates are invisible to a keyword filter.

The specific reason AI sourcing fits the FDE problem so well is the title mismatch that this guide keeps returning to. Because a great FDE hides under labels like "Software Engineer," "Solutions Architect," "Applied AI," or an old Palantir "FDSE," a boolean search on the exact title returns a thin and misleading pool. Semantic and signal-based search that reads the career context, rather than matching a string, is what surfaces the person who did the work without ever claiming the label. A new wave of AI recruiting platforms is built precisely on that capability, and they are worth knowing by name.

HeroHunt.ai runs an autonomous AI Recruiter that sources, screens in natural language, and messages candidates across more than a billion profiles.
SeekOut offers agentic sourcing over a billion-plus profiles, with strength in deep technical and security-cleared talent.
Gem pairs an AI Sourcing Agent over 800M-plus profiles with application review and CRM, and counts Anthropic among its users.
Juicebox lets recruiters describe a role in plain English through PeopleGPT and returns ranked candidates with no boolean at all.
hireEZ layers agentic sourcing, screening, and outreach on top of your existing ATS.

In practice the workflow that works for an FDE search is a relay, not a handoff to a robot. You point the AI sourcer at the signals that actually predict the profile, ask it to surface a few hundred candidates who shipped inside customer environments or founded something, and let it draft a first outreach note that references the specific work rather than a generic template. Then a human takes over at the exact moment judgment starts to matter: reading between the lines of a career history, deciding whether a founder-turned-engineer will tolerate someone else’s roadmap, and writing the second message that actually earns a reply. The teams that get real value from AI sourcing use it to spend their scarce human attention on the twenty candidates worth a genuine conversation instead of the two hundred worth a database query.

The practical takeaway is not that a tool will hire your FDE for you, it is that AI changes where the human effort goes. The agent does the thing it is good at, casting a wide net across hidden profiles and drafting first-pass outreach, which frees your recruiters to spend their judgment on the thing AI cannot assess: whether a candidate can actually hold a room of skeptical customer stakeholders. That division of labor is why 73% of Korn Ferry’s talent leaders still rank critical thinking as their number-one hiring priority, ahead of AI technical skills – Korn Ferry. For FDE hiring specifically, use AI to solve the discovery problem and keep humans firmly on the client-facing evaluation, because that is the half of the role a resume and an algorithm will never reveal.

12. The Future Outlook: Durable Role or Hype Cycle

The weight of institutional money in 2026 says the forward deployed engineer is a durable category, not a passing fad, even if the title itself keeps drifting. The clearest evidence is where the biggest players are putting billions. OpenAI launched a standalone deployment company in May 2026, raising $4 billion from nineteen investors at a reported $10 billion valuation and explicitly borrowing Palantir’s model of parachuting engineers into clients, with the effort overseen by senior leader Brad Lightcap – TechCrunch. Anthropic launched a competing $1.5 billion enterprise venture the same month with Blackstone, Goldman Sachs, and Hellman & Friedman – CNBC. When the frontier labs stand up multibillion-dollar vehicles whose entire purpose is embedded deployment, the role underneath them is not a fad.

The clearest single signal came from AWS, which in June 2026 committed $1 billion to a dedicated forward deployed engineering organization seeded with thousands of FDEs, embedding pods of roughly five to six engineers per customer, with the Allen Institute, Cox Automotive, the NBA, the NFL, and Southwest already onboard – About Amazon. A billion-dollar commitment and thousands of hires is a structural bet on the model, and it tells a recruiter that FDE demand is not going to soften on the timeline of a normal workforce plan. The practitioner view aligns: specialist analysts argue the surge is a structural shift rather than cyclical hype, and a gap unlikely to disappear through 2027 as long as every enterprise carries unique data, workflows, and compliance constraints that require human integration – Paraform.

The historical precedent that services-heavy companies grow into healthy margins supports the durable read rather than the bubble one. Andreessen Horowitz points out that Workday climbed from a 54.1% gross margin at its IPO to roughly 75% as its early implementation-heavy motion matured, and frames the enterprise AI buyer as grandma getting an iPhone, someone who genuinely wants the technology but needs a person to set it up, which is the permanent niche the forward deployed engineer fills – a16z. The same analysis found that even a frontier model lab is riddled with the role rather than treating it as a temporary crutch. For a recruiter, the signal is that this is not a staffing bulge to be quietly unwound once the product matures, it is how an entire category of company now goes to market, which means the requisitions keep coming and the plan you build for this talent should assume years, not quarters.

The role itself is changing faster than almost any other, and this is the part recruiters most need to internalize, because it changes what you screen for. The VP of forward deployed engineering at Cursor put it starkly, saying that "if we are doing the same job we were doing six months ago, we have done something wrong," as AI agents push FDEs away from hands-on implementation and toward finding new high-value use cases – Latent Space. In the a16z framing, the FDE increasingly acts as a human manager for AI systems rather than a pure coder, which raises the premium on judgment, business sense, and customer instinct relative to raw implementation speed. Hire for the ability to learn continuously and to spot leverage, not for mastery of a stack that will be obsolete in two quarters.

The video below, a 2026 panel with practitioners from OpenAI, Ramp, and other applied-AI companies, is a useful current read on where the role is heading and how leading teams scope and staff it. It is worth watching before you finalize an FDE scorecard, because it surfaces how quickly the definition is moving at the companies setting the pace.

The Future of Forward Deployed Engineering
Source: South Park Commons (YouTube), May 2026. Practitioners from OpenAI, Ramp, Nominal, and Dataland on why FDE is becoming a critical role and how they staff it.

None of this means the skeptics are wrong, and a good recruiter holds both ideas at once. Some of the 2025 and 2026 demand is genuine "AI FOMO," some organizations are slapping the FDE label on ordinary support or sales-engineering roles, and there is a real risk that a poorly scoped FDE role decays into permanent technical firefighting with no durable career upside. One analysis of roughly a thousand postings puts total compensation for mid-level FDEs at $300,000 to $450,000 and senior at $450,000 to $550,000, heavily equity-weighted, which is exactly the kind of frothy number that invites a correction – Perspective AI. The balanced conclusion is that the underlying need, engineers who make AI work inside real enterprises, is durable and structural, while the title, the comp peaks, and the hype around them are cyclical. Hire for the durable need and stay skeptical of the froth.

13. The Recruiter’s Playbook

If you distill everything above into a sequence you can actually run, FDE hiring becomes five decisions rather than one overwhelming search. The order matters, because each decision constrains the next, and almost every failed FDE search traces back to skipping the first one.

Decide whether you even need an FDE. The role is an upmarket motion for complex enterprise customers and a non-self-serve product, and hiring one against a product-led, freemium future is the most expensive way to solve the wrong problem. Sometimes the honest answer to a hiring manager is that they want a sales engineer, a support engineer, or a solutions architect, and naming that early saves everyone a quarter. Only open the requisition once the deployment gap is real and proof-of-concept deals keep stalling on integration.

Scope the flavor before you write a word. Decide whether this person’s success is measured in customer deployments shipped, revenue expanded, or product improvements landed, because the integration specialist, the implementation engineer, and the product-embedded engineer are three different hires. Write the job description to capabilities and situations rather than a tool checklist, put the travel reality in the first third, and use the litmus that attracts the right half: the customer is blocked, figure it out.

Source the passive pool on signals, not titles. Assume the best candidates are employed, invisible under generic titles, and not looking, then go get them through outbound. Mine the Palantir alumni network and startup founding engineers, treat consultants-turned-builders as a live pool, and lean on AI sourcing tools such as HeroHunt.ai to surface people who never wrote "forward deployed" on their profile. Keep a human on every message that decides whether a scarce engineer engages, because this audience is the least forgiving of automation that reads like spam.

Screen both halves, and move fast. Replace the algorithm gauntlet with an ambiguous decomposition case and a teach-us or push-back round that tests real stakeholder judgment, and watch for the candidate who clarifies before solving. Then compress the loop, because top FDEs hold multiple offers and a two-week scheduling gap loses them to a competitor who ran two interviews in two days.

Retain by managing scope and planning for churn. Make it a manager’s explicit job to guard the ratio of strategic building to pure services work, use onsite time to surface interesting problems rather than to babysit go-lives, and model turnover with tours of duty and a bench instead of pretending your best FDEs will never leave to found companies. The teams that win the forward deployed engineer are not the ones with the biggest budgets, they are the ones who understand exactly who this rare person is and what actually keeps them, and that understanding is an edge available to anyone willing to learn the market rather than just outbid it.

This guide reflects the forward deployed engineering hiring market as of August 2026. Compensation, company programs, and demand in this field change month to month, so verify current details before making decisions based on them.

Find candidates 10x faster

HeroHunt.ai uses AI to find and engage top talent automatically.

AI-powered sourcing
Automated outreach
No credit card required
Start for free

Latest Articles
View all
Hire Around the $100K H-1B Fee (2026 Guide)

The $100K H-1B fee keeps flipping in the courts. Here is the 2026 playbook for hiring global talent around it: cap-exempt H-1B, O-1, L-1, TN, E-3 and EOR.

Recruitment Strategies
44 min read
How to Screen for Real AI Skills (2026)

AI skills are the most claimed and least verified credential of 2026. A practical guide to screening candidates for real, demonstrable AI ability and judgment.

Recruitment Strategies
44 min read
Nova Recruiter Pricing 2026: Cost and Alternatives

Nova Recruiter costs €0 to €199 a month plus per-candidate credits. See the real 2026 pricing, how the credit model works, and 8 alternatives compared.

Recruitment
23 min read

Ready to hire smarter?

Join thousands of recruiters using HeroHunt.ai to find top talent.

Free to start
No credit card required
Start for free

原文链接

What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026

Thu, 03 Sep 2026 17:40:13 +0000

原文把「知识双盲」讲得很清楚——客户懂业务不懂模型，实验室懂模型不懂业务，两边合起来才能把东西做上线。这个判断我在交付一线完全认账，但它漏了决定这个模式生死的前提：Palantir 的 FDE 之所以成立，不是因为工程师坐进了客户现场，而是每次驻场沉淀的集成、prompt、数据管道最终都回流成了平台的产品能力。驻场本身是成本项，产品回流才是收入项。国内不少团队学 FDE 只学前半句，人常年泡在客户现场，交付物全是客户私有的 one-off 脚本，两年下来就是一家毛利更差的外包公司——这是原文没讲的第一坑：没有产品回流闭环的 FDE，本质是高级定制外包，所谓的黏性来自客户懒得换人，而不是换不起系统。

第二坑在退出机制。原文说 FDE「stays until it runs in production」，实战里这只是必要条件：我见过太多系统在 FDE 撤场三个月内腐烂，不是代码差，是客户侧没有指名 owner，没人敢动、没人会修。供应链和跨境场景还多一层——你嵌进客户 VPC 的那一刻，工程师本人就成了数据出境的一条路径，这不再只是技术问题，而是合规问题。对个人，风险同样被低估：客户特定知识攒得越多，可迁移性越差，议价能力押在雇主品牌上，跳出这家公司，简历上的 FDE 在很多招聘方眼里只是「驻场过的工程师」。

给你一条可执行的建议：下个项目签 SOW 时，把「客户侧指名对接人＋每周投入工时＋撤场后运维责任归属」写成硬条款。客户不肯指定对接人的项目，基本可以预判会滑向无限期驻场外包——这条判断标准，比任何方法论都便宜好用。

—— FDEChina编辑部 · 实战派

# What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026

来源：Michal Sutter · 2026-05-21T04:58:31+00:00

Artificial Intelligence

AI Infrastructure

Technology

AI Shorts

Applications

What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026

A plain-language guide for early-career AI engineers, software engineers, and data scientists.

What is a Forward Deployed Engineer?

The term ‘Forward Deployed Engineer’ (FDE) sounds military. That is intentional.

A Forward Deployed Engineer is a software engineer who works embedded with the customer’s technical and operational environment on-site, hybrid, remote, or inside a customer cloud or VPC, depending on the engagement. The FDE does not sit at a home office writing documentation. The FDE works alongside the client’s domain experts, inside the client’s workflows, and writes real code that runs in the client’s production systems.

The role differs from traditional advisory consulting because FDEs own implementation and production delivery. Consultants write reports and recommendations; an FDE builds the actual system and stays until it runs in production. The role was coined by Palantir in the early 2010s, and it emerged from a problem Palantir could not solve any other way.

The Origin: Palantir’s Intelligence Agency Problem

Palantir was founded in 2003 to help U.S. intelligence agencies make sense of large, fragmented datasets. The problem was not purely technical.

Intelligence agencies could not clearly describe what they needed. They could not openly share their data. Their workflows changed constantly. A traditional software product could not keep up. Palantir’s engineers had to go inside the agencies and work out the problem on-site. These early on-site engineers were called ‘Deltas.’

Until 2016, Palantir had more FDEs than software engineers. That ratio is unusual by software company standards. It shows how central the embedded model was to the business from the start.

The FDE role was inspired by how high-end French restaurants operate. The front-of-house staff is deeply integrated with the kitchen. They are empowered to tell customers ‘no’ if the customer is ordering incorrectly. Palantir applied that same philosophy to enterprise software delivery.

Why Standard SaaS Does Not Work for Complex AI Deployments

To understand why the FDE model is trending now, you need to understand where the standard SaaS model breaks down.

The standard enterprise software motion looks like this:

A company builds a product.

The sales team pitches it to clients.

A customer success manager helps with onboarding.

The client’s internal team integrates it.

This works for well-understood products like a CRM, a project management tool or an analytics dashboard. These have documented APIs, predictable behavior, and large communities who share implementation patterns.

AI systems break this model. There is a knowledge gap on both sides.

The client’s engineers know their business deeply: the data schemas, the compliance requirements, the edge cases, the legacy system architecture. The AI lab’s engineers know how models behave in production: the prompting patterns, the retrieval-augmented generation (RAG) strategies, the evaluation frameworks, the failure modes that appear only at scale.

Neither side has the other’s knowledge. And you need both to ship something that runs in production.

A customer success manager cannot bridge this gap. Documentation cannot bridge it. An FDE can.

This is why MIT NANDA’s State of AI in Business 2025 report found that 95% of enterprise generative AI pilots show no measurable business impact. The models are not the problem. The deployment is.

Palantir’s Operational Evidence

Before analyzing what OpenAI and Anthropic are doing, it is worth examining Palantir’s results. They provide the most direct proof of concept.

Palantir went public via a direct listing on September 30, 2020, with a reference price of $7.25 per share. The stock opened at $10 and closed its first day at $9.50. It rose to highs near $39 in early 2021, then dropped to around $6 in late 2022. Critics questioned the model throughout this period. The FDE approach looked too expensive and did not scale like a pure SaaS product.

The stronger evidence is operational. Palantir’s Q1 2026 investor release confirmed 85% total year-over-year revenue growth, U.S. government revenue up 84% year-over-year, and U.S. commercial revenue up 133% year-over-year. Palantir raised its full-year 2026 revenue guidance to 71% year-over-year growth. Those numbers reflect what the embedded deployment model produces at scale, in a competitive market, after years of iteration.

The FDE model produced a specific kind of revenue: sticky revenue. When an FDE team spends months inside a client organization building a system that integrates with the client’s internal data pipelines, that client does not switch vendors the following year. The switching cost is not a subscription cancellation. It is rebuilding an entire system woven into how the organization operates. High acquisition cost, very high retention, very high contract value. That is the economic structure the FDE model produces.

The Technical Skills FDEs Must Have

It is useful to be precise about the technical gaps FDEs bridge.

Prompt architecture: Writing a prompt that works in a demo is not the same as one that works reliably across thousands of production inputs. FDEs design prompt architectures like system prompts, few-shot examples, structured output formats, and guardrails that hold up under real-world variation.

Retrieval-Augmented Generation (RAG) pipelines: Most enterprise use cases require the model to reason over internal company data absent from the model’s training data. RAG involves embedding documents into a vector database (such as Pinecone, Weaviate, or pgvector), retrieving relevant chunks at inference time, and injecting them into the prompt context. The pipeline design like chunking strategy, embedding model, similarity metric, and reranking logic significantly affects output quality. FDEs configure this for the client’s specific data.

Evaluation frameworks: Anthropic’s FDE job specification requires “production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale.” Building evaluation suites that catch hallucinations, regressions, bias, and grounding gaps before production is a non-negotiable FDE skill in 2026. OpenAI’s own documentation describes this with John Deere: “after reviewing hundreds of real-world examples with domain experts, building custom evaluation systems to measure accuracy, and iterating.”

Agent development: As enterprises move from single-step inference to multi-step agentic workflows, FDEs need hands-on experience with agent frameworks. These include LangGraph, LangChain, CrewAI, and DSPy. They also need experience with multi-step tool-use chains where models call external APIs, read from databases, or write to internal systems within a single workflow.

Production observability: Models behave differently in production than in development. FDEs implement logging, monitoring, and alerting systems that track model outputs over time, including latency, token usage, error rates, and output drift.

Security, compliance, and data governance: Enterprise clients in financial services, healthcare, and government have strict data handling requirements. FDEs must understand how to deploy models inside client-controlled infrastructure, which often means running models on-premises or in a private cloud rather than calling a public API endpoint.

OpenAI’s Forward Deployed Engineering Team

OpenAI began building its Forward Deployed Engineering team in late 2024 and accelerated hiring through 2025. The OpenAI FDE job description describes the role directly:

Forward Deployed Engineers lead complex deployments of frontier models in production. You will embed with customers where model performance matters, delivery is urgent, and ambiguity is the default.

The role required up to 50% travel. Salaries ranged from $160,000 to $280,000 annually for mid-level positions in San Francisco. The team operates at the intersection of customer delivery and core product development, feeding deployment patterns back into OpenAI’s roadmap.

OpenAI’s FDE work at BBVA is a documented example. BBVA partnered with OpenAI to build an AI-native bank at global scale. What began as a ChatGPT Enterprise deployment expanded into a system now serving 120,000 employees across 25 countries.

The John Deere deployment is a second example. OpenAI FDE teams worked alongside John Deere’s domain experts to deploy AI-powered planting recommendations for farmers. The process involved reviewing hundreds of real-world examples, building custom evaluation systems, and iterating on model performance. The outcome: John Deere helped farmers reduce chemical usage by up to 70%.

There is a competitive context behind the timing. According to Menlo Ventures’ 2025 mid-year LLM market update, Anthropic held approximately 32% enterprise LLM market share, OpenAI approximately 25%, and Google approximately 20%, with OpenAI down from around 50% in 2023. The Deployment Company is, in part, a structural response to that shift.

On May 11, 2026, OpenAI formalized its FDE approach at scale. OpenAI confirmed the formation of “The Deployment Company” — a joint venture majority-owned and controlled by OpenAI. The venture raised over $4 billion from 19 investors, anchored by TPG, with Advent International, Bain Capital, and Brookfield Asset Management as co-lead founding partners. Additional named partners include Goldman Sachs, SoftBank Corp., Warburg Pincus, BBVA, and B Capital. Consulting and systems integration firms — including Bain & Company, Capgemini, and McKinsey & Company — are also founding partners. OpenAI’s official announcement confirmed more than $4 billion in initial investment and majority ownership; separate media reports, including from Axios, described the vehicle as having a reported pre-money valuation of approximately $10 billion, with a higher post-money structure.

OpenAI’s own financial commitment is $500 million in equity at close, with an option to contribute up to $1 billion more — for a total potential commitment of up to $1.5 billion. Reuters and Financial Times reporting indicated that private equity investors in the venture are reportedly guaranteed a 17.5% annual return over five years, with OpenAI retaining super-voting shares to keep strategic control. OpenAI has not confirmed the 17.5% figure in its official announcement. The venture is led by OpenAI COO Brad Lightcap. OpenAI also acquired Tomoro — an applied AI consulting firm bringing approximately 150 engineers with prior deployment experience at companies including Tesco, Virgin Atlantic, and Supercell — to build out the FDE team’s existing client experience.

Anthropic’s Enterprise Joint Venture

On May 4, 2026 — days before OpenAI’s announcement — Anthropic confirmed a parallel initiative.

Anthropic announced the formation of a new AI-native enterprise services firm alongside Blackstone, Hellman & Friedman, and Goldman Sachs as founding partners. Additional backing came from Apollo Global Management, General Atlantic, GIC, Leonard Green, and Sequoia Capital. The venture is valued at $1.5 billion, with a $300 million founding commitment split between Anthropic, Blackstone, and Hellman & Friedman.

Blackstone President and COO Jon Gray stated the venture aims to break down “one of the most significant bottlenecks to enterprise AI adoption” — specifically, the scarcity of engineers who can implement frontier AI systems at speed.

According to Anthropic’s CFO Krishna Rao: “Enterprise demand for Claude is significantly outpacing any single delivery model.” That statement directly explains the FDE pivot. Anthropic cannot serve enterprise demand at scale through API access alone.

Goldman Sachs’s Global Head of Asset Management Marc Nachmann described the goal as “democratizing access to forward-deployed engineers” for mid-market companies.

The new firm is a standalone entity with Anthropic engineering and partnership resources embedded directly within its team. The initial customer base is drawn from the portfolio companies of the investing firms. As TechCrunch reported, Anthropic described the engagement model directly: “An engagement might begin with the company’s engineering team sitting down with clinicians and IT staff to build tools that fit into the workflows that staff already use.” That is a straightforward FDE deployment description.

The new firm’s structure mirrors Palantir’s forward-deployment model and directly competes with traditional consulting firms for enterprise AI implementation work.

Marktechpost’s Visual Explainer

A Forward Deployed Engineer (FDE) is a software engineer who works embedded with a client’s technical and operational environment — on-site, hybrid, or inside the client’s cloud or VPC. The FDE writes production code directly inside the client’s systems.

The role differs from advisory consulting. Consultants deliver reports. FDEs deliver working systems and stay until those systems run reliably in production.

Palantir coined the model in the early 2010s to serve U.S. intelligence agencies whose requirements were too sensitive and too complex to articulate in a product brief. These early FDEs were called “Deltas.” Until 2016, Palantir had more FDEs than software engineers.

Key Takeaways

The FDE model embeds engineers inside client organizations to ship production AI — not slides, not docs, working code.

Enterprise AI pilots fail 95% of the time not because models are weak, but because deployment is broken.

Palantir’s Q1 2026 results (85% revenue growth, 133% U.S. commercial growth) are the clearest proof the embedded model works at scale.

OpenAI ($4B+ raised, The Deployment Company) and Anthropic ($1.5B JV with Blackstone and Goldman Sachs) both launched FDE ventures in May 2026 within days of each other.

For AI engineers, the FDE skill stack — RAG pipelines, eval frameworks, agent development, production observability — is now the most in-demand and least saturated path in enterprise AI.

Also, feel free to follow us on Twitter and don’t forget to join our 150k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.

Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us

Michal Sutter

Michal Sutter is a data science professional with a Master of Science in Data Science from the University of Padova. With a solid foundation in statistical analysis, machine learning, and data engineering, Michal excels at transforming complex datasets into actionable insights.

原文链接

Why OpenAI and Anthropic are hiring forward deployed engineer teams

Thu, 03 Sep 2026 17:40:11 +0000

原文的核心事实是 OpenAI 和 Anthropic 在组建 forward deployed engineer 团队。在一线上看，这事并不新鲜：Palantir 十几年前就把「把工程师压到客户现场」的模式跑通了，实验室下场做交付，本质是模型能力商品化之后，竞争重心从谁的模型强，转向谁先摸到客户的真实工作流。但硬币的另一面值得警惕——厂商派 FDE 进场，不只是帮你交付，也在拿你的业务场景当产品化的养料：今天为你定制的方案，明年可能变成平台的标准功能，而你的竞争对手同样买得到。这是接入厂商 FDE 服务前必须算清的一笔账。

真正容易翻车的环节，往往不在模型本身。从经手的跨境供应链项目看，demo 三天就能惊艳客户，但要把输出接进客户的 ERP/WMS 和审批流、再过一遍数据出境与个人信息合规，常常占掉七成以上工时。另一个被普遍低估的风险是模型版本漂移：厂商例行升级或下线旧版本，你上线三个月的工作流可能悄悄劣化，而客户只会觉得「你们的东西不准了」。FDE 撤场后的运维真空同样致命——定制方案没留下评测集和回归工具链，等于交付了一台没人会修的机器。

给读者一条可执行的建议：项目启动第一周，就把核心业务场景沉淀成三五十条带人工标注的黄金评测集，此后所有上线与模型版本变更都先过这套评测再放行，并在合同里约定版本变更的通知期与回滚窗口。这套纪律成本很低，却是厂商 FDE 与你自己的团队之间唯一靠得住的交接物。

—

编务提示：本次抓取的「原文」正文缺失，粘贴内容几乎全是 The New Stack 页面的投票组件脚本（一个 JS 框架问卷），仅标题与来源元数据可用。以上「编辑说」基于标题所指主题与行业公认事实撰写，未直接引用原文语句；若后续要走全文翻译或转载口径，建议先修复正文抓取。

—— FDEChina编辑部 · 实战派

# Why OpenAI and Anthropic are hiring forward deployed engineer teams

来源：Oluwadamilola Oshungboye · 2026-05-28T16:35:14+00:00

As a JavaScript developer, what non-React tools do you use most often?

✓

Angular
0%

✓

Astro
0%

✓

Svelte
0%

✓

Vue.js
0%

✓

Other
0%

✓

I only use React
0%

✓

I don’t use JavaScript
0%

Thanks for your opinion! Subscribe below to get the final results, published
exclusively in our TNS Update newsletter:

SUBMIT

$(document).ready(function() {
/// Handle TNS Daily subscription
var $poll = $(‘.tns-poll[data-instanceID="6a847ce8e8d00"]’);
var $tnsNewsletterEmailInput = $poll.find(‘.tns-poll-postroll-daily-input’);
var $tnsNewsletterSubmitButton = $poll.find(‘.tns-poll-postroll-daily-button’);

$tnsNewsletterEmailInput.on(‘keyup’, function($event) {
$(this).removeClass(‘error’);

if ($event.which === 13) {
$tnsNewsletterSubmitButton.click();
}
});

$tnsNewsletterSubmitButton.on(‘click’, function() {
var email = $tnsNewsletterEmailInput.val();

window.tns.subscribe.prepop = true;
window.tns.subscribe.context = ‘tns_voxpop_postroll’;

$(‘#tns-subscribe’).find(‘.subscribe-email’).val(email);
$(‘#tns-subscribe’).find(‘.subscribe-button’).click();

window.tns.subscribe.open();
});
});

$(document).ready(function() {
var $poll = $(‘.tns-poll[data-instanceID="6a847ce8e8d00"]’);
var $option = $poll.find(‘.option’);
var sponsor_slug = ”;
var voxpop = ‘true’; /// string ‘true’ || ‘false’
var categories = $poll.data(‘categories’);

var voted = localStorage.getItem(‘tns_poll_vote_22754645’);
if (voted) voted = JSON.parse(voted);

///
/// Handle vote
///

$option.on(‘click’, function($event) {
var $thisOption = $(this);
var poll_ID = ‘22754645’;
var instance_ID = ‘6a847ce8e8d00’;
var question_ID = null;
var answer_ID = null;
var captchaToken = null;
var pollData = null;

if ($poll.hasClass(‘done’)) return;

async.series([
setStatusClasses,
obtainCaptchaToken,
revealPercentages,
submitVote,
displayResults,
handlePostroll
], function(result) {
if (result) console.log(result);
});

function setStatusClasses(next) {
$poll.addClass(‘done’);

$option.removeClass(‘active’);
$thisOption.addClass(‘active’);
$thisOption.addClass(‘selected’);

question_ID = $thisOption.data(‘questionid’);
answer_ID = $thisOption.data(‘answerid’);

return next();
}

function obtainCaptchaToken(next) {
captchaToken = window.tns.turnstile.token;

return next();
}

function revealPercentages(next) {
var delay = 21;
var i = 0;

$poll.find(‘.option-percentage’).each(function() {
$(this).transition({
delay : delay * i,
duration : 99,
opacity : 1,
easing : ‘easeOutQuad’
});

i++;
});

return next();
}

function submitVote(next) {
var payload = {
poll_ID : ‘22754645’,
instance_ID : instance_ID,
question_ID : question_ID,
answer_ID : answer_ID,
recaptcha_token : captchaToken,
sponsor : sponsor_slug
}

console.log(‘[tns-poll] Sending poll vote …’)

$.ajax({
url : ‘/no-cache/polls-vote/’,
type : ‘post’,
data : payload,
statusCode : {
429 : function() {
$poll.removeClass(‘done’);
$option.removeClass(‘active’);
$poll.find(‘.option-percentage’).css({
opacity : 0
});

var poll_type = ‘inline’;
if (voxpop === ‘true’) poll_type = ‘voxpop’;

var event_payload = {
event : ‘poll’,
poll_action : ‘rate-limited’,
poll_type : poll_type,
poll_id : ‘22754645’,
question_ID : question_ID,
answer_ID : answer_ID
}

if (sponsor_slug) {
event_payload.sponsor = sponsor_slug;
}

if (categories) {
event_payload.categories = categories;
}

window.dataLayer.push(event_payload)

var msg = ‘429 — Whoa, facile tigré.’;
msg += ‘You’re being rate-limited.’;
msg += ‘If you’re human, take it easy and try again in an hour.’;
console.log(msg);
}
}
}).done(function(data, statusText, xhr) {
if (data) data = JSON.parse(data);
pollData = data;

console.log(‘[tns-poll] Result from vote endpoint:’);
console.log(data);

/// Pre-construct the event_payload
var poll_type = ‘inline’;
if (voxpop === ‘true’) poll_type = ‘voxpop’;

var event_payload = {
event : ‘poll’,
poll_action : null,
poll_type : poll_type,
poll_id : ‘22754645’,
question_ID : question_ID,
answer_ID : answer_ID
}

if (sponsor_slug) {
event_payload.sponsor = sponsor_slug;
}

if (categories) {
event_payload.categories = categories;
}

if (data.bot === true) {
event_payload.poll_action = ‘recaptcha-fail’;

console.log(‘[tns-poll] Suspected bot vote due to recaptcha fail.’);

window.dataLayer.push(event_payload);

event_payload.instance_ID = instance_ID;
console.log(event_payload);

return next();
}

if (!voted && data.unique_vote === true) {
event_payload.poll_action = ‘vote’;

console.log(‘[tns-poll] Unique vote detected, firing GA4 event.’);

window.dataLayer.push(event_payload);

event_payload.instance_ID = instance_ID;
console.log(event_payload);

delete payload.recaptcha_token;
localStorage.setItem(‘tns_poll_vote_22754645’, JSON.stringify(payload));
console.log(‘[tns-poll] Set localStorage item.’);
} else {
event_payload.poll_action = ‘duplicate-vote-attempt’;

console.log(‘[tns-poll] Detected duplicate vote, did not fire GA4 event.’);

event_payload.instance_ID = instance_ID;
console.log(event_payload);

delete payload.recaptcha_token;
localStorage.setItem(‘tns_poll_vote_22754645’, JSON.stringify(payload));
}

return next();
});
}

function displayResults(next) {
var highestPercentage = 0;
var totalVotes = parseInt(pollData.totalVotes);
var totalPercentage = 0;

$option.each(function() {
var optionAnswerID = $(this).data(‘answerid’);
var percentage = 0;

pollData.results.map(result => {
if (result.answer_ID === optionAnswerID) {
percentage = parseInt(result.percentage);
totalPercentage += percentage;

if (percentage > highestPercentage) {
highestPercentage = percentage;

$option.removeClass(‘active’);
$(this).addClass(‘active’);
}
}
});

var $resultsBar = $(this).find(‘.option-results’);
var $percentDisplay = $(this).find(‘.option-percentage’);
var digit = 0;

var uptickPercentDisplay = setInterval(function() {
if (digit >= percentage) {
clearInterval(uptickPercentDisplay);
return;
}

digit++;

$percentDisplay.html(digit + ‘%’);
}, 3);

if (percentage === 0) {
$percentDisplay.html(‘0%’);
}

$resultsBar.transition({
width : percentage + ‘%’,
duration : 777,
easing : ‘easeOutQuad’
})
});

return next();
}

function handlePostroll(next) {
if (voxpop !== ‘true’) {
console.log(‘[tns-poll] Inline poll detected, skipping post-roll …’);

return next();
}

console.log(‘[tns-poll] Voxpop poll detected, firing post-roll …’);

var targetHeight = $poll.find(‘.post-roll-block’).outerHeight(true);

$poll.find(‘.post-roll’).transition({
delay : 555,
height : targetHeight,
duration : 777,
easing : ‘easeOutQuad’
});

setTimeout(function() {
$poll.find(‘.post-roll’).addClass(‘open’);

if (window.tns.voxpop && window.tns.voxpop.vote) {
window.tns.voxpop.vote(pollData, 777);
}
}, 777);
}
});

///
/// Handle firing the impression event, but only when
/// the poll enters the viewport.
///

function isInViewport($element) {
var elementTop = $element.offset().top;
var elementBottom = elementTop + $element.outerHeight();
var viewportTop = $(window).scrollTop();
var viewportBottom = viewportTop + $(window).height();
return elementBottom > viewportTop && elementTop < viewportBottom;
};

if (!voted && voxpop !== ‘true’) {
var impression_recorded = false;

$(window).scroll(function() {
if (!impression_recorded && isInViewport($poll)) {
var poll_type = ‘inline’;
if (voxpop === ‘true’) poll_type = ‘voxpop’;

var event_payload = {
event : ‘poll’,
poll_action : ‘impression’,
poll_type : poll_type,
poll_id : ‘22754645’
}

if (sponsor_slug) {
event_payload.sponsor = sponsor_slug;
}

if (categories) {
event_payload.categories = categories;
}

console.log(‘[Polls] Poll impression detected, firing GA4 event.’);

window.dataLayer.push(event_payload)

event_payload.instance_ID = ‘6a847ce8e8d00’;
console.log(event_payload);

impression_recorded = true;
}
});
}

///
/// Handle rendering the poll if this user has
/// already voted in it. Display the results.
///

if (voted) {
var renderResults = setInterval(function() {
$option.each(function() {
var answer_ID = $(this).data(‘answerid’);
if (answer_ID === voted.answer_ID) {
$(this).click();
}
});

clearInterval(renderResults);

return false;
}, 333);
}

///
/// Poll Sponsor Click Tracking
///

$sponsorBlock = $poll.find(‘.poll-sponsor’);

$sponsorBlock.on(‘click’, function() {
var sponsorSlug = $(this).data(‘sponsor-slug’);
var url = $(this).attr(‘href’);
var poll_type = ‘inline’;
if (voxpop === ‘true’) poll_type = ‘voxpop’;

var event_payload = {
event : ‘sponsor_poll_click’,
sponsor : sponsor_slug,
url : url,
poll_type : poll_type,
poll_id : ‘22754645’
}

if (categories) {
event_payload.categories = categories;
}

window.dataLayer.push(event_payload);
});
});

FDE vs AI Engineer：客户现场与产品团队的两条路

Thu, 03 Sep 2026 17:35:16 +0000

两条都写 AI 代码的路，岔口在「需求从哪来」。

对比表里最有分量的一行是成功定义：FDE 对客户业务指标负责，AI Engineer 对产品指标负责。指标一变，技术选择全变——同样做 RAG，现场版要先解决数据出不了内网的问题，产品版要先解决规模化之后的延迟与成本。这不是技能高低之差，是工作对象之差。

国内 AI Engineer 岗位供给多、成长路径成熟，FDE 岗位相对少但对行业积累的回报更高；已有三五年工程经验的人转 FDE，行业知识会从「背景」变成「核心竞争力」，这是现场岗位独有的复利。

按处境选：要成长确定性选产品团队，要责任半径与行业纵深下现场。面试前把本文对比表「工作现场、需求来源、成功定义」三行的差异讲给面试官听，也能反过来验证对方岗位的真实定位。

—— FDEChina编辑部 · 实战派

导语

FDE 与 AI Engineer（AI 工程师）都在写 AI 相关的代码，用的是高度重叠的技术栈，做的却是两种工作：一个把模型能力落进客户业务，一个把模型能力做进产品。本文用一张对比表拆开两条路的差异，给正站在岔路口的人一份对照。FDE 与其他岗位的区别概览见新手指南第四节。

对比维度表

公开可见的招聘信息显示，两类岗位大致呈现以下差异。各家公司的实际边界有出入，具体以职位描述为准：

维度	FDE	AI Engineer
工作现场	客户环境或驻场，面对真实组织的约束	公司产品团队，面对迭代节奏与代码库
需求来源	客户业务方访谈与现场观察	产品规划、用户反馈、数据指标
成功定义	客户业务指标改善、系统被真实使用	产品指标改善：留存、性能、功能采用
技术栈侧重	系统集成、数据管道、RAG/Agent 落地与评测	模型训练与微调、推理优化、AI 功能工程化
协作界面	客户业务方、项目经理、自家产品团队	产品经理、算法研究员、基础平台团队
转型方向	交付负责人、行业方案负责人、客户成功管理	资深工程师、AI 架构师、应用科学家
典型背景	后端/全栈工程师转岗，或交付一线成长	算法工程化、平台工程、应用开发背景

三个关键差异展开

差异一：需求从哪里来，决定工作什么样

AI Engineer 的需求相对结构化：需求文档、指标、迭代排期，改需求有评审、排期有缓冲。FDE 的需求长在客户业务里，要靠访谈与观察挖出来——「这个审批环节为什么慢」往往比「给我们做个大模型应用」更接近真问题。喜欢确定性的人会在现场感到煎熬，喜欢具体问题的人反而觉得产品需求隔了一层。

差异二：成功定义不同，技术选择就不同

FDE 的技术选择围着客户约束转：数据出不出得了内网、旧系统怎么接、评测怎么对齐验收标准。AI Engineer 的选择围着产品转：延迟、成本、效果在规模化场景下的平衡。同为 RAG，两边关心的指标与常踩的坑并不一样，经验也不能直接照搬。

差异三：经验复利的方向不同

FDE 攒的是行业与场景知识：这类客户的流程、那类数据的脾气，复利落在「懂业务」上；AI Engineer 攒的是工程与模型纵深，复利落在「技术高度」上。三五年之后，两条路分别通向行业方案负责人与 AI 架构师这类不同的终点，切换成本随年限上升。判断哪条路适合自己，可以看你更愿意在哪种会议上花时间：客户的业务流程梳理会，还是自家产品的技术评审会。

怎么选：按处境给建议

按处境给建议：刚毕业或工程纵深尚浅，AI Engineer 的成长路径更标准，先打底再下现场不迟；已有几年后端或全栈经验、想放大业务价值，FDE 的责任半径与稀缺性都更大；对某个行业（如制造、医疗、金融）本来就有积累，FDE 能让行业知识直接变成竞争力。两条路并非单行道：现场经验回流产品团队，是不少公司刻意设计的通道。

小结与相关阅读

一句话收束：AI Engineer 把模型做进产品，FDE 把模型做进客户的业务流程。两条路都长期存在，差别在于你愿意让哪类问题占据自己的日常。继续对照：《FDE vs Solutions Engineer》比较签约前后分工的另一组岗位；《FDE 项目生命周期》看 FDE 的项目实际怎么跑；更多行业观察见FDE 观察频道。

参考来源

对比依据来自公开可见的招聘信息与公司公开资料中对两类岗位的职责描述（openai.com、anthropic.com、palantir.com 及国内招聘平台公开页面）；
具体公司的岗位边界以各家职位描述为准，本篇不构成对任何公司岗位设置的断言。