Why did FDE suddenly become hot? What AI adoption lacks isn't tools, but people who can go into the field
FDE (Forward Deployed Engineer) is becoming a new keyword in AI adoption. It's not a new job title, but a swing back in enterprise software delivery models, reflecting how AI competition is shifting from model capability to field capability. This article takes a deep look at how FDEs bridge the gap between product and business, and explores their key value in complex scenarios like banking.
Recently, the term FDE has been appearing more and more often.
FDE stands for Forward Deployed Engineer, usually translated as "Forward Deployed Engineer." Taken at face value, it looks like a new job title; but look a little deeper, and it actually reflects an old problem in AI adoption:
Tools can be standardized, but the field is always complex.
Over the past few years, many enterprises have tried AI. Demos look great: copy can be generated, knowledge bases can answer questions, code can be completed, meetings can be summarized, and AI agents can even simulate task execution. But when it comes to actually deploying inside an enterprise, the problems usually aren't with the model—they're in the field.
A bank launched an AI relationship manager assistant. At the demo stage, everything looked smooth: input customer information, and the AI could summarize customer profiles, generate talking points, and recommend next follow-up actions. In the real environment, things immediately got complicated.
Customer profiles come from multiple systems with inconsistent field definitions; which information a relationship manager can see depends on permissions; wealth management recommendations involve suitability and compliance review, so AI-generated talking points can't be sent directly to customers; whether relationship managers use mobile or PC daily also affects the product entry point; and whether outreach leads to deals, asset retention, or customer feedback needs to flow back into the system.
At this point you realize: it's not that AI lacks capability—it just hasn't entered the places where the business actually runs.
The rise of FDE shows that enterprise AI competition is shifting from model capability to field capability. Whoever can enter the customer's real workflow is more likely to turn AI into business results.
FDE isn't a new job title, but a swing back in enterprise software
FDE is most easily presented as a job description. But if it stops there, that's shallow.
It's more like a swing back in enterprise software delivery models.
Early enterprise software was heavy. Every enterprise had its own processes, systems, and organizational structures, so much of the software was project-based, customized, and system-integrated. The advantage was closeness to the business; the drawbacks were long cycles, high costs, and difficulty replicating.
Later, SaaS rose, and the industry pursued standardization. Standard products, standard processes, standard configurations—ideally customers would register, deploy, and expand on their own. This model is elegant and fits the business logic of software companies: the more standardized the product, the lighter the delivery, the easier the scaling.
But in complex enterprise scenarios, things aren't that simple.
Industries like government, finance, energy, manufacturing, and healthcare have scattered data, complex processes, strict permissions, and many organizational layers. Many problems can't be solved with a standard software configuration. Palantir took a different path early on: putting engineers close to the customer's field, kneading the customer's data, processes, and problems into the product. The FDE role was repeatedly validated in exactly these complex enterprise software scenarios.
In the AI era, this problem has come back.
Large models have made demos easier, but they haven't made the enterprise field simpler. In many scenarios, AI has actually made adoption problems more complicated. Before, launching a system mainly meant solving processes and interfaces; now, launching AI also means handling data permissions, model hallucinations, compliance responsibility, result explanation, user adoption, and impact measurement.
So the rise of FDE isn't because enterprise software suddenly loves "on-site presence"—it's because AI has pulled everyone back to a reality:
What enterprises really pay for isn't tools, but the results after tools enter the business.
What gaps does FDE actually bridge?
FDE is not pre-sales, not a consultant, and not ordinary on-site development.
It stands between the model and the field, handling several kinds of gaps.
The first gap is between product capability and business problems. AI companies know what models can do, but customers may not know how their problems should be transformed by AI. Many enterprises say "we want to use AI to improve efficiency"—but that statement is too vague. Whose efficiency? Which part of the process? What metrics prove the improvement? If these questions can't be broken down, AI projects become vague pilots.
The second gap is between data systems and business processes. For a model to answer questions, it must access data; but enterprise data is often scattered across different systems. Customer data, transaction data, product data, entitlement data, outreach data, relationship manager service records—each with its own definitions. If the data can't be connected, AI stays stuck at surface-level Q&A.
The third gap is between technical implementation and organizational adoption. A system going live doesn't mean anyone uses it. If frontline employees don't use it, it may not be resistance to new technology, but that the new system hasn't entered their workflow and instead adds extra steps. For relationship managers, if AI suggestions can't directly become to-do tasks, can't reduce time spent looking up data, writing talking points, or keeping records, it's hard to create real usage.
The fourth gap is between tool output and business metrics. The biggest fear in enterprise AI projects is proving only that "generation looks good" without proving "the business got better." Has relationship manager efficiency improved? Has outreach conversion rate increased? Has AUM retention improved? Have marketing costs decreased? Has customer experience improved? If these metrics aren't designed in, AI projects easily become showcase projects.
What an FDE must do isn't solve a single feature, but connect these gaps.
The work is often very concrete: working with the customer to break vague requirements into verifiable business scenarios, quickly building prototypes, connecting real data, handling interfaces, permissions, and audit requirements, deploying the system to production, and then using logs, usage rates, conversion rates, retention rates, and other metrics to observe whether it's actually working.
More importantly, it must feed field-discovered problems back to the product and model teams. Which capabilities should be productized, which are just one customer's special requirements, which processes should be distilled into templates, which model capabilities aren't stable enough—none of this is work traditional pre-sales can do.
So the "Engineer" in FDE isn't just for show in the job title. It must be able to get hands-on, and also judge which field problems are worth absorbing into the product.
Why are AI companies valuing FDE again?
There's also a business logic behind this.
If an AI company only sells accounts, APIs, or a generic Copilot, it easily becomes a tool vendor. The problem with tool vendors: customers can try many, switching costs aren't necessarily high, and budgets get squeezed.
But if an AI company can enter the customer's core workflows, things change.
It can see the customer's real problems, know which processes hurt most, which data matters most, which roles need AI most, and which results impress management most. It's also easier to move from "tool procurement" into "business transformation budgets."
Selling only generic tools, AI companies easily stay stuck in low-stickiness account businesses; entering the field is the only way into the customer's core workflows, core data, and core budgets.
This is why companies like OpenAI and AWS have started emphasizing forward deployed capabilities. OpenAI's FDE job description doesn't just say "knows how to use models"—it emphasizes complex deployments, going from prototype to stable production, measuring workflow impact, and bringing field feedback back into product and model roadmaps. AWS has also announced building a Forward Deployed Engineering organization, embedding engineers in customer teams to help customers deploy more complex AI systems.
This shows that competition among AI companies is changing.
In the past, everyone competed over whose model was stronger, whose context was longer, and whose prices were lower. Going forward, the truly high-value enterprise market will keep asking: Can you help me put AI into real workflows? Can you make me see business results? Can you turn a pilot into a long-term capability?
Whoever can answer these questions is no longer just selling tools.
In banking scenarios, FDE-type capabilities are especially important
Banking is a classic example of a complex field environment.
It has massive customer bases and strict permissions; rich data and numerous data definition issues; customer managers, operations teams, product teams, data teams, tech teams, and compliance teams—each holding a piece of the real picture. Getting AI to run in a bank is rarely something a single model API can solve.
The more realistic situation is that a bank's field environment is not a unified "customer need," but a set of mutually pulling constraints: business departments want growth, tech departments want stability, compliance departments want control, branches need to be able to execute, customer managers want less added burden, and management wants to see metric changes.
The value of FDE-type capabilities lies in being able to translate between these constraints.
It must translate the business department's "we want to improve conversion" into problems of customer identification, segmentation, outreach, and attribution; translate the tech department's "the API can't be connected yet" into problems of data scope, real-time performance, and system modification costs; translate the compliance department's "no direct recommendations" into problems of suitability, script review, and operation logging; translate frontline customer managers' "it's hard to use" into problems of entry points, tasks, reminders, and feedback mechanisms.
Take customer management as an example: banks are not short of "AI script assistants." What's truly hard is putting AI into a complete management chain:
For example, early warning of high-value wealth client churn. A model can identify a batch of high-risk clients, but once the list comes out, the real problems begin.
Is "high value" judged by point-in-time AUM or average daily AUM? Is the recent decline in activity relative to all clients, or relative to the client's own history? When a wealth management product is about to mature, does it trigger an automatic reminder or one-on-one follow-up by the customer manager? If the client holds loss-making products, can AI generate reassuring scripts? Do the scripts need review? After the customer manager makes contact, how are results fed back? And when evaluating retention effectiveness, do you look at repurchase or asset retention rate?
If no one connects these questions, AI just generates one more risk list. The list may be smart, but the business won't necessarily change.
This is also why I think FDE offers inspiration for banking.
Banks don't necessarily need to create a position literally called FDE, but they need FDE-type capabilities internally: people who understand business, data, systems, compliance, and management metrics simultaneously, and can translate AI from "tool capability" into "business action."
Many AI projects fail not because the model fails, but because the organization lacks the capacity to absorb it
Enterprises often attribute AI implementation failures to the model: not accurate enough, unstable answers, too many hallucinations, unable to understand industry knowledge.
These problems certainly exist, but they're not the whole story.
In many cases, AI projects fail because the enterprise isn't ready internally to absorb AI.
No one unifies the data, no one changes the processes, no one signs off on permissions, no one takes responsibility for risks, no one defines the metrics, no one on the frontline wants to use it. No matter how strong the model, it gets stuck in organizational gaps.
Banking is even more typical. Customer master data isn't unified, tag definitions are inconsistent, real-time and offline data are siloed, permission models are complex, audit logging requirements are high, and model outputs must be explainable. Once AI enters the field, what it encounters is not a single technical problem, but a set of enterprise architecture, data governance, and organizational coordination problems.
This is also why simply purchasing tools can't solve the problem. Tools can provide capability, but they can't automatically transform the organization. For AI to truly work, someone needs to redesign processes, clarify responsibility boundaries, define use cases, design feedback mechanisms, and evaluate business results.
The value of an FDE is not just "helping clients write code," but helping enterprises digest AI into their own organizations.
If a bank's AI project just involves the tech department building systems, the business department making requests, and frontline branches passively using them, it will easily end in three outcomes: headquarters thinks the project is important while the frontline finds it troublesome; the system has many features but little real usage; the reports look great but business improvement is limited.
A truly valuable AI project must make the frontline feel that it reduces work, improves judgment, and delivers results. Otherwise, it's just one more system entry point.
FDE also has costs—it shouldn't be deified
The FDE model has value, but it shouldn't be deified.
Its biggest problem is that it's heavy.
A good FDE needs to understand engineering, business, and communication, and also handle a lot of uncertainty on the client's site. Such people are hard to recruit and hard to replicate. If every client requires deep involvement from a few experts, scaling will be very difficult.
A bigger risk is that FDEs can easily drag AI companies back into a project-based model. Client A gets one build, client B another, client C yet another—short-term delivery fits well, but long-term the product becomes increasingly fragmented.
So a good FDE shouldn't just be a "client-site firefighting team." It must bring field experience back into the product, turning one client's problems into capabilities for a class of clients.
In banking AI marketing scenarios, this accumulation can take the form of customer tag management, strategy orchestration, permission control, compliance review, task distribution, result feedback, and effectiveness evaluation, or industry templates like wealth client management, credit card activation, churn early warning, and benefits operations.
Without accumulation, FDE is just high-cost delivery. Only with accumulation can FDE become an entry point for product evolution.
The future competition isn't about the number of tools, but field capabilities
Why did FDE suddenly become popular?
Not because the job title is new, nor because AI companies suddenly like heavy delivery, but because enterprise AI has entered a new phase.
In the previous phase, people cared about whether you had models, whether you had tools, whether you could generate content. In the next phase, enterprises will care more about: Can AI enter workflows? Can employees use it? Can it comply with organizational constraints? Can it deliver business results?
At this point, what's truly scarce isn't tools, but field capability.
For AI companies, whoever understands the client's field environment better is more likely to enter core business. For banks, whoever can combine AI with customer management, data systems, business processes, compliance requirements, and management metrics is more likely to take AI from pilot to real value.
The rise of FDE reminds us not to "rush to chase a new job title," but to re-understand AI implementation:
AI is not a tool that automatically generates value once handed to employees. It must enter workflows, enter the organization, enter metrics, and finally enter business results.
This is also why I believe that in the AI era, what's scarcest isn't people who can demo tools, but people who can bring tools into the field and turn them into results.
This article was originally published by @老徐的干货铺 on 人人都是产品经理. Reproduction without the author's permission is prohibited
Cover image from Unsplash, under the CC0 license
