On the morning of March 6th this year, a line started to form outside Tencent's headquarters in Shenzhen at 10 a.m. People arrived equipped with their laptops, eagerly awaiting assistance from Tencent Cloud engineers to install OpenClaw. By 10 a.m., over 80 individuals had already joined the queue, and by 11 a.m., hundreds of appointment slots were fully booked. According to Tencent, nearly a thousand developers and AI enthusiasts visited the site that day. The queue included a diverse group, ranging from retired aerospace engineers to a fourth-grade elementary school student.

OpenClaw is an open-source software. Tencent's Lighthouse cloud deployment solution can be deployed in as little as five minutes. Meanwhile, some individuals on social platforms began offering installation services. Remote installation fees typically ranged from 50 to 100 yuan, while on-site services could cost several hundred yuan. Despite the software being freely available and deployment tools becoming increasingly user-friendly, people were still willing to pay for installation and configuration services.

Six months later, Tencent repeated a similar initiative. On September 10th, Tencent Cloud introduced the FDE Engineer Certification program, training partners to conduct requirement analysis, solution design, application development, delivery implementation, and security compliance for intelligent agent projects. On the same day, Moonshot AI unveiled the Kimi Enterprise Partner Program, collaborating with traditional IT service providers and system integrators to train frontline deployment engineers.

Volcano Engine's public recruitment page also listed several types of FDE positions: some focused on the development and deployment of agents, others on model selection and inference optimization, while still others specialized in visiting customer sites to understand their specific needs.

In the commercialization of large models, there has always been a daunting challenge that is hard to overcome. While models can be distributed to thousands of enterprises via APIs, each enterprise has its unique ERP systems, databases, permission frameworks, and business processes. Models can be upgraded simultaneously, but clients' systems and organizational structures cannot change in tandem. After selling a model, someone usually needs to follow up and assist in integrating it into the specific work environment.

Therefore, the 'FDE craze' poses the question: if each additional client necessitates sending more engineers, what kind of company will large model firms ultimately become?

Initially, large models appeared to resemble a standardized software business.

Capabilities are encapsulated behind APIs, with unified pricing and invocation methods, enabling clients to develop independently. When a model is upgraded, all clients using the same version benefit.

However, once models are implemented in enterprises, the work is rarely that straightforward. Suppose a company wants AI to assist in contract reviews. When engineers begin implementation, they must first determine where contracts are stored, who has access to them, which policies define review standards, which departments have the authority to modify them, and who ultimately approves them.

Even if the model accurately identifies abnormal clauses in contracts, it may lack permission to access the original documents, let alone decide on internal approval procedures. For each new client, these questions often need to be addressed anew.

The traditional software industry has long grappled with the issue that 'the larger the enterprise and the more legacy systems it has, the more complex its customization needs become, and the heavier the delivery workload.' Developing a product may require a one-time effort, but deploying it across different enterprises demands significant repeated human investment.

Large models have not eliminated these issues; they have merely brought them to the forefront again.

Palantir early on transformed the work of addressing this challenge into a product development methodology—the 'human equivalent of backpropagation.' Engineers work as closely as possible to the actual problems clients face, collaborate with core R&D teams, and continuously feed on-site feedback back to the platform to form new product capabilities.

To understand this approach, one can start with Palantir's three roles. Echo identifies the client's genuine problems and coordinates between business personnel and management. Delta ensures technical solutions operate effectively, including data infrastructure and practical applications. Dev collaborates with the first two roles to develop validated solutions into platform capabilities usable by more clients.

While these roles overlap, they form a collaborative chain from on-site problem identification to product development.

The FDEs publicly recruited by Volcano Engine this year reflect a similar division of labor. General FDEs connect APIs and data systems within client environments, develop prototypes into production-grade agents, and establish evaluation and observability systems. Algorithm-focused FDEs further handle model selection, fine-tuning, and inference optimization, translating client technical issues into product requirements for Ark and Seed.

Volcano Engine also specifically recruits FDE Echos, whose role focuses on interviewing and observing clients to organize vague, scattered business feedback into verifiable product opportunities. The job requirements explicitly state at least five years of experience in solution consulting.

The emergence of such roles largely aims to shorten the distance through which client needs travel within the organization. In the past, when a company said, 'Monthly reconciliation is too cumbersome,' the request might first be received by sales, then passed to presales, product managers, and R&D teams. After several rounds of transmission, R&D might receive only, 'A financial interface needs to be added.'

However, the client's problem may have nothing to do with the interface itself. Are two departments using different data standards, or are historical records missing? Should an interface be added, processes adjusted, or AI used to replace manual verification? Engineers too far from clients find it difficult to judge.

The farther engineers are from the scene, the more they rely on secondhand descriptions to judge problems.

FDEs attempt to push engineers back to the front of the business. By participating in actual processes, building solutions firsthand, and bringing recurring issues back to R&D, the experience from one project can become directly usable product capabilities in the next.

This is where FDEs most easily differentiate themselves from ordinary project outsourcing. After a project is completed, if only revenue and a client-specific codebase remain, delivery is just delivery. However, if connectors, workflow templates, evaluation methods, and new platform capabilities are also left behind, these labor costs can be amortized across subsequent clients.

This is also the commercial reason large model companies are beginning to re-emphasize FDEs. Simply increasing token usage only indicates that enterprises are using more model capabilities. For models to truly integrate into core processes like customer service, finance, R&D, and supply chains, enterprises also need long-term maintenance of data interfaces, permission rules, evaluation systems, and employee operating methods.

These factors determine whether AI can become part of daily enterprise operations and how much delivery resources model companies must invest per client. However, as clients multiply, so may the number of engineers needed on-site. While one model can serve 100,000 enterprises, one engineer cannot simultaneously deploy it across 100,000 enterprises.

Therefore, Tencent, ByteDance, Kimi, and OpenAI have taken different paths.

On September 10th, Tencent Cloud launched the FDE Certification program and began recruiting partners. Tencent organized requirement analysis, solution design, agent development, delivery implementation, and security compliance into training and assessment content, using the ADP platform to help partners build enterprise-grade intelligent agent delivery capabilities. The official positioning is clear: this certification primarily targets professional engineers from partners and individual developers.

This is essentially what IBM, Microsoft, and SAP have done: channelizing delivery.

Tencent's current choice first addresses delivery radius. The ADP platform does not require assigning dedicated engineers to each enterprise; the more partners there are, the more industries and clients can be served. For Tencent, with its vast cloud ecosystem, this system aligns better with its existing commercial foundation than relying solely on proprietary FDE expansion.

However, while channels can replicate engineers, project experience does not automatically replicate.

If one partner develops a special permission process for a bank, another partner serving a second bank may encounter similar issues. If project experience remains isolated in different service providers' codebases and implementation teams, the platform can primarily increase delivery personnel rather than product capabilities.

Tencent must next transform the FDE ecosystem into a system that 'becomes more efficient with each delivery.'

Whether problems repeatedly encountered on-site by partners can stably enter the ADP platform, and whether updated ADP capabilities can return to the entire partner network, determines whether this delivery network ultimately accumulates human scale or product capabilities.

ByteDance has chosen a path closer to internal R&D.

ByteDance publicly recruits a team of FDEs with different divisions of labor. Volcano Engine's general, algorithm, and Echo roles cover application engineering, model optimization, and client needs discovery, respectively. Feishu Commercialization also recruits FDEs to have engineers enter client work scenarios, use Feishu AI tools to build workflows, and standardize solutions and templates.

The greatest advantage of internal teams is shorter feedback loops. If engineers discover suboptimal retrieval performance on-site, they can directly bring the issue back to the model and platform teams. If the problem lies in collaboration processes, solutions can be sought from the Feishu product side. With fewer layers between client sites and product R&D, information loss is naturally smaller.

However, this path also means retaining more delivery costs within one's own organization.

After completing the first bank project, how much can workload be reduced for the second bank? After entering automotive and retail industries, how much of the experience from banking projects can be reused? These questions ultimately reflect in FDE productivity.

For companies building proprietary FDE teams, simply increasing engineer numbers holds little meaning. More critical data points include whether the person-days required for similar projects continuously decline.

If projects multiply while the FDE team expands proportionally, the business may scale, but the organization will also become heavier. Only when on-site experience continuously transforms into standard components, platform capabilities, and industry templates can the advantage of having a self-built team closer to R&D truly materialize.

Kimi skips this step entirely, placing partners at the core of its enterprise delivery plan. On September 10th, Moonshot AI announced collaborations with enterprises such as Teamsun, Kingsoft Cloud, Acon InfoTech, AsiaInfo, and Chinasoft International to jointly train FDE teams. Kimi provides models, Hosted Agents runtime infrastructure, and engineering methodologies, while partners leverage their existing industry knowledge and client service capabilities to complete project delivery.

Kimi can use these partners' established client relationships and delivery teams to enter industries it has not yet deeply penetrated. However, in such collaborations, when an agent does not operate smoothly on-site, whether the issue stems from the model, workflow design, or legacy systems, partners are usually the first to understand. How client-site information returns to Kimi becomes a critical link in this cooperation model.

In January, Hayden Krush, an FDE at medical AI startup Lamar Health, discussed his daily work in an interview with FDE Hub. He is responsible for integrating AI into specialty pharmacies' insurance pre-authorization processes. Sometimes, he spends a week writing code for initial client system integration; other times, he spends a day responding to emails about new client issues.

A significant part of his job involves clarifying exactly how clients want the system to handle highly specific exceptions. For example, if two patients share identical names and birthdates, how should the system choose? Hayden's team opts to leave decision-making to clients rather than having AI decide autonomously. Additionally, he finds that larger functionalities often require client-specific adjustments, while small client suggestions—like modifying a UI element—can quickly benefit all clients.

This is also what Kimi faces: it can use service providers' personnel to enter more enterprises. However, how much of what these individuals learn on-site ultimately enters Kimi's products remains to be tested by subsequent projects.

OpenAI remains classic in its approach—simply establishing a separate company for this purpose. On May 11th, OpenAI announced the formation of Deployment Company, majority-owned and controlled by OpenAI itself, with plans to invest over $4 billion in initial funding. It simultaneously announced its intent to acquire AI consulting and engineering firm Tomoro, which would bring approximately 150 FDEs and deployment experts to the new company.

Deployment Company operates as an independent entity while maintaining connections with OpenAI's research, product, and internal deployment teams. This allows it to establish an organization dedicated to enterprise delivery while preserving pathways for on-site experience to inform model and product R&D.

The over $4 billion investment alone demonstrates the current cost structure of enterprise AI: model R&D remains expensive, but deploying models into large enterprises is also a capital-intensive endeavor.

OpenAI didn't entrust this entire segment solely to Accenture, IBM, or other system integrators; instead, it opted to directly oversee a specialized deployment company. It aims to have ownership over enterprise sites without the need to handle massive (páng dà, where 'huge' translates to 'enormous') project delivery entirely within the core organization of a foundational model company.

This also presents an intriguing facet of the FDE (Foundation Model Deployment Entity) craze: the closer large model vendors get to the core processes of enterprises, the more they find themselves needing to acquire capabilities that have traditionally been the domain of enterprise software firms, consulting companies, and system integrators.

Tencent delegates some of these capabilities to its ecosystem partners, ByteDance retains more of them in-house, Kimi leverages traditional IT service providers, and OpenAI establishes an independent company.

Although the organizational forms vary, all must ultimately grapple with three key questions: who shoulders the costs of delivery personnel, who holds control over client-site information, and to what extent can resources from one project be directly repurposed for the next.

These three factors will dictate whether FDEs ultimately serve as a scaling lever for AI companies or evolve into a cost center that expands in tandem with revenue.

Palantir has already embarked on a journey where software begins to take over tasks that were previously performed by on-site engineers. This year, AI FDEs have gradually acquired more operational capabilities within Foundry, enabling them to manage data, code, evaluations, and platform resources. On September 8th, Palantir further introduced AIP Evolve, a system that allows multiple AI FDE Agents to collaboratively optimize running AI systems. Users can specify objectives such as cost, latency, and evaluation effectiveness, set test data and modification boundaries, and have the Agents propose improvement plans.

When introducing AIP Evolve, Palantir stated: 'You can't scale what only humans can fix.'

This principle applies equally to today's FDEs. The number of certifications Tencent issues this year, the number of engineers ByteDance hires, or the number of partners Kimi signs are merely early indicators. When enterprise AI truly enters a phase of scaling deployment, mere growth in project quantity does not signify a viable model.

If the first bank project requires ten people over three months, and the second project still demands the same, the company's revenue increases, but so do labor costs. However, if the second project only needs five people for one month, and eventually, data interfaces, permission rules, industry evaluations, and common workflows become standardized platform capabilities, the business begins to demonstrate the replicability expected of software.

The most valuable aspect of FDE lies in its ability to transform a costly on-site experience into a resource that can be directly leveraged for the next project.

Following this path, in the future, when an FDE completes a project at a bank, they won't have to start from scratch when writing data interfaces, configuring permissions, or handling familiar exceptions for the next bank.

The pitfalls encountered in the previous project have already been incorporated into the product. Next time, engineers will still need to visit the customer's site, but they can avoid repeating many tasks they've already accomplished.

For today's large model companies, this is likely where the FDE calculus ultimately needs to be clarified: customers can be acquired one by one, but delivery cannot always commence from scratch for each one.

*The title image and illustrations in the text are sourced from the internet.