FDE: Is the Call for Career Transformation in the AI Era Already Sounding?
From Super-Individual to Super-Role.
From Super-Individual to Super-Role.
👦🏻 Author: Henry (DeerFlow Team) [1]
🥷 Editor: Koji
🧑🎨 Layout: NCon
Over the past month, I met four friends preparing to pivot — a frontend engineer, a solutions architect, a product manager, and a traditional algorithm engineer. Different backgrounds, ages, cities. Yet they all asked about the same acronym: FDE. Is it worth pursuing?
FDE, short for Forward Deployed Engineer. Two years ago, it was still insider jargon in Palantir circles. Today it has quietly become a recruiter's opening line, a high-frequency job title in postings, and one of the candidate answers for "the most valuable role in the AI era" on social media. In May 2026, OpenAI directly incorporated a company under this name — Deployment Company — with an initial investment of $4 billion, explicitly stating it would send engineers into clients' offices and embed them in client workflows. Anthropic's Applied AI team is also hiring FDEs across four time zones. The journey from insider jargon to mainstream vocabulary took just over a year.
My previous article, To the Super-Individual, discussed the "human engine" — how curiosity, self-learning, self-drive, and hands-on ability get activated within a complete closed loop. But people don't float in midair. People need to be caught by a concrete role coordinate system. If the super-individual is the "raw material" of AI-era production relations, then FDE is the most visible "role form" that the market has grown in the past year.
In my view, FDE doesn't sit in the consulting box, nor in the outsourcing box. It sits closest to the super-individual — the only difference being that FDE is an institutionalized super-individual operating in the crevice between "model company × client."
Do you know where the term "Forward Deployed" comes from? It was originally U.S. military terminology — Forward Deployed Forces — referring to troops stationed overseas or at the front lines who could respond on-site, as opposed to rear forces kept at domestic bases. In the late 2000s, Palantir imported this term into the software industry to describe a work model where engineers were sent away from headquarters to live at client sites, with internal teams even named after military phonetic alphabet designations: Delta and Echo. That OpenAI and Anthropic are now reclaiming it is no coincidence — the fundamental nature of sending engineers to the front lines has never changed.
This article addresses three specific questions I've been asked by those four friends:
- Is FDE just a consulting firm in AI clothing? Where does it draw the boundary with traditional consulting?
- Is FDE just premium software outsourcing? How is it different from the vendor work I'm doing now?
- Am I suited for FDE? Which types of people does this role amplify, and which does it grind down?
My stance is cautiously optimistic: FDE is genuinely emerging, but it is far from a career exit for everyone. Explaining it clearly matters more than hyping it up.
Starting with OpenAI's Deployment Team
If I had to pick one event to mark FDE's return to prominence this cycle, I'd choose May 11, 2026 — the day OpenAI announced the formation of Deployment Company. COO Brad Lightcap left his original commercial line to lead special projects, reporting directly to Sam Altman, working on this full-time. That same week, OpenAI acquired UK-based AI consultancy Tomoro, bringing 150 Forward Deployed Engineers and Deployment Specialists into the new company in one move.
Worth noting: OpenAI's careers page simultaneously listed over a dozen FDE roles across San Francisco, New York, and Washington, plus vertical industry tracks like Life Sciences, Semiconductor, and Gov. They were even hiring FDE recruiters. Analysts estimate this team will expand to 2,000–4,000 people within three years. This isn't the size of a research group. This is a standing army.
Anthropic's moves are almost a mirror image. The Forward Deployed Engineer roles under its Applied AI team are simultaneously open in Boston, New York, Seattle, San Francisco, Washington, and London, requiring 25%–50% client-site travel. One frequently cited example is fintech company FIS — its announcement explicitly states that "Anthropic's Applied AI team and forward-deployed engineers have embedded at FIS to co-design the Financial Crimes AI Agent, and transfer knowledge to FIS so it can independently scale more agents later."
Hidden in this description is the real nature of FDE work. It's not a pre-sales architect, not an SDR, not an evangelist who comes to train clients. It's an engineer who brings the model and moves into the client's codebase. Brad Lightcap put it more bluntly: "Our customers tell us they need the ability to go from pilot to production. Deployment Company puts our engineers inside their teams, with full resources to deliver."
Mapping this out makes the three-party relationship very clear:
Note the two most informative arrows in this diagram: the feedback FDE sends in both directions. Toward the client, FDE doesn't sell the model as SaaS — instead, they twist the client's data, permissions, compliance, and internal systems into a pipeline that can actually run the model. Toward the model company, FDE brings back real pain points and failure samples to product and research, influencing the roadmap — a repeatedly failing tool-calling pattern might become the next built-in abstraction in the SDK.
This is why FDE is being simultaneously revived by both leading model companies — it's not simply "we want to copy Palantir and do consulting." It's a signal acquisition device for model companies. The densest frontline customer pain points must be captured by their own people on the ground; requirements filtered through partners always lose something in translation. Anthropic is taking a hybrid path: building FDE capabilities in-house while also creating joint venture deployment networks with consultancies and PE giants. One leans self-operated, the leans ecosystem, but the kernel is identical: model companies are no longer just API suppliers — they're directly embedding engineers into client products.
Next, I need to address the two most common comparison questions — where does FDE draw the boundary with traditional consulting (the McKinsey & Company, Accenture type)? And is it the same thing as the software outsourcing we're all familiar with?
FDE Is Not McKinsey: Model Boundary vs. Process Boundary
Many people's first reaction upon hearing FDE's job description is: "Isn't this just McKinsey or Accenture with a new coat of paint?"
I understand the association. Suits, client-site travel, whiteboarding in client conference rooms, aligning with C-suite executives — on the surface, FDEs and management consultants look similar. But go one layer deeper, and the work texture is completely different. Consulting sells process boundaries; FDE sells model boundaries.
Putting these side by side in a table makes the differences immediately apparent.
The row in this table most worth pausing on is "asset depreciation."
The most profitable logic of traditional consulting is asset reuse — a proposal built for one bank gets slightly modified and sold to the next; a retail industry digital transformation playbook can be applied to thirty clients in succession. This has been the underlying economic model that allowed Accenture, Deloitte, and McKinsey Digital to scale over the past three decades.
FDE has no such assets. Model capabilities are still moving fast — the carefully designed prompt chains needed today might be replaced by a single sentence in the next model version. The "methodological沉淀" of consulting depreciates rapidly at this speed. So FDE cannot use the asset reuse model; it must run the full loop from scratch every time — reassessing model boundaries, reselecting the tool stack, reassembling the product form. It looks inefficient, but it's the only way to keep pace with model velocity.
Do you know — what is Product Overhang? I explained this term in my previous article "To the Super-Individual"[4]: model capabilities have already surpassed existing product forms, but there's no product entry point, permissions, or context to cash them out. The essential value of the FDE role is converting that suspended Overhang in a customer's scenario into a concrete, running product. What the customer buys isn't model API call quota — it's the capability of "someone who can actually land this pile of Overhang in my business."
This also explains the difference in "project structure." The standard consulting project structure is SOW (Statement of Work) + WBS (Work Breakdown Structure) + phase gate acceptance: the contract specifies what will be delivered, when, and against what acceptance criteria. This structure presumes that the goal is already clearly defined before the contract is signed.
FDE projects can't follow this playbook. The most common thing customers say is: "I know AI should be able to help me with something, but I don't know what." The goal itself is part of the project. So FDE doesn't take SOWs; it takes missions — a relatively fuzzy direction. Then through iteration round by round, the direction becomes clear; finally in some round, the accumulated model understanding gets cashed out into a product form.
The "deliverable" row is also worth unpacking. After the FDE leaves, what remains in the customer's system is a running function — maybe small, maybe ugly, maybe with barely any user interface, but it's actually being called every day, being modified, being cursed at. Consulting deliverables are PowerPoints and change management reports; even if code was written or ERP configured during the project, what ends up in the customer's executive hands is still a methodology document.
The "moat" row is the most subtle. FDE's moat is real-time手感 for model capability boundaries — how many real customer scenarios you ran this month determines whether you know better than others what Claude 4.7 can do and what must wait for Claude 5. This手感 can't be written into PowerPoint or stored in a knowledge base; it can only live in the brains of engineers who have had their hands dirty in the last 90 days.
So next time someone says "FDE is just the new Accenture," here's the response: Accenture's engineers go to redesign the customer's processes; FDE goes to reprobe the model's boundaries. The former's assets can沉淀 for ten years; the latter's assets have to regrow every 90 days.
FDE Is Not Software Outsourcing: Co-Exploration vs. Requirements Fulfillment
If "FDE is the new Accenture" is the first layer of misreading, then "FDE is expensive software outsourcing" is the second. This one is more misleading because the surface evidence looks very convincing: FDEs really do go to customer sites to write code, really do customize features to customer business needs, really do get billed by customer working hours. At first glance, no different from outsourced engineers.
But just look at feedback loops, and the difference becomes impossible to miss.
The most critical difference in this diagram isn't how simple the top half is — it's that the bottom half has an extra feedback chain extending to the model company. This chain isn't decorative; it's the real reason the FDE role exists. Unpacking this layer of difference reveals at least four contrasts.
What they take on is different. Outsourcing takes SOW — a requirements list already clearly defined before contract signing: what features to build, what tech stack to use, what acceptance criteria, what penalties for breach. FDE takes mission — the customer themselves haven't figured out what they want, only knowing "AI should be able to help me with something." SOW presumes certainty; mission presumes exploration. Completely different project starting postures.
The scope of work is different. Outsourcing does local delivery — a module, a website, a data pipeline, package and leave when done, on to the next one. FDE does end-to-end — from business pain point, to model selection, to product form design, to post-launch retention and churn of real users.
The billing model is different. This is the most counterintuitive point. When a model company sends an FDE into a customer site, what they ultimately care about isn't just how much consulting fee this project generates, but rather: how many tokens will this customer consume going forward? Will they become a retention customer? Will they expand to more business lines? FDE's real KPI is the long-term token consumption curve, not the number on the project acceptance form.
Where feedback goes is different. This is the deepest of the four contrasts. In outsourcing projects, client feedback travels at most to the outsourcing company and doesn't affect products sold to others in the future. FDE feedback flows back to the model company's roadmap — every pitfall encountered in real scenarios, every prompt failure, every tool invocation bug becomes input for the next version of training data, next version of tool design, next version of product features. In other words, every customer where an FDE deploys is simultaneously a natural design partner for the model company.
This is the real reason model companies are willing to pay high salaries for FDEs. They're not just selling a service; they're collecting real-world product form signals on customer premises. These signals can't be bought, scraped, or surveyed — they can only be brought back by a specific engineer, in a specific customer workflow, after personally hitting the wall a few times.
Do you know — what's the total comp for OpenAI and Anthropic FDEs? According to publicly available data on Levels.fyi for Anthropic software engineers[8], senior SDE total comp median has already reached $710K. The FDE role carries higher risk — facing uncertainty in model capabilities, customer business, and product form — so industry compilations[9] note that mid-to-senior FDE total comp at frontier AI labs generally falls in the $350K-$550K range, with Staff level and above hitting $630K+. This price isn't paying for "outsourced labor hours"; it's paying for someone who bears the composite risk of "product + customer + model."
Looking back to 2006, when I had just started working at a central SOE undergoing informatization transformation, the Accenture consultants our group invited to be stationed on-site cost the group 3,500 RMB per day in consulting fees, staying for years — what media at the time called "gold-collar." I later jumped to German company SAP, which practically defined a name for the consulting industry; SAP consultants were the very symbol of "gold-collar." Viewed this way, FDE salaries will continue rising for at least the next 24-36 months, with stable upward demand.
Outsourcing is labor arbitrage; FDE is a frontline sensor. Confusing these two things makes clients mistakenly think they can bring in FDEs via SOW, and makes candidates approach FDE with an outsourcing work posture. Both sides will hit the wall fast.
Two Roots of Overseas FDE: Palantir and the New Generation of Model Companies
Many people mistakenly think FDE was coined by OpenAI. It wasn't. It has two historical roots, one from Palantir and one from the new generation of model companies post-2023. Looking at these two roots side by side clarifies what the FDE role is really doing.
First, a timeline.
The first root is Palantir.
Palantir was founded in 2003 by Peter Thiel, Alex Karp, Joe Lonsdale and others; its earliest customers were United States intelligence agencies. Karp himself had no CS background — he did his PhD in Frankfurt under philosopher Jürgen Habermas, and was only pulled in by Thiel to be CEO after returning to the US. The FDE role was precisely forced out by this combination of "atypical CEO + highly classified clients": 36Kr's retrospective[10] puts it bluntly — Palantir got ripped apart by intelligence agencies early on because engineers couldn't access real business scenarios, and requirements got distorted after layers of translation. Later Palantir negotiated one thing — letting their own engineers directly enter customer premises and work alongside intelligence analysts. This model was later systematized by Shyam Sankar and became the prototype of FDE.
By 2009, FDE expanded to commercial domains. When JPMorgan deployed Palantir's Metropolis platform, 120 FDEs were stationed for internal threat monitoring. From this point on, FDE was no longer just "sending engineers on business trips" but a systematic customer embed playbook: actually running Foundry/Gotham into customer business flows, not dropping a license and leaving.
Palantir's FDE hiring has one counterintuitive standard — no CS degree required. This can go in the "do you know" section.
Did You Know — Palantir FDEs Don't Require CS Degrees?
According to hiring criteria compiled by SkillScouter[11] and Palantir's official careers page[12], Palantir explicitly welcomes candidates from non-CS backgrounds. Recent FDE hires have come from mechanical engineering, economics, philosophy, and other fields. What Palantir actually screens for are two things: the ability to act with incomplete information, and the ability to speak directly with C-suite clients. A CS degree is a plus, not a prerequisite. Karp himself was the earliest proof-of-concept for this standard — a philosophy-major CEO who built a corps of FDEs trained in physics, math, and philosophy.
The second root is the new generation of model companies post-2023.
After ChatGPT's release in late 2022, OpenAI quickly realized something: hanging model APIs in documentation and letting customers figure out integration themselves simply didn't work. Customers weren't unwilling — they were unable. They had business problems but no product form factor. So OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon, and others began hiring FDEs at scale.
This wave of FDEs studied Palantir's playbook — embedding engineers at customer sites to run end-to-end workflows. But the product vehicle was now completely different: Palantir-era FDEs worked on data integration and UI customization; the new generation works on prompt design, agent orchestration, tool calling, and workflow embedding.
In Pragmatic Engineer's dedicated piece on FDEs[13], this new version is described as "embedded with enterprises to make Claude solve real, specific, high-value problems" — nearly identical in framing to Palantir's original pitch, just swapping "data" for "model."
Putting these two roots together reveals a clear set of commonalities and differences.
Common ground: Customers aren't buying software. They're buying "an engineer who can solve my problem, plus the tools to do it." This is actually anomalous in three decades of enterprise software history. SAP, Oracle, Salesforce sold software itself — engineers existed as supporting resources to "help customers use the software." Palantir inverted this: tools were leverage to "help FDEs solve problems on-site." The new generation of model companies inherited this inverted relationship — OpenAI doesn't sell GPT-4 licenses; it sells "our FDEs can use GPT-4 to automate your customer service end-to-end."
Difference: Palantir's era skewed toward ops integration — the heavy lifting was data integration, ontology modeling, and governance. The new generation skews toward model capability deployment — the heavy lifting is prompt design, agent orchestration, and retention optimization. The former was like an advanced systems integrator; the latter is like an extended product engineer.
One more interesting fact: Many early Palantir FDEs later became founders or joined the new generation of model companies directly. Anthropic, OpenAI, Sierra, Hebbia — their early teams are littered with ex-Palantir names. This isn't coincidence. The FDE role itself forces one person to simultaneously bear product risk, customer risk, and engineering risk — it's essentially entrepreneur training. I'd rather think of Palantir as a stealth startup bootcamp: it didn't just produce engineers, but a cohort of people who know how to push something from zero to one with incomplete information. The two roots converged after 2023.
Domestic FDEs: From Solution Architects to AI Deployment Engineers
This convergence happened primarily abroad. In China, the term "FDE" hasn't been around long, but the work it describes didn't emerge from nowhere. To understand domestic FDEs, you need to first see its two local predecessors, then three ways it diverges from the US version.
Two Local Predecessors
The first predecessor is cloud vendors' solution architects. Alibaba Cloud, Tencent Cloud, and Huawei Cloud have spent the past decade building out full Solution Architect (SA) teams who pitch architectures to customers, write POCs, draft migration plans, and coordinate delivery through go-live. Huawei even has dedicated "delivery engineer" tracks responsible for landing projects in customer data centers. This system already covers roughly 80% of what FDEs do, but the center of gravity remains pre-sales and deployment — end-to-end product iteration responsibility doesn't sit with SAs. Requirement changes go through change management processes; model swaps wait for headquarters scheduling.
The second predecessor is the new track growing inside AI startups. MiniMax posts "AI Pre-Sales Solution Specialist" roles on BOSS Zhipin; Moonshot AI, Zhipu AI, Tongyi, Hunyuan, and other model companies list similar positions. The titles vary slightly, but the JDs are highly convergent: understand customer scenarios, build demos, tune prompts, run RAG, write delivery proposals, and coordinate with customer engineering teams through go-live. This wave of roles represents the true "domestic FDE."
Three Local Adaptations
Private deployment + data compliance kills the pure API-calling model. Domestic B2B customers demand far stricter data-sovereignty, model-weight controllability, and audit-trail requirements than the US market. In a typical FDE project, pure API tuning and prompt work might account for 30% of effort; the remaining 70% goes to moving models into customer data centers, running privilege reviews, integrating with data middle platforms, and filing compliance documentation.
Model capabilities still chasing SOTA compresses room for maneuver to the engineering layer. OpenAI and Anthropic in the US can win customers on raw model capability alone. Domestic Tongyi, Doubao, Kimi, GLM, and DeepSeek don't differentiate that sharply on capability — customers judge more on agent orchestration, RAG retrieval quality, tool integration, and workflow design. Domestic FDEs don't compete on "how strong our model is" but "can I actually make this business workflow run."
B2B payment willingness and pricing rhythm diverge from the US. Palantir's model of "embed FDEs first, then charge high subscription fees" doesn't copy cleanly. Domestic customer budgets follow annual procurement cycles; payment skews toward project-based structures. The domestic FDE business model is typically a hybrid of subscription + private-deployment licensing + project delivery.
A Unique Positioning: Internal FDEs
Many big-tech internal AI teams have begun using the FDE model to serve "internal customers." Alibaba Cloud's PAI embeds engineers into Taobao; Tencent's Hunyuan has similar mechanisms connecting to WeChat and advertising business units. JD postings use titles like "Industry Deployment Engineer," "AI Application Engineer," or "Intelligent Business Specialist" — essentially internal FDEs who run model team capabilities end-to-end into business units. This gives big-tech leaders a new playbook: station a few internal FDEs in business units, get the first demo running, and deliver ROI data to the business head — department silos dissolve faster than they would through ten alignment meetings.
Who Fits FDE, Who Doesn't
In my previous piece To the Super-Individual[4], I outlined five engines of the super-individual: strong curiosity, strong exploration and innovation drive, strong self-learning ability, strong self-motivation, and strong hands-on execution. These five are table stakes for FDE, but not sufficient. Beyond these engines, FDE demands a very specific additional trait profile, and several personality types are explicitly ill-suited. I've seen too many excellent engineers struggle after switching to FDE — the problem usually isn't capability, but personality and work preferences.
Five Traits That Fit FDE
No aversion to sales and communication. An FDE's daily work isn't heads-down coding — it's interfacing directly with customer CTOs, business heads, procurement, compliance, and IT. A typical rhythm: the customer CTO interrupts your mid-demo, and your response can't be "I'll revise and come back next week" — it's opening your IDE on the spot, rewriting the prompt, and rerunning it for them live. "Customer present, me modifying" is the FDE normal.
Enjoys the fuzzy zone. FDEs don't receive clear PRDs — they get "we want to do something with AI." The customer can't articulate what they want; the FDE must help that fuzzy expectation grow into concrete form. If you can only function with clear requirements, FDE will give you daily anxiety.
Solid engineering without needing to be 10x. FDE doesn't require the cleanest code or deepest algorithms in the company. What it needs is end-to-end executability: frontend that can cobble together a clickable page, backend that can stand up a running service, model that can connect to business data sources. In FDE world, "good enough" isn't a flaw — it's a virtue.
Likes being shaped by feedback. FDE work involves massive amounts of "sent back by customer to redo": today's demo gets "this isn't what I wanted" from the business side tomorrow; last week's aligned plan gets redone this week because the customer changed executives. People who fit FDE treat this feedback as fuel — they bear end-to-end responsibility without deflecting to "the requirement wasn't clear."
Sensitive to model boundaries. This is the most technical and most implicit trait. FDEs must judge what tasks suit LLMs, what doesn't, how to fallback — sensitivity you can't get from reading papers, only from getting burned by failure cases. Accumulated failure samples build muscle memory: what scenarios need RAG, what scenarios need rules, what scenarios must provide human fallback entrypoints.
Four Types Who Don't Fit FDE
Pure technologists who want to hide in code. FDEs spend roughly 50% of time not coding — in customer meetings, internal coordination, product discussions, contract negotiation. If your joy comes from four uninterrupted hours of coding, FDE will leave you in chronic mental exhaustion.
People who need OKRs to function. FDE targets live with the customer, not in your performance review. Work pace is determined by customer project milestones, model capability shifts, and your own scene judgment. People accustomed to "first I get OKRs, then I know what to do" will find no anchor.
People who value "promotion" more than "shipping." FDE doesn't play well with big-company promotion systems — customer satisfaction, deal closure, and reuse rate don't carry the same weight as lines of code or deployment frequency in level-review conversations. If advancement ranks first in your work motivation, FDE is a poor fit.
People who resist commercial context. FDE requires understanding a customer's P&L, ROI, procurement process, and compliance requirements. If you instinctively recoil from talking money, contracts, or business logic, FDE will make you feel like you're selling out your technical ideals.
Self-Check Checklist
Seven questions, each mapping to a real FDE work scenario. Five or more "yes" answers means FDE is worth serious consideration; three or fewer means proceed with caution.
-
Are you willing to shift 50% of your daily time from code to customer meetings, messages, and calls?
-
When a customer tells you "this doesn't work, and I can't explain why," is your first reaction curiosity or impatience?
-
With no one writing you a PRD, can you and Claude Code ship a customer-ready prototype within a week?
-
After a customer asks for eight revisions on the same deliverable, can you still exercise judgment rather than execute mechanically?
-
When a model gives a wrong answer, is your first instinct to design a fallback, or to complain the model isn't good enough?
-
Are you willing to sign contracts, write reports, run customer acceptance, and negotiate compliance terms with legal?
-
Can you embrace rapid prototyping and rapid failure?
Five traits, four anti-profiles, seven self-test questions — they all converge on one question: Are you willing to have your product sense, engineering ability, and commercial judgment sharpened simultaneously in the same workflow?
Closing: From Super-Individual to Super-Role
The author's previous article addressed the "human engine": how curiosity, exploratory spirit, self-learning ability, self-drive, and hands-on capability can be fully activated and closed-looped inside a big company. This article addresses something else — role morphology. FDE is the first named, salaried, JD-posted, customer-paid new role to emerge from the AI industrial revolution. It is not synonymous with the "super-individual" concept, but rather the first coordinate to move from abstraction to concrete reality in this wave of restructuring.
FDE is not the endpoint. The author's judgment is that FDE is merely the first form to sprout a name in the new division of labor. What follows will be Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher — every function tightly coupled to customer scenarios and required to grow products out of ambiguity will develop its own "forward deployed" variant. The titles will change, but the underlying logic remains the same: model capability runs ahead, product form chases behind, and role structure re-splits along with the workflow.
One closing thought for each of three reader types.
For technologists: FDE doesn't require you to be the strongest coder in your company, but it does require willingness to shift half your time from code to the customer side. If your answer is "yes," the market window just opened — hiring is accelerating at domestic leading model companies, cloud vendors, and big-company internal AI teams. If your answer is "no," that's fine too; other positions will grow in the new division of labor.
For HR and OD: Beware the "name-reality split." Your company may already have FDEs running, just with job codes labeled "solution specialist," "industry architect," or "AI application engineer." Identifying them, reclassifying them, and giving them growth paths that match their actual work is more efficient than hiring from scratch.
For managers: The FDE model works internally too. Planting a few "internal FDEs" embedded in business units, running model team capabilities end-to-end into business processes, may prove far more efficient than creating a new AI department and holding ten cross-team alignment meetings. Department walls aren't dissolved by org design; they're dissolved by a working demo.
The career transformation of the AI era is already underway. FDE is the first signal flare, telling us: model capability is changing fast enough to force new roles into existence. The author leaves readers with one concrete question — if three new roles appear on your company's org chart three years from now, which three do you think they'll be? Thinking through that question is more useful than finishing this article.
Crossing is looking for independent writers to cover AI product and model reviews.
If you've written articles like: "Hands-on: PixVerse C1", "Hands-on: LibTV", please contact zeo0811@gmail.com. Your email should include: ① personal introduction, ② AI review articles you've written.
We offer competitive compensation. Looking forward to observing and documenting the AI era with you 🎪
References
[1] Henry (DeerFlow team): https://xhslink.com/m/AyUHaIeXWic
[3] Deployment Company: https://www.primeai.solutions/blog/openai-deployment-company-forward-deployed-engineers-uk
[4] To the Super-Individual: https://my.feishu.cn/wiki/AfvNwnZiEirKPSkmUz7cfDlYnM1
[5] Deployment Company: https://finance.biggo.com/news/202605141021_OpenAI-Launches-$4-Billion-Deployment-Company
[6] FDE Recruiter: https://openai.com/careers/recruiter-forward-deployed-engineering-remote-us/
[7] Forward Deployed Engineer role: https://job-boards.greenhouse.io/anthropic/jobs/4985877008
[8] Public data on Anthropic software engineers from Levels.fyi: https://www.levels.fyi/companies/anthropic/salaries/software-engineer
[9] Industry roundup: https://hashnode.com/blog/a-complete-2026-guide-to-the-forward-deployed-engineer
[10] 36Kr retrospective: https://eu.36kr.com/en/p/3568217567575174
[11] SkillScouter's compilation of Palantir hiring criteria: https://skillscouter.com/how-to-become-a-forward-deployed-engineer/
[12] Palantir official careers page: https://www.palantir.com/careers/students-and-early-talent/
[13] Pragmatic Engineer's feature on FDE: https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers