The biggest risk for FDE is becoming a "high-level outsourcing" company. How can this be overcome?

Author: Zhang Feng

The "Outsourcing Trap" and Flywheel Breakthrough of the FDE Model: A Life-or-Death Race for Asset Accumulation.

I. The Underlying Logic of FDE is Proactive Responsibility

When an AI company decides to build an FDE (Forward Deployed Engineer) team, the most common narrative is "benchmarking Palantir"—letting engineers go deep into customer sites and deliver model capabilities into real business processes. The story of Palantir's market value once exceeding $400 billion and its gross profit margin exceeding 80% has attracted countless companies. However, this is precisely the most dangerous starting point of cognition.

II. The biggest risk for FDE is becoming a high-level outsourcing platform

The risk of "outsourcing" faced by FDE is not unique to China, but a common issue in the global wave of AI implementation.

From global data, the explosion of FDE positions itself is accompanied by the risk of model dilution.

From global data, the explosion of FDE positions is itself accompanied by the risk of model dilution.

A LinkedIn report released in January 2026 showed that the number of new FDE (Fixed-Deployment) jobs surged 42-fold from 2023 to 2025. OpenAI established a dedicated deployment company, and AWS invested $1 billion to build a team of thousands of "embedded AI engineers." When capital and talent flood into an emerging field at such a rapid pace, the dilution of models and the lowering of standards are inevitable trends for any emerging profession. The "contradiction between depth and scale" is a common dilemma for all FDE practitioners. As revealed in interviews with 19 practitioners: "The deeper you go into the customer's business, the more likely you are to create value; but it's also easier to absorb personalized needs, leaving experience in the person, and then you have to start from scratch for the next customer. Without depth, there is no value; with only depth, there is no scale." This contradiction is not limited by country, industry, or company size—it is the inherent tension of the FDE model. a16z's warning has universal significance. A partner at a16z AI Applications Investment pointed out that Silicon Valley AI startups are emulating Palantir's FDE model, "offering highly customized services to secure high-value contracts." However, "blindly adopting the Palantir model may lead to a 'service trap'—customized development cannot be productized, resulting in low gross margins and a lack of economies of scale." This is not a problem unique to China, but a common challenge faced by the FDE model globally. Recognizing this is not to lower our guard, but to dispel the attribution illusion of "problems unique to China"—attributing problems to external environments only masks the structural flaws of the model itself. III. China's FDE Problems Arose Earlier and Platform Support is Weaker. Under common patterns, the "outsourcing" risks faced by China's FDE have unique historical depth and structural causes. First, the "do it first, then recognize its value" growth path means that Chinese FDEs lack native platform support. Palantir's FDEs can maintain high gross margins because they have a foundry platform behind them—the FDEs on-site perform "last mile" customization based on the platform. However, most Chinese companies' FDEs follow the "do it first, then recognize its value" approach: many companies don't study Palantir and then build their FDE teams accordingly; instead, they only realize after the AI ​​project is actually implemented that their original organizational structure can't handle the results the client wants. Sales is responsible for signing contracts, pre-sales for solutions, product for general capabilities, and implementation for deployment—but if the AI ​​functionality doesn't generate business results after deployment, who is responsible? The old organization just happens to lack such a person. Thus, FDEs are "grown" out, but often they are just a lone figurehead—no platform, no asset library, and no feedback mechanism. Second, the customer base and willingness to pay of Chinese companies create unique pressure for "outsourcing." Palantir's clients are primarily governments and large institutions, with projects that are large-scale, long-term, and have ample budgets. In contrast, the Chinese AI service market faces the reality of a "weak client base—incomplete data and processes." One practitioner described a typical dilemma: a multi-million dollar contract, the client's top management signs the contract and then delegates it to their subordinates, but these subordinates can't articulate specific requirements. The directive is to "let the FDEs find their own, propose their own, and do it themselves." As a result, the FDEs wander aimlessly through various departments, "trying their luck" to discuss requirements, and end up creating seven AI agents that "are unusable." In this environment, FDEs easily become "firefighters"—not building capabilities, but paying the price for the client's organizational chaos. Third, the mismatch between salary and value proposition exacerbates the "outsourcing" tendency. Palantir's FDE compensation is high in the industry—entry-level positions earn approximately $135,000 to $200,000 annually, while senior positions can reach $155,000 to $307,000. In the Chinese market, practitioners report that outsourced engineers earn approximately 15,000 yuan per month (based on interviews with 19 practitioners), while data from the Liepin platform shows that the average annual salary for FDEs is approximately 408,000 yuan. The logic behind this salary gap is that lower salaries mean lower barriers to entry, which in turn means a large influx of people lacking genuine FDE skills into the market. As industry insiders have pointed out, "FDE without platform support is just another form of high-end outsourcing." The uniqueness of Chinese FDEs lies not in "more serious problems," but in the fact that the problems arose earlier, platform support is weaker, and the market environment is more complex—requiring a more systematic approach to problem-solving than their Silicon Valley counterparts. IV. The Most Critical Issue is the Lack of Asset Accumulation Among the many challenges facing FDE—talent shortage, insufficient customer awareness, organizational power struggles, and difficulties in technology adaptation—which is the most fatal? The answer is: the lack of an asset accumulation mechanism. This is not because other problems are unimportant, but because other problems can be gradually resolved through asset accumulation. Talent shortage? Accumulated skill libraries and templates can reduce reliance on "all-rounders." Insufficient customer awareness? Accumulated industry templates can help the next customer understand "what can be done" more quickly. Organizational power struggles? Accumulated methodologies and evaluation sets can shorten the "alignment" time. Asset accumulation is the only lever that can generate a compounding effect—other investments are linear, only asset accumulation is exponential. A report from Tencent Research Institute provides a concise framework for judgment: "The essential difference between FDE and traditional on-site work lies in whether the asset is accumulated into a reusable asset after the project ends. Leaving only a system for the client is outsourcing; bringing back experience that cannot be reused is project-based; transforming on-site experience into skills, templates, test sets, or product capabilities is FDE; and scalable FDE is one that significantly reduces the cost of the next similar delivery after asset accumulation." This judgment reveals two dimensions of the core lever: First, what is accumulated? It's not about accumulating "project documentation," but rather about accumulating assets that can be directly used by machines—Skills, connectors (system interfaces), industry templates (scenario-based configurations), test suites (evaluation criteria), workflows, and ontology. Leading teams have already accumulated these into four types of assets: deployment templates (one-click infrastructure code), integration component libraries (pre-built connectors for mainstream enterprise systems), industry knowledge bases, and a reusable skill system. Secondly, how should priorities be arranged? "Building an ontology entirely in-house is extremely costly; a more realistic approach is to first accumulate high-frequency skills and system connectors, and then gradually form industry templates and knowledge bases." Start with "high frequency" and focus on "reusability," rather than pursuing a "unified" industry platform from the outset. V. From Manpower Accumulation to Asset Accumulation, From Single-Point Delivery to Flywheel Closed Loop How to turn disadvantages into advantages? How to turn crises into opportunities? The answer lies in two key transformations—from "manpower accumulation" to "asset accumulation," and from "single-point delivery" to "flywheel closed loop." Transformation 1: Transform the seemingly disadvantageous characteristic of "customization" into the unique advantage of "high-value data collection." The essential dilemma of customization is "complete and leave, unable to be reused." However, from another perspective, each customized delivery is a "high-value data collection" that delves into the customer's business environment. The business logic, process rules, failure cases, and boundary scenarios encountered by the FDE in this process are precisely the "real-world data" most scarce for training and optimizing intelligent agents. The problem is not "customization" itself, but whether the knowledge generated by customization has been captured, structured, and encoded into machine-executable capabilities. A research report from Guotai Haitong Securities provides a clear transformation model: FDE enters the customer's site to acquire high-value business knowledge → Harness (the intelligent agent runtime platform) encodes the knowledge into agent-executable capabilities → production operation generates real tasks and failure data → FDE reinterprets and abstracts feedback → Harness and the platform continuously iterate → the next customer deployment is faster and cheaper. The key to this closed loop is that each "customization" is no longer a one-time cost, but an investment for the next "reuse." Transformation Two: Transforming the seemingly passive situation of "on-site pressure" into the primary driving force for "flywheel startup." The on-site pressure of FDE (Fulfillment by Engineering) stems from clients' demanding requirements for results, anxiety about schedules, and aversion to uncertainty. However, these pressures are precisely the strongest driving force for asset accumulation—because only what is accumulated can save time, reduce risks, and increase certainty in the next delivery. Saiyi Information's practice provides evidence: According to Saiyi Information's official disclosure, its FDE system has been verified in more than ten large group enterprises, with delivery cycles reduced by up to 36% and manpower input reduced by an average of over 16%. The core difference lies in "each on-site co-creation feeding back into the platform, enabling similar projects to gradually shift from customized delivery to capability reuse." According to securities reports, CaiXun Technology has achieved a positive cycle of "on-site delivery—capability accumulation—cross-project reuse," with a peak of 430 projects delivered concurrently in the first half of 2026. The specific strategies are threefold: Strategy 1: Establish a "capability accumulation priority" delivery discipline. Before each project ends, three questions must be answered: What skills were accumulated? What connectors were updated? What templates were improved? Projects without asset output are not considered complete. Strategy 2: Build a feedback loop of "on-site → platform → on-site." In the FDE work loop, the feedback loop must be directly connected to the back-end product development team. Problems, data, and requirements from the customer's site are brought back to the platform, ultimately transforming a customized delivery into reusable platform capabilities. FDE needs to "continue to contribute the capabilities developed on the front lines to the back-end, turning a problem exposed on-site into an asset that can be used again next time." Strategy Three: Replace "Manpower Replication" with "Capability Replication." The true scaling of FDE lies not in continuously increasing personnel, but in transforming on-site experience into skills, connectors, industry templates, and platform capabilities, thereby continuously reducing the manpower investment per customer. The next stage of competition "will no longer be limited to the performance of the model itself, but will also reflect whether enterprises can accumulate and replicate FDE practical experience at a lower marginal cost." VI. Transformation, Flywheel, and the Future Looking back at the essence of the FDE model, three universal principles can be extracted: First, FDE is not "on-site" but "transformation." On-site presence is merely a means; transformation is the goal—transforming the client's business knowledge into reusable machine capabilities. As one observer stated, "The core capability of FDE is—abstracting the real world into a structure that AI can understand." Without this, no amount of human investment is more than just another form of "high-end outsourcing." Second, FDE without a flywheel of transformation has no future. The core of the flywheel is not "spinning fast," but "reducing effort with each spin." Every on-site delivery should make the next delivery easier—not by making people more skilled, but by enriching assets and making the platform more intelligent. Those FDE teams that feel "more and more tired" are not working hard enough, but because they haven't established a mechanism for asset accumulation and feedback loops. Third, the greatest opportunity for FDE in China lies precisely in its greatest risk. The risk of "outsourcing" is prominent because Chinese companies have a large enough demand for AI, a wide enough range of scenarios, and a rich enough amount of data—precisely the most valuable "fuel" for training the flywheel. The key lies in establishing a feedback mechanism of "on-site → ecosystem → on-site," transforming every "dirty and tiring job" into capital for the next "easy and efficient" experience. In September 2026, the Ministry of Industry and Information Technology (MIIT) issued the "Notice on Carrying Out a Special Action for Cultivating Artificial Intelligence Application Service Providers" (MIIT Office Science Letter [2026] No. 414), explicitly stating that "service providers are encouraged to build frontline deployment engineer (FDE) teams, rooted in user sites, to ensure the implementation of scenarios." Data from recruitment websites shows that the number of new FDE-related job postings in August alone exceeded the total for the first half of 2026. Amidst this surge, the most concerning issue is not "whether or not to do FDE," but rather "doing FDE but forgetting to accumulate experience." The ultimate goal of FDE is not a large, on-site team, but a smart asset system that grows stronger with use. People can be mobile, but assets must remain; projects can be temporary, but capabilities must be sustainable. This is the only path for FDE to move from "high-priced outsourcing" to a "value flywheel."