After Yesterday’s FDE Roadshow in Shenzhen, I’m More Certain Than Ever: What Enterprises Really Lack Isn’t Models

Yesterday, I went to Shenzhen to deliver an FDE project roadshow presentation to investors and an industry association on behalf of my team.

I had originally planned to talk about how the research system works alongside FDE to get AI actually deployed inside enterprises. But by the end of the conversation, people kept circling back to several more fundamental questions: Is an FDE a person or a service? Is it more like sales or more like engineering? Can programmers make the transition? And how should enterprises actually use this kind of role?

Taken together, these questions expose the biggest gap in enterprise AI adoption today. Models are getting more powerful, but the people who can connect models, business, data, and organizational accountability together are still very rare.

I decided to write up the parts I didn’t get to cover in full at the roadshow. This isn’t just from the presentation deck—it also comes from the headaches I’ve run into doing algorithm deployment, enterprise communication, and FDE projects in the past.

The FDE Gap Is Far Bigger Than How Many Positions Are Unfilled

When discussing talent gaps, it’s easiest to fall into hiring numbers: how many positions were added this year, how much salaries went up, which big companies started recruiting. These numbers change, and the statistical methodologies are messy. I’d rather look at this gap through what happens inside enterprises every day.

Putting together an AI demo is easy now. Grab a few documents for Q&A, use a model to generate reports, hook up a few tools to run some automation—you can see results in half a day. But the moment you actually go into an enterprise, the problems change immediately: materials exist in multiple versions, data is scattered across different systems, account permissions can’t be obtained, business rules only exist in the heads of veteran employees, nobody knows whether to stop the model when it answers wrong, and after launch, nobody maintains the evaluation and cost.

No matter how polished the model’s answers are, if they don’t enter a real workflow, they haven’t produced business results. Even if the system can call APIs, if permissions, approvals, and failure recovery aren’t in place, the enterprise won’t dare let it execute.

What enterprises really lack is someone willing to take responsibility all the way from “what the model can do” to “what the customer actually gets.”

OpenAI’s description of the FDE role is quite direct now: from customer discovery, technical scoping, system design, and building, all the way through to production launch; success isn’t measured by demos completed but by production adoption, workflow changes, and whether on-site feedback makes it back into the product and model roadmap. The current job architecture has also split out FDE, Forward Deployed Software Engineer, Technical Deployment Lead, and Platform Engineer. Anthropic is also configuring engineering, architecture, and deployment roles under Applied AI.

What’s missing here is clearly not just one type of engineer. Enterprises don’t know which piece of work to start with. Technical teams can build demos but aren’t familiar with customer sites. Business teams know the pain points but can’t translate them into systems. When a project finally finishes, the interfaces, processes, and judgment calls modified on-site leave together with the delivery team. The next FDE who comes in has to dig through everything from scratch.

If you only fill one piece of that chain, the project still stalls. Hire an algorithm engineer and you might solve the model problem, but nobody confirms the business objective. Hire a consulting firm and you might get a proposal, but nobody runs the code into production. Have sales drive the project and you might win the deal, but you leave promises that can’t be kept to the delivery team.

So when I say the gap is enormous, I don’t mean how few resumes are on some job board. From enterprise AI moving from interest to results, the entire chain of responsibility in between is empty.

Is an FDE a Person, or an Organizational Capability

By name, an FDE is of course a role: Forward Deployed Engineer. “Forward” means deploying at the front, close to where the problem actually is; “Engineer” means this person must genuinely participate in building and launching, not just stop at recommendations and coordination.

But stepping back, FDE is more like an organizational mechanism that connects the field with R&D.

In yesterday’s deck, I drew it as two ends. On the left is the customer site, responsible for understanding the business, building solutions, and validating value with real data. On the right is the R&D backend, responsible for product planning, platform development, version releases, and foundational capabilities. The FDE constantly shuttles between the two: bringing platform capabilities to the field, and bringing field-validated methods, failure experiences, and common requirements back to the R&D backend.

textR&D backend: models, platform, common components, product roadmap ↓ capability delivery FDE ↑ asset flow-back Customer site: processes, data, edge cases, validation results

If it’s only downward delivery, FDE quickly becomes premium implementation or on-site outsourcing. Rewriting everything for each customer, the more projects there are, the more the company relies on stacking headcount. If it’s only upward reporting, the field turns into requirements collection, and customers wait months before seeing a single product cycle.

The FDE I understand is one that keeps both loops spinning simultaneously: R&D capability flows down to the field, and field results flow back to the R&D backend. Temporarily getting an interface working or handling an edge case in a project only solves the immediate problem. An FDE also needs to break these practices apart: which ones are just this particular customer’s special configuration, and which can be extracted into templates, components, evaluation sets, or standard processes—then take that evidence back to the R&D backend for validation, cataloging, and maintenance. The data integration templates, ontology modeling methods, industry analysis models, agent skill libraries, evidence tracking systems, and research scaffolding from yesterday’s deck are all things this loop should leave behind.

They don’t all have to become software products. A validated set of data field definitions, an edge-case handling checklist, an industry terminology mapping, a set of evaluation questions—these are all R&D assets too. The next time a similar project comes up, the team doesn’t have to copy the previous customer’s solution or start from zero. They can swap data, change configuration, and add a small amount of business logic on top of an existing foundation—delivery naturally gets faster.

So FDE can be carried by one person, or shared by a small team. When it’s one person, they have to do discovery, solution design, engineering, and delivery all at once. When projects grow, it can split into customer owner, FDE, FDSE, platform engineer, and domain expert. How the roles are split can change, but someone must own the chain from customer problem to production results, and bring reusable assets back to R&D. If the team leaves right after launch, the chain hasn’t actually been completed.

If an enterprise only changes a job title without changing the responsibility boundaries between departments, it hasn’t truly built FDE capability.

Which Matters More: Sales Attributes or Technical Attributes

This is the question most likely to spark debate after a roadshow.

My answer is clear: Engineering capability is the threshold for an FDE; customer and commercial capability determines an FDE’s ceiling.

Without technical capability, an FDE quickly becomes a salesperson who can talk about AI. They can make models, agents, and private deployment sound exciting, but can’t judge whether data is usable, whether interfaces can connect, why the model is wrong, or whether the system can go to production. When a customer asks “how do we accept and verify this commitment,” the answer can only retreat to a glossy slide deck.

But an engineer who is technically strong and completely refuses to touch customers will also struggle as an FDE. They might write the most complex systems, but have no idea what the enterprise is willing to pay for, which business owner is accountable for results, or that when a customer says “we want a knowledge base,” behind it might just be support staff spending their days searching through dozens of documents for answers.

The sales attributes I’m talking about here have little to do with drinking, entertaining clients, or pushing for signatures. An FDE has to find out what the customer is paying a price for, get different stakeholders to be willing to reveal their real processes and constraints, and then translate technical choices into scope, value, risk, and cost. When customers push on timeline, price, or outcomes, the FDE also has to hold the line against making promises that can’t be kept.

And all of this ultimately comes back to engineering judgment. If a customer demands launch in two weeks, you need to know whether to cut scope or whether the system simply can’t be built in that time. If a customer insists on on-premise deployment, you need to keep drilling into data boundaries, concurrency, and operations capability. If a customer wants an agent to execute payments automatically, you need to be willing to put approval, idempotency, and rollback on the table.

An FDE isn’t choosing between “sales” and “technology.” Its scarcity comes precisely from the fact that both must land on the same result. Sales capability gets you into the field, engineering capability keeps you there, and delivery results determine whether the customer will let you in next time.

If I had to give different phases different emphases, here’s my take: for a programmer transitioning to FDE, the most important things to learn are customer discovery, communication, and negotiation. For someone transitioning from sales or consulting, the most important things to learn are hands-on building, data, system integration, and production responsibility. Neither side can rely on AI to pretend you already know how to do it.

Why This Roadshow Put the Research System Inside FDE

Yesterday’s theme was “Research Supporting FDE Engineers.” The “research” here means bringing evidence, reproducibility, and review discipline into enterprise delivery—adding a stricter working methodology to FDE.

Enterprise AI projects have a particular problem: a lot of conclusions look true.

The model says “this solution improves efficiency.” The vendor says “this model supports this capability.” The engineer estimates throughput based on parameters, the demo runs through a batch of samples, and the customer judges based on experience that it’s ready to launch. If you don’t distinguish the evidence behind each of these claims, they all get written into the proposal together, as if they share the same credibility.

In the roadshow deck, evidence was split into six categories:

• REQUIREMENT: an explicit request from the customer or project;

• CALCULATED: a result computed from public models and assumptions;

• SIMULATED: a simulation completed using recorded inputs and conditions;

• MEASURED: a result actually observed under reproducible conditions;

• SUPPLIER_DECLARED: a statement from a vendor or external authority;

• CERTIFIED: a conclusion supported by clear certification records.

These six types don’t need to be ranked. What really needs to be prevented is them impersonating each other. A cost calculated from concurrency and token counts is only a calculated result. Running successfully in a test environment only shows it was measured under those conditions. A vendor writing “supports private deployment” doesn’t mean it has passed the customer’s own security review.

Whether a claim can enter the delivery plan depends on what evidence it has, and whether that evidence can be re-examined.

This methodology can directly change an FDE’s daily work. When a customer proposes a goal, first mark it as a requirement. When AI helps with analysis, preserve the assumptions and sources. When engineers do small-step implementation, run validators, scanners, and tests. AI can participate in a second round of review, and then a human confirms privacy, boundaries, and the final conclusion. After a failure, the team needs to be able to return to a well-defined state and continue, rather than digging through chat logs guessing why something was done that way.

The six principles from yesterday’s deck also take on practical meaning: data first, evidence grading, reproducibility, recoverability, human accountability, and privacy boundaries. They sound like research requirements, but they’re all things frequently missing in enterprise delivery. If an FDE only leaves behind code without evidence, decisions, and recovery methods, the R&D backend can’t judge which capabilities are worth reusing, and the project will lose its memory again after personnel changes.

Can One FDE with a Team of Agents Complete an Enterprise AI Transformation

This was the last slide of yesterday’s roadshow, and I believe it’s the point most worth continuing to validate:

One FDE with a team of agents can complete AI transformation delivery.

I agree with this direction, but I need to add one premise: agents can extend execution capability, but responsibility cannot be delegated.

Before, one person could barely complete customer research, meeting notes, solution comparison, prototype development, testing, documentation, and project retrospectives all at once. Now these tasks can be split across different AIs: one handles search and synthesis, another checks code, one generates tests, another compares meeting notes against the current solution for conflicts. An FDE can do with a smaller team what previously required multiple people.

AI doesn’t know about the conflicts of interest a customer hasn’t written into documentation, and it doesn’t know whether “in principle, yes” counts as a commitment. It can’t decide on its own which data is allowed to be uploaded, can’t approve scope changes on behalf of the accountable person, and certainly can’t bear the commercial consequences when a project fails.

So this human-AI collaboration system needs a clear gate: AI can propose, implement, and review; humans are responsible for authorization, merging, and final judgment. Raw material can be organized by agents, but it must be confirmed by a human before entering the project fact base. Code can be drafted by agents, but it must pass testing and approval before entering production. Reports can be generated by agents, but they cannot upgrade their own evidence types.

Agents give the FDE more hands. They don’t give the FDE eyes at the customer site, and they don’t bear the responsibility of signing off for him.

I increasingly believe that in the future there will be very small delivery teams: a few FDEs up front who can enter the field, understand the business, and dare to make technical judgments; behind them, research, development, testing, and delivery agents connected through; and a platform team providing a stable foundation. Agents can help organize field differences, fill in documentation, generate tests, and convert one-off deliverables into candidate assets. FDEs and backend R&D then decide which ones enter common components and which stay in the customer project. The team may be smaller, but the demands on the leading person’s judgment will be higher.

How Programmers Can Transition to FDE

A programmer’s advantages in transitioning to FDE are obvious: an engineering foundation, an understanding of system boundaries, and a better ability to recognize how far an AI demo is from production. The real difficulty is shifting from “someone writes clear requirements and I implement them” to “the requirements themselves are unclear, and I first have to judge what’s worth building.”

The transition doesn’t have to start with memorizing a longer tech stack. RAG, agents, MCP, and model deployment certainly need to be learned, but they’re just tools. A more effective approach is to run one complete small-scale delivery.

Find a real piece of work you have access to. It could be customer service searching for information, sales organizing meeting notes, operations reconciling data, or issue collection after enterprise training. Follow an actual user through their most recent task, recording inputs, actions, judgments, systems, outputs, and edge cases. Then find one step that is high-frequency, measurable, and safe for humans to take over if it fails.

Next, build a very small version. First write out the current state and baseline, then define which step the first phase changes and explicitly what it doesn’t do. Validate with real but anonymized samples, and record where it fails. Finally, leave behind the system, evaluations, run instructions, and retrospective together, and organize the reusable parts into candidate assets the R&D backend can take over.

During the transition, I would deliberately train four types of outputs:

• A current-state assessment the customer can correct;

• A delivery plan with scope and acceptance criteria;

• A minimal system that can be validated with real samples;

• An asset package that explains failures, fixes, and business changes, and can flow back to the R&D backend.

These four things prove your FDE capability far better than “I’ve learned ten agent frameworks.” They also map exactly to the human-AI loop from yesterday’s roadshow: formulate the problem, locate the source, implement in small steps, run validation, double review, preserve and recover.

Programmers also need to proactively enter situations they may have avoided in the past: talking about goals with business owners, watching real processes with frontline employees, discussing permissions with IT, and negotiating scope changes with procurement. Once you become an FDE, communication is no longer prep work before development. Communication itself is part of system design.

How Enterprises Should Think About FDE Correctly

The most dangerous thing an enterprise can do is treat an FDE as an “all-purpose AI-savvy on-site resource.” Hand every requirement to them, have no department provide an accountable owner, and then accept delivery by asking “did you build an agent?”

An FDE is not someone who makes internal decisions on behalf of the enterprise. They can reconstruct processes, point out contradictions, offer solutions, and participate in building—but they can’t confirm business rules on behalf of business units, can’t grant access on behalf of data owners, and can’t decide for management what level of risk is acceptable.

For an enterprise to get value from an FDE, it must provide at least four things: access to the real work site, usable samples, someone with authority to make decisions, and space to validate in a small scope.

After a project is complete, the enterprise also needs to look back and check whether two layers of capability were left behind. For the customer: an operable system, data standards, evidence rules, evaluation sets, run manuals, and failure boundaries. For the delivery organization’s R&D backend: anonymized and abstracted templates, components, industry rules, and evaluation methods. The first layer prevents the customer from becoming permanently dependent on on-site personnel. The second layer lets the next similar project build on top of what this delivery produced.

Yesterday’s roadshow divided the business model into three layers: outcome-based pricing, custom development, and private deployment. This direction can work, but enterprises shouldn’t buy all three layers up front. Before the problem is validated, start with diagnostics or small-scope validation. Once the scenario is proven but the systems differ significantly, move into custom development. Only when data and infrastructure genuinely have clear constraints should private deployment be discussed. Outcome-based pricing also requires agreeing on baselines, attribution, and both parties’ contributions in advance—otherwise “outcomes” just becomes a new source of dispute.

For enterprises, judging whether an FDE is qualified can be as simple as asking: Did they go deep into the real process? Did they personally participate in building? Did they use evidence to explain results? Did they turn field experience into assets the R&D backend can take over? Did they help the customer’s internal team gradually reduce its dependence on them?

If the answer to all of these is “no,” then no matter what the position is called, it’s essentially still sales, consulting, or outsourcing.

After This Roadshow, My Understanding of FDE Is More Concrete

I used to work on AI algorithms, model optimization, and deployment—my familiarity was more on the model side. It was only through later work in enterprise communication, training, and FDE projects that it became increasingly clear: model capability is just the starting point; what enterprises are actually willing to pay for is results.

The FDE opportunity is huge, but it’s genuinely hard. It requires someone who can both enter the customer’s site and come back to code and data; who can drive a project forward while daring to reject commitments without evidence; and who, after finishing the customer in front of them, sends the field-validated results back to the R&D backend, turning them into assets the next project can call, modify, and keep iterating on.

I don’t want to crudely cram sales, consulting, product management, and programming into one job title. It’s just that AI has already made some work that previously required multi-person collaboration achievable by smaller teams, and the FDE happens to stand at the front: holding the context, organizing agents, completing engineering delivery, and responsible for turning a one-off project into a capability the organization can still use next time.

What will truly be scarce in the future isn’t just people who can use AI. It’s people who can take AI into the real world and turn complex problems into verifiable results.

I’m Miles, an AI algorithm specialist who transitioned from a big tech company into FDE. I’ve done model optimization and deployment, and I’ve also done enterprise internal communication and training. Yesterday’s roadshow in Shenzhen was just one field validation along this path.

Follow me @miles_mazy, and I’ll keep writing clearly about how FDEs find customers, communicate, build solutions, and complete delivery with AI. Grow together, earn together.