LinktierRecently, I exchanged views on X about FDEs (Forward Deployed Engineers) with Shunsuke Ono (@ono_shunsuke), who serves as an AI Strategy Advisor to DMM and is affiliated with Algomatic, through this exchange.
Although I had personally worked with FDEs in the past and am now in San Francisco, where I encounter the latest AI developments every day, many people had already organized and explained the FDE topic well, so I had not written about it myself.
However, as the public discussion has matured and FDE hiring is now actually increasing in Japan, I decided to write this article now in case my perspective and first-hand observations can be of some help for FDE-style businesses at Japanese companies.
I have not been able to follow every public discussion, so there may be perspectives I have missed or points that are off. If anything stands out, I would appreciate your comments.
0. Conclusion: Why FDEs Matter
I will describe the role and details later, but my conclusion is that FDEs will matter in the age of AI agents because AI is shifting from something that answers questions to something that executes work.
With chatbots and RAG, the primary role was information retrieval and answer generation. Of course, even that involves issues of accuracy and permission management, but in many cases the final approval, judgment, and execution were handled by humans.
AI agents, on the other hand, will operate internal systems, send chat messages, manage tasks, update files, and otherwise move workflows forward. In other words, AI agents become a "new user or employee" inside the company.
When that happens, the required design changes all at once. What information may the AI see? Which operations may it execute automatically? Where is human approval required? Who should it escalate to when exceptions occur? How should execution logs be kept? How should company-specific implicit rules and past practices be handled? This is not a problem that can be solved simply by making the model smarter.
That is why, in the age of AI agents, customization aligned with each company's unique operations, permissions, approval processes, and realities on the ground becomes more important. Here, customization does not mean slightly adjusting screens or workflows. It means designing company-specific rules, practices, permissions, and approval processes into executable forms so that AI can perform work safely and reliably.
Against this backdrop, I believe FDEs are becoming more important because they can work deeply inside client environments and connect business understanding with implementation.
1. FDEs Are More Than Implementation Support
An FDE is a technical role that works deeply inside client organizations and frontline environments, handling everything from problem discovery to implementation, production adoption, evaluation, and feedback into the product. Palantir, OpenAI, Anthropic, and other companies use different role names and place the function differently in the organization, but they share the point that FDEs enter client environments and turn complex, ambiguous business problems into production value through implementation and operating design.
In fact, OpenAI announced the OpenAI Deployment Company in May 2026 and explained that FDEs enter client organizations, connect models to customer data, tools, and business processes, and design, build, test, and deploy production systems. Anthropic's FDE job postings also describe responsibilities including building production applications with Claude, supporting implementation in enterprise environments, systematizing reusable implementation patterns, and returning learnings to the product team.
2. AI Enables FDEs to Work End to End
Traditionally, this series of work was often divided among consultants who organized the client's business, systems engineers or PMs who handled client coordination and project management, and engineers who implemented the system. But because AI has improved productivity in research, requirements definition, and programming, a strong FDE can increasingly carry the work end to end.
When I worked with FDEs in the past, what left an impression on me was the speed and agility with which they handled reporting to client executives, interviewing and understanding frontline operations, coordinating with many stakeholders, structuring ambiguous issues, and translating them into implementation direction.
Because the FDE can move forward while reducing communication overhead within the team and deeply understanding the status of every phase, I felt that this role makes it easier to connect the client's reality with implementation and move closer to production value.
3. Compounding Is the Key to the FDE Model
If FDEs are understood only as "people who customize for each customer," the role becomes nothing more than contract development or expensive individual development talent. The economics of the FDE model depend on whether the value created in each engagement can be converted into reusable products, templates, and organizational knowledge, shortening the startup time for the next engagement. Whether this loop turns is the dividing line between FDEs and contract development.
If approval rules, exception handling, permission design, logging requirements, and failure patterns in frontline adoption that required customization at each company are implemented from scratch every time, the work becomes simple custom development.
On the other hand, if those elements can be converted into templates, evaluation frameworks, permission design, approval flows, implementation methodology, and product features, the knowledge FDEs gain in the field returns to the company's own product, the next deployment becomes faster, and the FDE's own work becomes more efficient.
This compounding effect, in which FDEs use their own company's product and that usage experience further improves the product, is important. As long as FDEs manually conduct interviews, organize requirements, design evaluations, check permissions, and prepare reports every time, the FDE model remains heavy. Conversely, if there is a product or internal OS that supports FDE work itself, deployment activity becomes a feedback loop for product improvement.
4. Building Moats and Moving Beyond Time-and-Materials Pricing
When this cycle turns, several moats accumulate.
1. Business know-how
Exception handling, approval structures, frontline tacit knowledge, and failure patterns that cannot be understood without entering customer sites are accumulated.
2. Track record and trust
If AI agents are introduced incorrectly, they become a business risk. That is why customers choose not simply a company with features, but a company they can trust to enter their business and carry it through to production.
3. Product
Issues found by FDEs in the field are reflected in the product. With each deployment, permission design, evaluation frameworks, logging design, approval flows, and templates become more refined, so even if later entrants create a superficially similar UI, differences emerge in production operations and feature quality.
4. Switching costs
When AI agents become deeply embedded in a company's own business rules, permissions, approvals, exception handling, and logging design, the product becomes less like a simple tool and closer to the business operation itself. Replacing it requires not only data migration but also reconstruction of business processes, training, permission design, approval design, and audit design.
What is especially important is that as these moats accumulate, the basis of comparison from the client's perspective shifts from implementation effort to business outcomes, lower implementation risk, and speed to production adoption. With simple contract development, comparison tends to center on time-and-materials pricing or development cost. But when the FDE model works well, clients choose not a cheap outsourcing company but a company that can enter their complex business and safely carry it through to outcomes.
Once this happens, there is less need to compete on who can build more cheaply on a time-and-materials basis, and as a result, value- or outcome-based pricing becomes easier to design and it should become easier to improve margins.
5. The FDE Business Model Must Be Designed Deliberately
As described above, FDEs should play an important role in the age of AI agents. But to maximize their effect, I feel that business model design such as the following is important.
1. A mechanism that reliably returns what FDEs learn to the product
Rather than simply sharing in internal chat or leaving notes internally, the company needs to define clear internal rules and methods so that the field knowledge FDEs learn on site is actually connected to reusable internal know-how, templates, and product improvement.
2. A product designed on the premise of customization
If a product that was not designed for customization is forced to fit a client's business, the burden on FDEs becomes large and truly valuable customization becomes difficult.
3. A product that can support and strengthen FDE work itself
Because the scope of FDE work is broad, the product needs to make FDE work more efficient and more advanced so that FDEs are not exhausted and can produce results that outperform competitors.
4. KPIs That Go Beyond Deployment Count
Because the design described above is important, companies need to look not only at the number of product deployments but also at whether clear customer outcomes are actually being produced, whether FDE work efficiency is improving day by day, and how much field knowledge is being reused in the next engagement. These indicators are necessary to measure whether gross margin and product competitiveness can be maintained over the medium and long term.
6. Agent-Ready and Harness Engineering Capabilities Required of FDEs
I believe FDE work in the age of AI agents will become even more difficult than traditional implementation support. That is because the counterpart is not only a product used by humans, but also a business process executed by AI.
Until now, business systems and SaaS have been designed on the premise that humans look at screens, make decisions, and perform the necessary operations. But when AI agents begin to execute work, products also need to be designed on the premise that not only humans but also AI are users. In other words, it is necessary to design what information AI agents can reference, what operations they can execute, where they request human approval, what logs they leave, and how they recover when they fail.
In this sense, I believe FDEs will be expected to have ways of thinking such as Agent Ready and Harness Engineering.
Agent-Ready product design means embedding into the product and business flow the dedicated permissions, IDs, executable operation scope, operations requiring human approval, execution logs, rollback on failure, available context, and memory and history management that allow AI agents to execute work safely.
I also believe the idea known as Harness Engineering will become important. Harness Engineering is close to the idea of designing pre-execution guidance, post-execution verification, and feedback loops so that AI agents can operate more safely and accurately.
In other words, FDEs in the age of AI agents are not simply people who listen to client requests and build. They need to understand the client's business, grasp that company's unique rules and approval processes, translate them into forms that AI can execute safely, and reflect those learnings back into product design.
Given all of this, I believe the biggest bottleneck for the FDE model in companies is talent acquisition.
FDEs need capabilities that span both business and technology: the ability to notice discomfort in the field, structure ambiguous issues, build prototypes, design for production operations, talk with customers, and determine whether something is an individual requirement or a common pattern that should return to the product. In the age of AI agents, the value of FDE talent that can think deeply across both business and technology, and the difficulty of hiring such talent, should rise further.
7. The Value of the FDE Model for Japanese Enterprises
Japanese enterprises are often said to face issues such as AI adoption stopping at PoC, complex approval processes, difficult cross-department coordination, and frontline work becoming tacit knowledge. At the same time, I think we can also understand the rise of the FDE model as creating room to solve these issues in complex frontline environments that were difficult for SaaS not designed for customization to enter.
In addition, as coding agents lower the barrier to building software, what will matter going forward is not simply developing everything in-house, but deciding what should and should not be built for one's own company. To make that decision, it is important to understand company-specific business rules, frontline know-how, approval processes, and decision criteria, and to convert them into reusable knowledge. I believe the FDE model is also effective in turning this field knowledge into data and structure, bringing it closer to a form that AI agents can use.
AI agents are not something that can be used immediately in production work simply by introducing a standard product. It is necessary to go deeply into each company's business, permissions, approval processes, and frontline practices and design them into a form that AI can execute safely. Especially in environments such as Japanese enterprises, where business processes and decision-making are complex and field knowledge is tacit, I feel that the role of entering the field, understanding the business, implementing, and bringing it into production is highly important.
I myself keep these perspectives in mind every day as I build the business at Linktier, where I serve as founder. I hope to speak with people inside and outside Japan and build a business that is meaningful, even in a small way, so if you have points of concern or different views, I would appreciate your comments.