FDE: The New Role Driving AI Adoption in Enterprises

👦🏻 Author: Henry (DeerFlow Team)^[1]

Over the past month, I met four friends preparing to transition careers—front-end developer, solutions architect, product manager, and traditional algorithm engineer—each with different backgrounds, ages, and cities, yet all asking about the same acronym: FDE^[2]Is it worth it for me to go?

FDE, short for Forward Deployed Engineer^[2]It was once jargon within the Palantir community two years ago; today, it has quietly become a recruiter’s opening line, a frequently listed job title in job postings, and one of the top candidates for “the most valuable job in the AI era” on social media. In May 2026, OpenAI directly established a company named Deployment Company.^[3]With an initial investment of $4 billion, it explicitly stated that engineers would be embedded directly into clients' on-site offices and integrated into their workflows; Anthropic’s Applied AI team is also hiring FDEs simultaneously across four time zones. What began as industry jargon became an explicit term in just over a year.

My previous article, “To the Super Individual”[4], explored how the “human engine”—curiosity, self-learning, self-motivation, and hands-on ability—is activated within a complete Closed-loop. But humans are not suspended; they must be grounded by a specific job coordinate system. If super individuals are the “raw material” of production relations in the AI era, then FDE is the most visible job form that the market has grown this year.

In my view, FDE is not in the consulting box or the outsourcing box—it’s closest to the super individual, with the only difference being that FDE is an organized super individual existing in the gap between “model company × client.”

Did you know—where does the term “Forward Deployed” come from? It originally stemmed from the U.S. military term “Forward Deployed Forces,” referring to troops stationed overseas or at the front lines to enable rapid response, as opposed to rear units remaining at home bases. In the late 2000s, Palantir adopted this term into the software industry to describe the practice of sending engineers away from headquarters to live on-site with clients—even naming internal teams using military phonetics like Delta and Echo. Now, OpenAI and Anthropic have taken it back—not by coincidence—because the core idea of sending engineers to the front lines has never changed.

The three specific questions addressed in this article are those recently asked by four friends of the author:

Is FDE just a consulting firm dressed in AI clothing? Where does its boundary lie with traditional consulting?

Is FDE a more advanced form of software outsourcing? How does it differ from what I'm currently doing as a contractor?

Am I suitable for FDE? Which types of people will thrive in this role, and which will be worn down by it?

The author’s stance is cautiously optimistic: FDE is genuinely taking root, but it is far from a transformational exit for everyone. Clarifying it is more important than sensationalizing it.

If only one event could mark the moment FDE re-emerged into the spotlight, the author would choose May 11, 2026—the day OpenAI announced the formation of Deployment Company.^[5]COO Brad Lightcap left his original business division and transitioned to a special projects role, reporting directly to Sam Altman and dedicating himself full-time to this initiative. In the same week, OpenAI acquired the UK-based AI consulting company Tomoro, bringing in 150 Forward Deployed Engineers and Deployment Specialists all at once.

It’s worth noting that OpenAI’s careers page is currently listing over a dozen FDE roles across San Francisco, New York, Washington, as well as verticals such as Life Sciences, Semiconductor, and Gov—along with the FDE recruiter themselves.^[6]This position is currently open. Analysts estimate the team will expand to 2,000–4,000 people within three years. This is not the scale of a research group—it’s a full-fledged army.

Anthropic is almost mirroring this action—the Forward Deployed Engineer role under the Applied AI team.^[7]Simultaneously launched in Boston, New York, Seattle, San Francisco, Washington, and London, requiring 25%–50% of clients to travel on-site. A recently frequently cited example is the fintech company FIS—its announcement directly states, “Anthropic’s Applied AI team and forward-deployed engineers have been embedded within FIS to co-design the Financial Crimes AI Agent and transfer knowledge to FIS so it can independently scale additional agents in the future.”

This is what the FDE role really looks like. It’s not a pre-sales architect, not an SDR, and not an evangelist coming in to train customers. It’s an engineer who brings models and moves into the customer’s codebase. Brad Lightcap puts it even more bluntly: “Our customers tell us they need the ability to go from pilot to production. Deployment Company means embedding our engineers into their teams and giving them the resources to deliver.”

Drawing this as a diagram will make the three-party relationship very clear:

Pay attention to the two most informative lines in this diagram: the feedback flowing from FDE in both directions. Toward customers, FDE doesn’t sell the model as SaaS; instead, it integrates customer data, permissions, compliance, and internal systems into a single pipeline capable of running models. Toward model companies, FDE brings back real customer pain points and failure samples to product and research, influencing the roadmap—a recurring erroneous tool-calling pattern could become the next built-in abstraction in the SDK.

This is why FDE has been simultaneously revived by two leading model companies in this round—it’s not as simple as “we also want to emulate Palantir’s consulting model.” It’s a signal-gathering mechanism for model companies: the most intense customer pain points on the front lines must be captured by their own people on the ground; demands filtered through partners always come with a layer of distortion. Anthropic is taking a hybrid approach: running FDE in-house while also building joint deployment networks with consulting firms and private equity giants. One leans toward in-house operations, the other toward ecosystem collaboration—but at their core, they’re identical: model companies are no longer just API providers; they’re sending engineers directly into their customers’ products.

The next questions to address are two of the most common comparative ones—where is the boundary between FDE and traditional consulting (like McKinsey or Accenture)? And is it the same as the software outsourcing we’re familiar with?

Many people’s first reaction upon hearing FDE’s job description is: “Isn’t this just the new McKinsey or Accenture?”

I understand this association. Dressing in a suit, visiting client sites, drawing on whiteboards in client meeting rooms, and aligning with C-level executives—on the surface, FDEs and consultants do look similar. But once you look one layer deeper, their core work dynamics are entirely different. Consultants sell process boundaries; FDEs sell model boundaries.

Putting these two side by side in a table makes the differences immediately apparent.

The row worth pausing on in this table is "asset depreciation."

The most profitable logic of traditional consulting is asset reuse—a solution created for one bank can be slightly modified and sold again to the next; a digital playbook for the retail industry can be repeatedly applied to thirty clients. This has been the underlying economic model behind the growth of Accenture, Deloitte, and McKinsey Digital over the past thirty years.

FDE does not have this asset. Model capabilities are evolving rapidly—today requires carefully designed prompt chains, but the next version might accomplish the same with a single sentence. The "methodology consolidation" in consulting will quickly lose value against this pace. Therefore, FDE cannot use an asset-reuse model; it must rerun the entire闭环 each time—reassessing model boundaries, reselecting tool stacks, and reassembling product forms. It may seem inefficient, but it’s the only way to keep up with the speed of models.

Did you know—what is Product Overhang? The author of the previous article, "For the Super Individual"^[4]We’ve explained this term before: the model’s capabilities have surpassed existing product forms, but there’s no product entry point, permissions, or context to realize them. The value of the FDE role is essentially turning the suspended Overhangs from customer scenarios into concrete, operational products. Customers aren’t buying API call quotas—they’re buying the capability that “someone can actually deliver this pile of Overhangs into my business.”

This also explains the difference in the “project structure” row. The standard structure for consulting projects is SOW (Statement of Work) + WBS (Work Breakdown Structure) + phase-based acceptance: the contract clearly defines what will be delivered, when it will be delivered, and the criteria for acceptance. This structure assumes that the objectives are already clearly defined before the contract is signed.

FDE’s projects don’t follow this approach. The most common thing clients 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—they take missions: a relatively vague direction—and then clarify that direction through iterative rounds; finally, in one of those rounds, they turn the accumulated model understanding into a tangible product.

The line "deliverables" is also worth expanding. After FDE leaves, what remains in the client’s system is a working function—perhaps small, perhaps ugly, perhaps with little to no user interface—but it is genuinely being called, modified, and criticized every day. The deliverables of consulting are PPTs and change management reports; even if code was written or ERP systems configured during the project, what ultimately stays in the hands of the client’s executives is still a methodology document.

The "moat" row is the most subtle. FDE’s moat is the real-time intuition for the boundaries of model capabilities—how many real customer scenarios you’ve run this month determines how well you know what Claude 4.7 can do and what must wait for Claude 5. This intuition can’t be written into a PPT or stored in a knowledge base; it can only reside in the minds of engineers who’ve worked with it over the past 90 days.

So next time someone says, “Isn’t FDE just the new Accenture?” you can respond: Accenture’s engineers go to redesign clients’ processes, while FDE goes to rediscover the boundaries of models. The assets of the former can last a decade, while the assets of the latter need to regrow every 90 days.

If "FDE is the new Accenture" is the first layer of misinterpretation, then "FDE is expensive software outsourcing" is the second. This layer is more misleading, because the surface-level evidence appears overwhelmingly convincing: FDE does go to client sites to write code, does customize features according to client business needs, and does adhere to client working hours. At first glance, it seems no different from outsourced engineers.

But just looking at the feedback loop, the difference becomes unmistakable.

The most crucial difference in this diagram isn’t how simple the top half is, but rather the feedback loop extending toward the model company in the bottom half. This loop isn’t decorative—it’s the very reason the FDE role exists. Breaking down this distinction reveals at least four key comparisons.

The things they connect to are different. Outsourcing connects to a SOW—a clearly defined requirements list established before signing the contract: which features to build, what tech stack to use, what criteria for acceptance, and how to compensate for breaches. FDE connects to a mission—the client themselves isn’t clear on what they want, only that “AI should be able to help me with something.” A SOW is predicated on certainty; a mission is predicated on exploration. The two represent entirely different approaches to initiating a project.

The scope is different. Outsourcing handles partial deliverables—a module, a website, a data pipeline—then packages up and moves on to the next client. FDE handles end-to-end—from identifying business pain points, through model selection and product design, to post-launch user retention and churn.

The billing model is different. This is the most counterintuitive point. When a model company sends an FDE to a client’s site, their concern isn’t just how much consulting fee they’ll earn from this project—they’re asking: How many tokens will this client consume going forward? Will they become a retention customer? Will they expand to more business lines? The FDE’s true KPI is the long-term token consumption curve, not the number on the project sign-off sheet.

The feedback goes to different places. This is the deepest group among the four. In outsourced projects, the client’s feedback stops at the outsourcing company and does not influence future products the outsourcing company sells to others. In contrast, FDE feedback flows back into the model company’s roadmap—every pain point, every failed prompt, and every tool invocation bug encountered by customers in real-world scenarios becomes input for the next version of training data, tool design, and product features. In other words, each FDE-deployed customer is, for the model company, a natural design partner.

This is the real reason model companies are willing to pay high salaries to hire FDEs. They’re not just selling a service—they’re collecting real-world product signal data at customer sites. These signals can’t be bought, captured, or uncovered through surveys—they can only be brought back by a specific engineer who has personally hit walls a few times within a specific customer workflow.

Did you know—what’s the total FDE compensation for OpenAI and Anthropic? According to publicly available data on Levels.fyi for Anthropic software engineers.^[8]The median total compensation for senior SDEs has reached $710K. The FDE role carries higher risk—it must contend with uncertainty around model capabilities, client business needs, and product形态, so the industry is consolidating.^[9]It was mentioned that at the cutting-edge AI lab FDE, senior-level package totals generally fall in the range of $350K–$550K, with Staff-level and above reaching $630K+. This compensation is not payment for “outsourced hours,” but rather for bearing the combined risk of “product + customer + model.” > Recall 2006, when I first entered the workforce at a state-owned enterprise undergoing digital transformation; back then, our group hired Accenture consultants on-site, paying them 3,500 RMB per day for several years—these consultants were dubbed “golden collars” by the media at the time. I later joined Germany’s SAP, which even defined a new term in the consulting industry: SAP consultants became the very symbol of the “golden collar.” Seen this way, FDE salaries are likely to continue rising over the next 24–36 months, with demand also steadily increasing.

Outsourcing is labor arbitrage; FDE is a frontline sensor. Confusing the two will lead clients to mistakenly believe they can hire FDEs using an SOW, and candidates will treat FDE roles with an outsourcing mindset. Both sides will hit a wall quickly.

Many people mistakenly believe that the term FDE was invented by OpenAI. It wasn’t. It has two historical roots: one from Palantir, and another from the new generation of model companies after 2023. Looking at these two roots side by side makes it clearer what the FDE role truly does.

First, take a look at the timeline.

The first root is Palantir.

Palantir was founded in 2003 by Peter Thiel, Alex Karp, Joe Lonsdale, and others, with its earliest clients being U.S. intelligence agencies. Karp himself has no CS background—he pursued his PhD in philosophy under Jürgen Habermas in Frankfurt and was later brought on as CEO by Thiel after returning to the U.S. The FDE role emerged precisely from this unconventional combination of a non-typical CEO and highly classified clients: 36Kr’s retrospective^[10]It was stated very plainly that Palantir was heavily criticized by intelligence agencies early on because engineers couldn't access real business scenarios, and requirements became distorted after multiple layers of translation. Later, Palantir secured an arrangement allowing its engineers to work directly on client sites alongside intelligence analysts. This model was later systematized by Shyam Sankar, becoming the雏形 of FDE.

By 2009, FDE had expanded into the commercial sector. When JPMorgan deployed Palantir’s Metropolis platform, 120 FDEs were embedded to monitor for insider threats. From this point on, FDE was no longer just about “sending engineers on site,” but became a structured approach to customer embedding: truly integrating Foundry/Gotham into the client’s business workflows, rather than simply handing over a license and leaving.

Palantir's FDE hiring has an unexpected criterion—no CS degree required. This could fit in a "Did you know?"

Did you know—Palantir FDE does not require a CS degree? According to Palantir’s 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 fields such as mechanical engineering, economics, and philosophy. The two true deal-breakers are: the ability to act with incomplete information, and the ability to communicate directly with C-level clients. A CS degree is a plus, not a requirement. Karp himself is the earliest example of this standard—a philosophy major CEO who has built a team of FDEs with backgrounds in physics, mathematics, and philosophy.

The second root is a new generation of model companies after 2023.

After ChatGPT was released at the end of 2022, OpenAI quickly realized one thing: putting the model API on documentation and expecting customers to integrate it themselves simply wasn’t working. Customers weren’t unwilling to use it—they didn’t know how to use it. They had business problems but no product form. As a result, companies like OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, and Decagon began hiring FDEs at scale.

This wave of FDEs is learning from Palantir’s playbook—sending engineers to client sites to end-to-end operationalize a workflow. But the product载体 has changed completely: FDEs in the Palantir era focused on data integration and UI customization; today’s新一代 FDEs work on prompt design, agent orchestration, tool invocation, and workflow embedding.

Pragmatic Engineer's article on FDE^[13]They call this new version “embedded with enterprises to make Claude solve real, specific, high-value problems”—phrased almost identically to Palantir’s original, only replacing “data” with “model”.

Looking at these two roots together, you can see a clear set of commonalities and differences.

Commonality: Customers aren’t buying software. They’re buying “engineers + a toolkit that solves my problem.” This has been unusual in the past thirty years of enterprise software history. SAP, Oracle, and Salesforce sold software itself—engineers existed as auxiliary resources to make the software affordable for customers. Palantir flips this: the tools exist as leverage to enable FDEs to solve problems for customers. The new generation of model companies inherits this inverted relationship—OpenAI doesn’t sell a GPT-4 license; it sells “our FDEs using GPT-4 to automate your customer service.”

Difference: Palantir era focused on OPS integration—centered on data integration, ontology modeling, and permission governance. The new generation focuses on model capability deployment—centered on prompt design, agent orchestration, and retention optimization. The former is like an advanced system integrator, while the latter is like an extension of a product engineer.

One final interesting fact: Many early Palantir FDEs later became entrepreneurs or joined next-generation model companies. A long list of former Palantir employees can be found in the early teams of Anthropic, OpenAI, Sierra, and Hebbia. This is no coincidence—the FDE role inherently forces one to manage product risk, customer risk, and engineering risk simultaneously, essentially serving as entrepreneurship training. The author prefers to view Palantir as an invisible startup incubator: it doesn’t just produce engineers, but a cohort of people who know how to drive something from zero to one amid incomplete information. Two roots converged after 2023.

The convergence of the two roots primarily occurs overseas. In China, the term FDE has not been around for long, but the work it represents did not emerge out of nowhere. To understand FDE in China, one must first recognize its two local predecessors, then examine the three key differences between it and the U.S. version of FDE.

Two local predecessors

The first predecessor was the solution architect role at cloud providers. Over the past decade, Alibaba Cloud, Tencent Cloud, and Huawei Cloud have cultivated entire teams of Solution Architects (SAs) who present architectures to customers, write POCs, develop migration plans, and support delivery to go-live. Within Huawei, there is even a dedicated "Delivery Engineer" track responsible for implementing projects at customer data centers. This system already handles 80% of FDE work, but its focus remains on pre-sales and deployment—the end-to-end product iteration responsibility does not lie with the SA; changes in requirements require formal change processes, and switching models depends on headquarters’ scheduling.

The second predecessor is a new role emerging from AI startups: MiniMax is listing "AI Pre-sales Solutions Expert" on Boss Zhipin, and similar positions are also posted by model companies such as Moonshot AI, Zhipu, Tongyi, and Hunyuan. Although the job titles vary slightly, the job descriptions are highly consistent: understanding customer scenarios, creating demos, tuning prompts, running RAG, writing delivery plans, and coordinating with customer engineering teams to go live. This wave of roles truly represents the domestic FDE.

Three differences in water and soil

On-premises deployment and data compliance are overwhelming the pure model API invocation model. Domestic B2B customers in China have far higher requirements than the U.S. market for data staying within their premises, control over model weights, and auditable traceability. In an FDE project, the workload of purely calling APIs and running prompts may account for only 30%, while the remaining 70% involves deploying the model to the customer’s data center, enabling authentication, integrating with the data middleware, and completing compliance filings.

Model capabilities are still catching up to SOTA, with room for differentiation narrowing to the engineering layer. In the U.S., OpenAI and Anthropic can win customers with model capability alone; in China, the differences among Tongyi, Doubao, Kimi, GLM, and DeepSeek are less pronounced, so customers increasingly judge based on engineering capabilities such as agent orchestration, RAG retrieval quality, tool integration, and workflow design. Chinese FDEs are competing not on “how strong our model is,” but on “whether we can actually make this business work.”

B-end customers' willingness to pay and pricing rhythms differ from those in the U.S. The model used by Palantir—deploying FDEs first, then charging high subscription fees—is difficult to replicate directly. Domestic clients' budgets follow annual procurement cycles, with payments tending toward project-based models; the FDE business model is often a hybrid of subscription + on-premises licensing + project delivery.

A unique positioning: Internal FDE

Many large tech companies' internal AI teams are now using the FDE model to serve "internal customers." Alibaba Cloud's PAI has assigned engineers to work directly within Taobao, and Tencent's HunYuan has similar mechanisms to support WeChat and advertising teams. JD.com lists roles such as "Industry Implementation Engineers," "AI Application Engineers," and "Intelligent Business Experts"—essentially internal FDEs who take model capabilities and deliver them end-to-end to business teams. This gives leaders at large companies a new approach: place a few internal FDEs on-site with business units, get the first demo up and running, and deliver ROI data directly to business stakeholders—this will break down departmental silos faster than ten alignment meetings.

The author of the previous article, "To the Super Individual"^[4]The text previously described the five engines of a super individual: strong curiosity, strong spirit of exploration and innovation, strong self-learning ability, strong self-motivation, and strong hands-on ability. These five traits are the entry ticket for an FDE role, but not the whole picture. Beyond these five engines, FDE positions require a distinct set of specific additional traits, and certain personality types are clearly unsuited. The author has seen too many excellent engineers struggle after transitioning into FDE roles—not due to lack of ability, but because of mismatched personality and work preferences.

Five traits suitable for FDE

Don’t shy away from sales and communication. A typical day for an FDE isn’t coding behind closed doors—it’s directly engaging with the client’s CTO, business leads, procurement teams, compliance officers, and IT staff. The usual rhythm: a client CTO interrupts you mid-demo. The FDE’s response isn’t “I’ll go back and revise it and come back next week”—it’s opening the IDE right there, adjusting the prompt, and re-running it live. “The client is here, and I’m making changes” is the norm for an FDE.

Embrace the gray area. FDEs don’t receive clear PRDs—they get a statement like, “We want to do something with AI.” Even the client isn’t sure what they want, and it’s the FDE’s job to help shape that vague expectation into something concrete. If you can only act when requirements are clear, being an FDE will leave you anxious every day.

Strong engineering skills are required, but not 10x-level perfection. FDE doesn’t need you to be the person with the cleanest code or deepest algorithms in the company—it needs you to deliver end-to-end: a frontend that can render a clickable page, a backend that can run a working service, and a model that connects to business data sources. In the FDE world, “good enough” isn’t a flaw—it’s a virtue.

Thrive on feedback. FDE roles involve countless moments where work is sent back by clients: today’s demo is rejected tomorrow with “This isn’t what I wanted”; a solution aligned with stakeholders last week must be redone this week because a new executive has taken over. The right person for an FDE role treats feedback as fuel, takes end-to-end ownership, and never blames the “requirements team for not being clear.”

Sensitive to model boundaries. This is the most technical and most implicit rule. FDE must know which tasks are suitable for LLMs and which are not, and how to fallback appropriately—this sensitivity cannot be learned from papers, only forged through failed cases. Only by accumulating failure samples does the FDE develop muscle memory for model boundaries: when to use RAG, when to apply rules, and when to always provide a human fallback.

Four types of people unsuitable for FDE

A pure tech enthusiast who wants to hide in the code. FDEs spend about 50% of their time not writing code, but in client meetings, internal coordination, product discussions, and contract progression. If your joy comes from coding uninterrupted for four hours straight, an FDE role will leave you chronically mentally exhausted.

People who need OKRs to get started. FDE goals are rooted in the customer, not on your performance sheet. Progress is determined by the customer’s project milestones, changes in model capabilities, and your own judgment of the use case. Those accustomed to “needing OKRs to know what to do” will struggle to find their anchor.

People who value promotion over work. FDEs don’t have an advantage in large company promotion systems—metrics like customer satisfaction, project acquisition, and reuse rate carry less weight in level reviews compared to lines of code or deployment frequency. If promotion is your top motivation, FDE is not the right choice.

People who resist commercial contexts. FDEs must understand clients’ P&L, ROI, procurement processes, and compliance requirements. If you naturally dislike discussing money, contracts, or business logic, the FDE role may make you feel like you’re compromising your technical ideals.

Self-Check Checklist

7 questions, each corresponding to a real-world scenario for FDE. If you answer "yes" to five or more, consider FDE seriously; if three or fewer, proceed with caution.

Would you be willing to shift 50% of your daily time from coding to client meetings, replying to messages, and phone calls?

2. When a customer tells you, "This doesn't work, but I can't explain why," is your first reaction curiosity or impatience?

3. No one has given you a PRD—can you work with Claude Code to build a working prototype that you can show to customers within a week?

4. For the same delivery, the client asked you to revise it eight times—can you still maintain your judgment instead of mechanically following instructions?

5. When the model gives an incorrect answer, is your first reaction to design a fallback, or to complain that the model is inadequate?

6. Are you willing to sign contracts, write reports, handle client acceptance, and coordinate with legal on compliance terms?

7. Can you embrace rapid prototyping and rapid failure?

Five traits, four counter-personas, seven self-assessment questions—all ultimately come down to the same question: Are you willing to refine your product sense, engineering strength, and business judgment simultaneously within a single workflow?

In my previous article, I discussed the "human engine"—curiosity, spirit of exploration, self-learning ability, self-motivation, and hands-on skills—and how they can be fully activated within large corporations. This article addresses another topic: the evolution of job roles. FDE is the first newly defined job role in the AI industrial revolution to have a name, a salary range, a job description, and verified customer payment. It is not synonymous with the concept of a "super individual," but rather the first concrete milestone to emerge from abstraction in this wave of restructuring.

FDE is not the end. The author believes that FDE is merely the first形态 to take a name within this new division of labor. Soon, we’ll see Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher—all roles tightly coupled with customer contexts, requiring someone to grow products in ambiguous spaces—to emerge with their own “forward deployed” versions. The job titles may change, but the underlying logic remains the same: model capabilities lead the way, product forms follow behind, and job structures are redefined along the workflow.

Leave one sentence for each of the three types of readers.

For technologists: FDE doesn’t require you to be the best coder in the company, but it does require you to be willing to shift half your time from code to customers. If your answer is “yes,” the market window has just opened—domestic leading model companies, cloud providers, and internal AI teams at big tech firms are accelerating their hiring. If your answer is “no,” that’s perfectly fine—new roles will emerge in this new division just for you.

To HR and OD: Be alert to the disconnect between titles and actual roles. Your company may already have a group of FDEs working under titles like “Solution Specialist,” “Industry Architect,” or “AI Application Engineer.” Identify them, reclassify them, and provide a career path that aligns with their actual work—this is more efficient than hiring new talent from scratch.

To managers: The FDE model isn’t just for external use—it can also be applied internally. Place a few “internal FDEs” directly within business teams to end-to-end integrate model capabilities into business workflows; this may be far more efficient than creating a new AI department and holding ten cross-team alignment meetings. Departmental silos aren’t broken down by organizational design—they’re broken down by a working demo.

The career transformation in the AI era has already begun, and FDE is the first signal flare, telling us that the pace of model capability evolution has accelerated to the point of creating entirely new roles. The author leaves you with one concrete question—if three new positions appear on your company’s organizational chart three years from now, what do you think they’ll be? Figuring out this question is more valuable than reading this article itself.