This article comes from the WeChat official account: Techmo, author: Techmo
Recently, FDE has suddenly become a hot acronym in the AI industry.
In May, OpenAI announced the creation of a company dedicated to helping enterprises deploy AI, and plans to acquire the applied AI consulting firm Tomoro, whose roughly 150 engineers and deployment experts will join. The new company received over $4 billion in initial investment, with McKinsey, Bain, and Capgemini among the participants. After OpenAI's announcement, domestic cloud computing, ERP, and software services companies began talking intensively about FDE.
At the end of August, MiningLamp Technology disclosed in its interim results that about 30% of its delivery staff had transitioned to FDEs, and that it would push for an FDE model transformation at Pansoft; COSCO Shipping Holdings is preparing to cultivate its own FDEs, while iSoftStone, Kingdee, and Seeyon have written FDE into their product delivery systems.
Open recruitment apps, and major companies like Alibaba, ByteDance, Ant Group, MiniMax, and SenseTime are all posting FDE positions to recruit talent.
Why did a concept that has existed at Palantir for over twenty years only become widely popular after the emergence of large models?
This role is usually translated as "Forward Deployed Engineer" or "Forward Deployed Engineer". The name is fresh, but the work scenario feels familiar: go to the customer site, understand requirements, connect data, modify systems, and then accompany the customer to get the project running. Consultants, Solutions Architects, and on-site developers have done similar things in the past.
Whether FDE is a new profession is actually not that important. What companies are betting on is something else: whether they can turn on-site delivery that relies on individual experience into reusable software capability.
What capital markets are buying is not the job title
Palantir views FDE as a product development methodology. Engineers work close to the problems customers are dealing with, then bring field discoveries back to the core R&D team—the company describes this process as "human backpropagation" in software development. Palantir's official documentation shows this methodology has continued from the company's early days to the present.
In recent years, as Palantir's valuation has risen, outsiders have begun to reinterpret the company's growth through FDE. What FDE can explain is why a software company that requires engineers to go deep into customer sites can still maintain the high gross margin of a software business.
General Mills' supply chain project provides a sample. This food company connects with 4,000 suppliers and over 200 factories in North America, processing about 1.2 million orders per year. According to Palantir's published customer case, the two parties connected 200 master data and operational data tables to build a supply chain decision system called ELF. It checks about 3,000 orders daily and provides about 400 adjustment suggestions, of which over 70% are accepted by staff; General Mills says the system saves about $40,000 per day.
The system must simultaneously understand orders, transport capacity, production capacity, costs, and business constraints, and must also know which suggestions can be executed and which decisions must be left to humans. A consultant can propose optimization directions, a traditional implementation engineer can connect the databases, but an FDE must turn vague problems into production systems, and then use adoption rates and business metrics to judge whether the system is effective.
The three roles have no natural boundaries; the difference mainly lies in where responsibility ends. Consultants usually deliver recommendations, on-site engineers are responsible for go-live and operations within the agreed scope, while FDEs must also bring field problems back to the vendor's core products. If you only write one-off code at the customer site and start from scratch on the next delivery, the work is still custom development.
Domestic companies are betting on delivery efficiency
The differentiation in approach among domestic players is also very evident.
MiningLamp Technology is trying to transform its existing delivery team. About 30% of the company's delivery staff transitioned to FDEs in the first half of the year, and the company said it will push the Pansoft team to transform into FDEs serving central and state-owned enterprises. In the past, project experience stayed in the hands of consultants or implementation staff; now, the company is trying to write that experience into Skills and Agents, so that the next delivery relies less on people.
iSoftStone proposes "AI Factory + industry experience + FDE", going all the way from consulting and model deployment to agent development and continuous operations. Seeyon defines FDE as going deep into the field to complete data governance and custom feature development, then feeding business pain points back to internal teams. The former comes from a large IT services provider, the latter from a collaborative management software vendor—both want to add a product feedback link to traditional delivery.
This also points to a risk: FDE is becoming a broad business label. Anyone can rename their pre-sales, implementation, and outsourcing teams as FDEs. To judge whether it is a new model, ask three questions: Do the engineers write production code? Are they responsible for actual adoption? Does the experience from individual customers enter the standard product? Without the last item, no matter how glamorous the job title, it remains a project-based business.
Enterprises will not hand over the whole bunch of keys
The closer FDEs get to real business, the harder it is to avoid the contradiction over permissions.
An engineer who only sees a desensitized order table can quickly build a prototype. But to let the system participate in daily production scheduling and transport adjustments, he also needs to understand supplier tiers, customer priorities, breach costs, and exception approvals. The most valuable information is often not in the database, but in how business staff handle exceptions.
This kind of scenario has already appeared in China. In August 2026, Sungrow O&M (Sunshine Smart O&M) and Kingdee launched a unified intelligence platform project, starting with the review of contracts, invoices, and bidding documents. According to the plan disclosed by Kingdee, the external team will enter the site to organize review rules, samples, and knowledge, establishing a process of "AI initial review, human re-review". Although there is no public result yet proving that efficiency has improved, it shows what FDEs need to access: invoices are just the surface; what really needs to be written into the system are red-line clauses, approval responsibilities, and historical judgments.
Enterprises should not open up all their systems just because the other party is called an FDE. What the external team needs is the minimum information required to complete specific tasks: development and production environments isolated, sensitive fields tiered, accounts authorized by project, code merges approved internally, operations logged, and permissions revoked after the project ends.
Technology can only limit what members can see; it cannot answer why the enterprise is willing to let you see it. External teams may access cost structures, customer relationships, and undisclosed operating rules, and NDAs cannot fully eliminate the risk of knowledge spillover. Conversely, if the enterprise only provides heavily filtered materials, the FDE can easily stall at the demo stage, producing an application that looks smart but actually cannot take over the business.
Deep FDE projects must first solve the trust problem. Mature enterprises must retain internal data owners, business owners, and security teams. External FDEs can enter authorized rooms, but which doors to open, how to interpret business rules, and whether the system can go live—the decision-making power remains within the enterprise.
Internal FDEs vs. external FDEs: who will stay
Clients (Party A) are also building their own FDE teams. In addition to the many internal FDE team recruitment postings from major companies we saw above, COSCO Shipping Holdings stated that it will use FDE talent development as a lever to build an internal AI R&D team combining business and technology. For a large enterprise with a complex shipping network, this choice is easy to understand. External engineers are familiar with models and platforms, while internal staff know better which data standards cannot be mixed, which approval steps cannot be bypassed, and why a seemingly inefficient process has been kept all along.
Internal and external FDEs will cooperate, but also compete. New models and the first batch of high-risk scenarios require external experience; once scenarios enter daily operations, internal teams must take over permissions, evals, and modification capabilities. If vendors are unwilling to hand over, customers will worry about being locked in; if enterprises pull all work back in-house, they may lose the cross-project technical perspective.
To test whether the collaboration is healthy, look at a counterintuitive metric: whether the external manpower needed for subsequent projects decreases. If the first system requires ten people on site, the second still starts from scratch with data cleaning, and the third still depends on the same group of people for firefighting, then FDE has not formed a software lever—it is just a project business charging by person-day.
The best FDE projects should allow the FDE to leave
External FDEs have seen more ways models fail, and better understand what capabilities the product might gain next. This perspective can help enterprises avoid a few demo projects with no production value. But he cannot decide for the enterprise which errors are acceptable, which department should cede power, or who is responsible when automation fails. AI transformation involves adjustments to budgets, responsibilities, and interests, and code can only handle part of it.
We believe external FDEs will exist for a long time, because models and tools are still changing. But within any specific business engagement, the FDE should not become a permanent role. Once a project matures, day-to-day operations should return to the internal team, common requirements should be absorbed into the standard product, and low-level data transformation and troubleshooting will gradually be taken over by AI. Palantir has already launched an "AI FDE" capable of operating Foundry, managing code repositories, and modifying data transformations; the work of human FDEs will shift more toward business judgment, permissions coordination, and exception handling.
An FDE project is truly complete when three outcomes are achieved: the system is still in use after the external engineers leave, the internal team can modify it independently, and the vendor doesn't have to start from scratch when serving its next customer.
If the on-site team keeps growing, the engagement keeps extending, and the customer cannot operate without this group of people, then the AI industry is just giving traditional outsourcing a more expensive name.