Learning
Events
Zone
Community
Tools
Articles/Answers/Technical Experts
Publish
Kai Ge
Published on 2026-06-01 19:17:40
Welcome to follow the "Kai Ge Storytelling Series" official account
From Palantir, OpenAI, Anthropic, Google Cloud to Databricks, Scale AI, Harvey — a look at the capability restructuring of full-chain engineers in the age of agents.
Over the past few years, a role in the enterprise digital transformation field has been quietly heating up: FDE, Forward Deployed Engineer.
If you had heard this title ten years ago, most people would probably have assumed it was just "senior pre-sales" or "on-site customer engineer." But in the era of large models and agents, the meaning of FDE has fundamentally changed.
It is no longer just "the person who goes to the customer site to solve problems," but the core force through which AI companies drive cutting-edge technology into enterprise production systems.
At Palantir, it's called Forward Deployed Software Engineer — someone embedded at the customer site who uses platform and engineering capabilities to solve the hardest problems; at OpenAI, it's the person who turns frontier model research breakthroughs into customer production systems; at Anthropic, it delivers technical assets like MCP servers, sub-agents, and agent skills that truly enter workflows; at Google Cloud, it's defined as an embedded builder who pushes prototypes toward production-grade agentic workflows; at Databricks, it's the professional services vanguard helping customers productionize first-generation AI applications; at Scale AI, it develops production-grade AI agents, multi-agent systems, eval frameworks, and human-in-the-loop mechanisms; at Harvey, it enters professional services domains like law, transforming complex industry workflows into replicable AI product capabilities.
In the AI era, what's truly scarce is not people who can call models, but people who can enter the customer site and connect complex business, data systems, organizational processes, and agent capabilities.
These people are the new generation of FDEs.
Figure 1: The evolution of the global FDE paradigm — from on-site customer engineering to production deployment of frontier models and agents.
To understand FDE, you cannot avoid Palantir.
Palantir's official blog defines FDSE clearly: it is a software engineer embedded at the customer site, responsible for configuring Palantir's existing platform and solving the customer's hardest problems. Palantir also specifically distinguishes traditional software engineers from FDSEs: traditional software engineers are more like "building one general capability for many customers," while FDSEs are more like "combining many capabilities for one customer."
This statement is crucial. The traditional engineer's logic is product-centrism: I build a standard product and sell it to many customers. The FDE's logic is customer-site-ism: I enter a customer's real environment and pull together the platform, data, processes, applications, and users to solve a specific and complex problem.
Another Palantir article further explains that the mission of the Forward Deployed Software Engineer is to deliver technology-driven value creation for customers, deploying and customizing the Palantir platform, solving critical business problems, and measuring success by impact on customer goals. It is not one-off consulting analysis, but building long-term solutions together with customers so they can continuously improve themselves.
Not writing code for customers, but connecting code, data, platforms, and business outcomes.
Palantir's job description is also very direct: the FDSE must work directly with customers, quickly understand their biggest problems, and design and implement solutions that use data to solve them; the work may include discussing architecture, handling large-scale data, writing custom web applications, communicating with customer executives, and even building team strategy. Palantir also compares this role to a "startup CTO," emphasizing end-to-end ownership of small-team, high-autonomy, high-risk projects.
This is also why FDE is different from traditional pre-sales. Pre-sales presents solutions; FDEs build them. Consultants identify problems; FDEs turn problems into systems. Delivery engineers complete tasks; FDEs are accountable for customer outcomes.
In the GenAI era, Palantir upgraded this role to Forward Deployed AI Engineer. Its job description is even more explicit: the FDE must work directly with customers, own GenAI strategy and implementation, build end-to-end workflows every day, push them to production, solve the largest-scale real-world problems, and feed frontline experience back into the Palantir AIP product suite. Palantir also explicitly emphasizes that this role must solve real business problems, not academic benchmarks.
FDEs don't exist for demos; FDEs exist for real business outcomes.
If Palantir defined the prototype of the FDE, then OpenAI has redefined the boundaries of the FDE in the AI era.
OpenAI's FDE team positioning is: helping customers translate research breakthroughs into production systems, working at the intersection of customer delivery and core platform development. Its job responsibilities emphasize that FDEs must lead the most strategic customers through complex end-to-end production deployments of frontier models, responsible for discovery, technical scoping, system design, build, and production rollout.
This means that in OpenAI's view, the FDE is not an "implementation consultant for model APIs," but a full-chain owner from problem discovery to production launch.
More importantly, OpenAI's description of success criteria deserves close attention: FDE success is not just about getting the model connected, nor about a successful demo, but about production adoption, measurable workflow impact, and the ability to change product and model roadmaps through eval feedback.
There are three key phrases here.
First, production adoption. Success only counts when customers actually use it.
Second, measurable workflow impact. There must be a measurable impact on customer workflows — it can't just stay at "the experience is great."
Third, eval-driven feedback. Frontline eval results must feed back into product and model roadmaps.
OpenAI also requires FDEs to own technical delivery from the first prototype to stable production, build full-stack systems, embed with customer teams, understand customer needs and drive adoption; when progress or clarity depends on code, FDEs must also write code directly; meanwhile, they must distill their working patterns into tools, playbooks, or building blocks for other teams to reuse.
The FDE that AI companies truly need is not "someone who can talk about model capabilities," but "someone who can turn model capabilities into customer productivity."
From OpenAI's definition, an FDE must span at least five levels: understanding customer business scenarios; defining technical boundaries and system design; personally building full-stack systems; driving production launch and customer adoption; and using eval results to feed back into products and models.
This also raises the bar for domestic companies cultivating FDEs. Many teams are still stuck at the "can build an AI demo" stage, but companies like OpenAI have already raised the standard to "from demo to production, from production to evals, from evals to product evolution." This is the second evolution of the FDE.
Anthropic's FDE role better reflects the technical changes of the agent era.
In its Forward Deployed Engineer, Applied AI job description, Anthropic explicitly requires FDEs to build production applications based on Claude models within customer systems, and to deliver technical assets such as MCP servers, sub-agents, and agent skills—assets that will be used in production workflows.
This points to an important trend: the deliverables of FDEs are shifting from "application systems" to "agent capability units."
In the past, when doing enterprise software, we delivered pages, reports, workflows, and APIs. Now, when doing enterprise AI, we deliver: agents that can call tools; MCP servers that can connect data sources; sub-agents that can take on subtasks; agent skills that can encapsulate professional capabilities; and agent components that can be incorporated into workflows.
Anthropic's requirements for candidates are also clear: they need LLM production experience, including advanced prompt engineering, agent development, evaluation frameworks, and large-scale deployment capabilities; they also need programming skills such as Python, the ability to handle ambiguity in complex organizations, and a commitment to the values of safe and beneficial AI systems.
This is crucial for how we design FDE training. Traditional FDE training that only covers customer research, prototyping, and system integration is no longer enough. FDEs in the agent era must master four new things: agent architecture, tool protocols, eval frameworks, and safety boundaries.
The FDE of the AI era is not just an application engineer, but an Agentic Workflow Engineer.
Google Cloud's definition of the FDE comes closest to the real pain points of enterprise AI implementation today.
Google Cloud's Generative AI FDE job posting states: the FDE is an embedded builder who connects frontier AI products with customers' production-grade realities. Unlike a traditional advisory role, the FDE acts as an innovator-builder, entering the customer environment to code and debug, and to jointly deliver customized agentic solutions with the customer.
This statement is especially worth unpacking. First, embedded builder: the FDE doesn't stand outside talking about architecture, but embeds itself to build. Second, the bridge between frontier AI products and production-grade reality: model providers have the strongest models, customers have the most complex realities, and the FDE is the translator and connector in between. Third, code, debug, jointly ship: not advisory, not PowerPoint, not workshops, but writing together, debugging together, and launching together.
Google Cloud also explicitly states that the FDE must address the obstacles preventing AI from reaching enterprise-grade maturity, including integration complexity, data readiness, and state-management issues. It also requires FDEs to turn field insights into feedback for Google Cloud's product roadmap.
This hits almost every core obstacle in enterprise agent implementation. Many enterprise AI projects fail not because the models aren't strong enough, but because the data isn't ready, business processes haven't been broken down, system interfaces haven't been connected, permission boundaries haven't been defined, multi-turn task state management is chaotic, evals and observability are missing, and end users haven't adopted the solution.
Google Cloud's skill requirements for the role are also very specific: the FDE must be able to implement multi-agent systems and understand complex agent patterns such as ReAct, self-reflection, and hierarchical delegation; understand LLM-native metrics like tokens/sec and cost-per-request; be able to implement agentic workflows involving MCP, tool-calling, and OAuth authentication; build full-stack applications that interact with enterprise IT infrastructure; and identify business problems through interviews.
The core battlefield of the FDE is not showcasing model capabilities, but clearing production blockers.
Whoever can get the dirty, hard work done—data, interfaces, permissions, state, evals, and user adoption—is the one who can truly put AI into production.
Databricks' AI Engineer - FDE role places the FDE in the context of a data intelligence platform.
Databricks says the AI Forward Deployed Engineering team is a highly specialized, customer-facing AI team that helps customers build and productionize first-of-its-kind AI applications, while collaborating with engineering, product, developer relations, and other teams to influence long-term strategic priorities.
It requires FDEs to develop frontier GenAI solutions, have the ability to take GenAI applications for consumer and internal users to production, serve as trusted technical advisors to customers, and collaborate with product and engineering teams to influence the product roadmap.
More critically, its skill requirements: candidates need GenAI application experience, including RAG, multi-agent systems, Text2SQL, fine-tuning, and more; they also need the ability to deploy, evaluate, and optimize production-grade GenAI applications, as well as data science, machine learning, cloud platform, and large-scale distributed data processing capabilities.
An FDE without data engineering skills will struggle to build truly usable enterprise agents.
Because an enterprise agent is not a simple chat window—it typically has to handle the enterprise knowledge base, historical documents, business databases, metrics systems, permission data, ticket data, CRM, ERP, MES, OA, logs and behavioral data, external public data, multimodal files, and structured tables.
An FDE who can't do data ingestion, data cleaning, schema understanding, vector retrieval, Text2SQL, or RAG quality evals will easily end up building an agent that is a "talks the talk but unreliable" shell.
Databricks' biggest lesson for domestic FDE training is: agent bootcamps can't just teach prompting and AI coding—they must put data engineering, RAG, Text2SQL, evals, and data governance into the core curriculum. The FDE of the future is half agent engineer, half data product manager.
Scale AI's Forward Deployed AI Engineer role places greater emphasis on combining "reliable AI systems" with "data infrastructure."
Its job posting requires FDEs to develop production-grade AI agents for customer use cases, covering scenarios such as customer service, data analysis, content generation, and workflow automation; to architect multi-agent systems that orchestrate across different models, tools, and data sources; to implement eval frameworks to measure agent performance and iterate continuously around business goals; and to design human-in-the-loop workflows and feedback mechanisms.
This description is almost the standard answer for the Agentic FDE. A mature enterprise agent cannot just answer questions; it must enter a closed loop: task input, agent execution, tool calls, human confirmation, result evals, feedback learning, and continuous optimization.
Scale AI also requires FDEs to do prompt strategy, prompt library, A/B testing, RAG, and fine-tuning pipelines; at the same time, they must serve as the primary technical contact for strategic enterprise customers, train customer teams, and translate customer needs into product improvements.
Even more notably, Scale AI defines the debug scope as "the entire tech stack from data pipelines to model outputs," and requires rapid prototyping to help customers unblock, while identifying productizable common patterns.
This means the FDE's job is not "I finish one customer project and it's done." A truly excellent FDE must complete three transformations: first, transform customer problems into agent prototypes; second, transform agent prototypes into production-grade systems; third, transform production-grade systems into replicable product assets.
Harvey is a representative in the legal AI field. Although not all of its roles are called FDE, it clearly illustrates what kind of people vertical-industry AI deployment requires.
Harvey's New Verticals engineering role requires engineers to handle end-to-end issues including user applications, backend services, data systems, document and knowledge pipelines, and agentic workflows; depending on the problem, the work may involve building frontend experiences, designing APIs, building data models, setting up ETL pipelines, improving retrieval and eval loops, orchestrating long-running agents, or delivering platform capabilities.
More importantly, it requires engineers to work directly with customers, product, design, and engineering, understand complex legal workflows, and translate them into robust, scalable software. Harvey explicitly states that the goal is not to deliver custom solutions, but to identify repeatable patterns and turn them into durable products and platform capabilities.
This is the core of the vertical-industry FDE. In fields like legal, securities, transportation, energy, manufacturing, and government, the reason AI deployments fail is often not technology, but "not understanding the business."
If you don't know how lawyers review contracts, how investment advisors conduct suitability management, how dispatchers handle exceptions, how engineers troubleshoot equipment failures, or how government agencies write application materials, it's very hard to design truly usable agents.
Harvey's Legal Engineer role further illustrates the value of the "domain-expert FDE." Legal Engineers are practicing lawyers from top law firms or corporate legal teams; through customer discovery, education, and demos, they map Harvey's AI solutions onto lawyers' daily workflows, and act as the voice of the customer, bringing feedback to the product team.
Future FDEs will include not only technical types but also domain-expert types. Industry knowledge is not an add-on capability for an FDE—it is the FDE's moat.
Figure 2: The Agentic FDE nine-grid capability model.
Synthesizing these companies' public job postings and official materials, we can see that a common capability model for FDEs is emerging globally.
First, customer-embedding capability
FDEs must be able to go on-site with customers and work alongside frontline users, business owners, technical teams, and executives. Palantir emphasizes directly supporting one customer and driving impact around customer goals; OpenAI emphasizes embedding with customer teams, understanding needs, and driving adoption; Google Cloud directly defines the FDE as an embedded builder.
Second, problem-discovery capability
FDEs don't wait for requirements; they do discovery and scoping. OpenAI explicitly puts discovery and technical scoping at the very front of the job responsibilities; Harvey also emphasizes understanding specific legal workflows through customer discovery.
Third, full-stack engineering capability
The consensus among global tech giants on FDEs is: they must be able to write code. OpenAI requires building full-stack systems and directly contributing code when needed; Google Cloud requires code, debug, and jointly ship; Harvey requires end-to-end building of frontend, backend, APIs, data models, and developer tools.
Fourth, agent engineering capability
Anthropic requires MCP servers, sub-agents, and agent skills; Google Cloud requires multi-agent systems, MCP, tool-calling, and OAuth; Databricks requires RAG, multi-agent systems, Text2SQL, and fine-tuning; Scale AI requires production-grade AI agents, multi-agent systems, and human-in-the-loop.
Fifth, data engineering capability
Databricks emphasizes data and AI platform capabilities, requiring FDEs to have data science, machine learning, cloud platform, and distributed data processing skills; Scale AI requires debugging the entire tech stack from data pipelines to model outputs; Google Cloud explicitly lists data readiness as a blocker for enterprise AI productionization.
Sixth, eval and observability capability
OpenAI emphasizes eval-driven feedback; Anthropic requires evaluation frameworks; Google Cloud requires evaluation pipelines and observability frameworks; Scale AI requires implementing eval frameworks and iterating around business goals.
Seventh, organizational-driving capability
FDEs must be able to collaborate with customers, sales, product, engineering, security, and GTM. OpenAI requires collaboration with Product, Research, Partnerships, GRC, Security, and GTM teams; Anthropic requires building long-term customer relationships and identifying new AI deployment opportunities; Scale AI requires training customer teams and serving as the technical contact for strategic enterprise customers.
Eighth, productization capability
This may be the biggest difference between FDEs and outsourced engineers. OpenAI requires distilling effective working patterns into tools, playbooks, or building blocks; Anthropic requires identifying and codifying repeatable deployment patterns; Google Cloud requires turning field patterns and friction points into reusable modules or formal product requirements; Harvey requires turning custom solutions into durable product and platform capabilities.
Figure 3: A truly excellent FDE distills a single customer delivery into replicable industry assets.
If we translate the requirements of these global tech giants into the context of Chinese enterprises' AI transformation, the FDE should be redefined as:
An FDE is an AI-native, full-chain engineer embedded at the customer site, responsible for end-to-end delivery spanning customer research, problem identification, technical scoping, agent solution design, AI Coding prototype building, data and system integration, evals and security governance, through POC conversion and productization.
There are several key terms in this definition. First, being embedded at the customer site. If you don't go on-site, you don't understand real problems. Second, AI-native. Not a traditional software project manager with a bit of AI added on, but redesigning the solution from the ground up around models, agents, data, tool calls, evals, and security. Third, full-chain coverage. From customer research to POC conversion, from prototype to production, from delivery to productization—you need to understand it all. Fourth, results-oriented. Not just completing tasks, but driving customer adoption, validating business value, and creating opportunities for the next project. Fifth, productized accumulation. Every customer engagement should produce a scenario template, an agent PRD, tool interfaces, an eval set, a demo script, and an ROI model.
People like this are very much like special forces for enterprise AI transformation. They don't necessarily sit in the nicest offices at headquarters; instead, they constantly move between customer sites, meeting rooms, data centers, business departments, and frontline processes.
They must be able to hear a customer say "our efficiency is too low" and follow up with "which process, at what frequency, what losses, who makes the decisions, where is the data." They must be able to write code and also judge whether a feature has commercial value. They must be able to build agents and also know which actions cannot be automated and which require human-in-the-loop. They must be able to build demos and also design POC acceptance criteria. They must be able to win over frontline users at the customer, and also explain to customer leadership why this is worth funding.
This is the profile of the new-generation FDE.
Based on the public requirements of major global companies, the FDE training system can be further upgraded into nine modules.
| Module | Training Focus |
|---|---|
| Global FDE Awareness | The role paradigms of Palantir, OpenAI, Anthropic, Google, Databricks, Scale, and Harvey |
| Customer Research | Industry, company, business chain, organization, key people, budget path |
| Problem Discovery | Discovery, Technical Scoping, business losses, process breakpoints |
| Opportunity Conversion | Lead scoring, POC entry points, ROI narratives, customer next steps |
| Agent Design | Agent roles, tasks, tools, permissions, state, auditing |
| AI Coding | Frontend, backend, APIs, databases, model calls, rapid prototyping |
| Data Engineering | RAG, Text2SQL, ETL, vector databases, data quality, knowledge bases |
| Evals and Governance | Evals, Observability, Guardrails, Human-in-the-loop |
| Productized Accumulation | Playbooks, components, templates, scenario assets, product roadmap feedback |
The ultimate goal is not to train "people who can use AI to write code," but people who can take the tangled mess at a customer site and restructure it into an agent that is runnable, evaluable, deliverable, and replicable.
Today, AI is not short of models, APIs, or demos.
What is truly scarce is someone who can bring these capabilities into real enterprise scenarios, breaking through organizational walls, data walls, process walls, security walls, budget walls, and cognitive walls.
Traditional pre-sales can't do this. Traditional consultants can't go deep enough. Ordinary engineers can't cover it all. Pure product managers can't move fast enough.
That's why the FDE emerged.
The FDE is the frontline deal-maker of the agent era. They stand at the customer site and at the product frontier; they understand business and code; they know technology and organizations; they build prototypes and drive conversion; they solve one customer's problem and distill a pattern for an entire industry.
In the future, the real dividing line in enterprise AI transformation won't be who bought the strongest model, but who has an FDE team that can truly fight and win.
Traditional engineers deliver features; FDEs deliver outcomes. Traditional pre-sales talk about solutions; FDEs build them. Traditional consultants discover problems; FDEs turn problems into systems. Traditional delivery completes projects; FDEs distill projects into product capabilities. The scarcest people in the AI era are not those who can call models, but those who can turn the customer site into a battlefield for agents.
智胜 | THE INTELLIGENCE EDGE
Strategy · Insights · Impact
This article is part of the Tencent Cloud Creator Sync Exposure Program, shared from a WeChat official account.
Originally published: 2026-06-01. For removal due to infringement, please contact cloudcommunity@tencent.com
Table of Contents