Dazzling demos, painful deployments. This is the most paradoxical gap in enterprise AI adoption today.
The results at the PoC stage often get people's blood pumping, but the moment you try to actually move into production—data scattered across a dozen legacy systems, unclear permission boundaries, business processes full of unwritten rules that "only Old Wang knows"—the model's capabilities feel like punching cotton, unable to gain traction. It is precisely at this gap that an old profession from Palantir has been dug back out: FDE, Forward Deployed Engineer.
It's really not a new term
FDE traces back to Palantir's early playbook. This company served not ordinary internet clients, but governments and large enterprises: physically isolated classified environments, requirements so vague they barely qualified as requirements, and client organizations where "nothing moves unless you send someone over." Its solution was to station engineers directly on-site—understanding the business, writing code, and shipping, all at once, while being accountable for "whether it actually runs in the end." This model was later summarized as Forward Deployed Software Engineer, and the logic can be stated in one sentence: deploying complex systems cannot be done through remote support and documentation; someone has to get into the field.
Interestingly, OpenAI is now hiring for this role too. The JD is blunt: be embedded at the client's company, lead end-to-end deployment of frontier models in production environments, from requirements gathering all the way to launch. Salary range: $160,000 to $280,000, a notch higher than most pure R&D roles. This really says one thing—large model companies have finally realized that selling APIs alone isn't enough; the problem of clients "not knowing how to use" the model after they get it can't be solved by publishing a document.
Same name, different fate
As FDE heats up in China, a phenomenon worth watching out for has emerged: people carrying the FDE title are doing completely different work.
At the bottom is the outsourced on-site type—plainly put, on-site development plus ops billed by the hour, where technical depth depends entirely on the project itself and the ceiling is fixed. One level up is the solutions consultant type, handling both pre-sales and delivery: writing proposals, doing POCs, cleaning up post-launch messes, with the core skill being "understanding what the client actually wants." Then there's the product evangelist type, embedded on-site not to deliver projects, but to treat the client as a test field—observing real usage behavior and bringing feedback back to the product team to drive iteration.
I'll gloss over these three types, because they're essentially all variants of "selling person-days" or "selling solutions." What truly deserves a closer look is the fourth type—the AI agent vendor type. AI companies have gradually realized that no matter how strong the model, it's scrap metal if it doesn't get into the client's business processes. So the vendor itself sends engineers on-site, translating the business into workflows an AI agent can execute, while bringing real-world scenario data back to iterate on the model. Where's the key? One sentence: the integrator won't take responsibility for your product; outsourced delivery delivers a "project," while the vendor's FDE delivers "how your product actually performs in the real world."
Intersecting with it is an even scarcer form—the industry expert type: someone who understands the business better than code, able to translate industry pain points directly into technical requirements, and even define how the AI agent should work. It usually doesn't appear alone, but teams up with the AI agent vendor type.
Put these categories side by side and you'll see that FDE in China is at a stage of "concept first, practice diverging." The names can be the same, but the core determines the value ceiling.
What's delivered is a closed loop, not an AI agent
The most fundamental difference between an FDE and an ordinary AI application developer is what they're accountable for.
The ordinary developer's deliverable is "feature shipped": the API works, the page runs, and the job is done. The FDE's deliverable is "a verifiable change in business outcomes"—they must answer a harder question: which step's costs did AI actually reduce, which decisions' accuracy did it improve, which types of repetitive labor did it replace?
One practitioner broke down a framework that turns enterprise processes into computable objects: an operations dictionary, cost drivers, standard costs, and a business baseline. I don't really want to recite that string of jargon—only one thing in it is truly critical: the business baseline. Without a baseline, you have no way to judge whether AI actually improved the outcome; without stable definitions of operations, the AI agent itself doesn't know what it's accountable for. In the end, you rely on a closed loop to verify: whether judgments are accurate, whether actions were executed, and whether results are confirmed by real business metrics.
This also explains what the most common failure looks like: many AI projects come out "seemingly useful" but the numbers can't be computed. One of the FDE's core capabilities is translating vague "efficiency gains" into concrete numbers that can be put on the table at the client's site, then using those numbers to prove or disprove their own solution.
Not for everyone, and not needed everywhere
FDE has a premise that's easy to overlook: its soil is "non-standard."
Internet companies' AI adoption logic is internal efficiency gains or API scale—light-touch, highly replicable. FDE, however, is heavy on-site presence, high cost, and outcome-oriented, naturally at odds with the business logic of "standardized replication." Its true arena is traditional industries and large organizations with non-standard processes, scattered data, legacy systems, and clients who are all different—government, finance, manufacturing, energy. In these places, the difficulty of AI adoption has never been that models aren't strong enough; it's that the field is too complex.
The cybersecurity industry is a ready-made observation sample. This sector is being squeezed by three things at once: product homogenization, price wars, and lengthening project payment cycles. The core of the FDE model—on-site presence, deep business integration, accountability for outcomes—overlaps heavily with the industry's existing forms of on-site ops, major-event security duty, and security consulting services. So it could be a genuine model upgrade, or just old wine in a new bottle. There's only one watershed: whether the true FDE has product feedback capability—whether on-site experience can be distilled into standardized products, whether subsequent projects can be replicated at scale, rather than forever doing customized "person-day business."
At this point, you can tell whether an FDE team is mature. The mark of maturity isn't how many people were hired, but three things: an independent reporting line, not hanging under sales or R&D; accountability for business outcomes, not just deliverables; and holding the power of product feedback, so frontline experience can directly change the product roadmap. Without that last one, FDE degenerates into a more expensive implementation consultant.
Closing thoughts
The rise of FDE is, at its core, a structural gap in enterprise AI adoption: model capability has already overflowed, but the "last mile" of turning capability into outcomes still lacks people. This gap can't be filled by stronger models or lower API prices; it demands a hybrid capability—technical enough to write production code, business-savvy enough to sit at the same table as the client's business people and break down processes, and delivery-minded enough to be accountable for outcomes rather than features.
But it's not a panacea. When FDE gets slapped around as a label in the hiring market, the most likely result is concept inflation: on-site outsourcing is called FDE, pre-sales support is called FDE, any engineer role that meets clients is called FDE. The questions that truly deserve asking were never "are you an FDE," but three things—what are you accountable for, what is your deliverable, and where did your on-site experience ultimately go. If you can't answer, FDE is just a nicer-sounding job title.