Palantir FDE, DS, and GTM: Consultants vs. Onsite Engineers
What you’ll learn
- The roles of FDE, DS, and GTM at Palantir and how they work together
- The differences between FDE teams, consulting, onsite engineering, and contract development
- AI deployment roles and services worldwide and in Japan as of August 2026
- Risks from bespoke development, insufficient authority, and dependence on individuals, and ways to address them
- A decision table for reviewing an internal team or external partner
How FDE, DS, and GTM work together
At Palantir, FDE, DS, and GTM cover the work of identifying customer problems, building usable systems, and applying that experience to product improvements and future deployments. Their responsibilities can be understood as follows.[1][2][3][4]
- FDE (Forward Deployed Engineer) is an engineer who works with customers to understand problems and design and implement systems. The role primarily handles technical work.
- DS (Deployment Strategist) defines the business problem and supports deployment and adoption through the business and its users.
- GTM (Go-to-Market) covers the activities that determine which customers a product serves, how it reaches them, and how usage grows. It includes sales, partnerships, and deployment methods. It is not a single job title equivalent to FDE or DS.
These responsibilities overlap with consulting and onsite engineering (development, maintenance, and operational support carried out at a customer’s workplace). A title alone therefore does not explain how much responsibility a team can take on.
This comparison draws on public sources. It does not include customer-field observations by the author or measured deployment outcomes. It compares responsibilities and deliverables, the conditions that suit an FDE operating model, and the checks needed before adopting it. By the end, you will be able to assess whether the model fits your organization or an external partner by looking at the actual division of work.
Palantir FDE: customer delivery and product development
Palantir describes FDE as both a customer-facing role and a way to improve products. Its Architecture Center explains system structure and design. It emphasizes engineers understanding field problems and working with the teams that develop the underlying products. The purpose is to turn customer feedback and observations into features that multiple customers can use.[1]
The job title in its recruitment materials is Forward Deployed Software Engineer (FDSE). This is a software engineering role within the FDE model. FDSEs understand important customer problems and design and implement solutions using data. Their responsibilities include system design, preparing large datasets, developing business applications, speaking with executives, and setting team direction.[2]
Small teams take responsibility from prototype through production, when the system is used in real operations. Writing code directly when needed is part of the job. Code is the program instructions that control software behavior.[2]
This article uses “FDE” for the person and “FDE operating model” for the way of working or team structure. Working onsite is not enough to establish that a team follows this model.
Ontology (a system for representing business data such as orders and inventory, their relationships, available actions, and who is allowed to perform them) also helps explain Palantir’s operational systems. The first article in the series, Palantir Ontology as an operational layer, explains the concept in more detail.
DS: defining business problems and supporting adoption
DS identifies which operations should change and how data can help. Palantir’s job description includes finding out what decisions users need to make and locating the data those decisions require. The role also works with FDEs to build reliable data processing, design user workflows, train users, and explain the work to executives.[3]
The main difference between FDE and DS is their primary area of responsibility. DS candidates also need experience with programming or data-analysis tools, so the distinction is not simply technical versus nontechnical.[3]
FDE focuses on production system architecture and code. DS focuses on questions such as:
- Which operational decision would produce a better outcome if it changed?
- Who will use the system, and when? Where does the current workflow stall?
- Which usage patterns, business measures, or changes in user behavior will demonstrate success?
- How should requests from the field inform product improvements and future deployments?
Limiting DS to schedules and progress tracking leaves out responsibility for observing users and reconsidering the problem. Assigning all business discovery and stakeholder agreement to FDE, however, leaves too little time for either development or adoption support.
GTM: from short trials to sales and wider adoption
GTM involves choosing customer problems, demonstrating value quickly, and turning that evidence into contracts and broader usage. Palantir’s 2025 annual report identifies AIP Bootcamps (short working sessions in which Palantir and a customer build operational workflows using its AI platform), entry points for developers, direct customer teams, and industry partners as ways to do this.[4]
An AIP Bootcamp uses real customer data to create workflows within days.[4] AIP stands for Artificial Intelligence Platform, Palantir’s product for incorporating AI into business operations.
Public materials describe customers and Palantir engineers working together on applying AI to important operations, selecting the first use case (a specific task or situation in which AI will be used), and training users.[5] They test both technical feasibility and fit with the user’s work, beyond simply showing how the product works.
The public materials support the following proposed division of work and collaboration. GTM considers which customers to serve and what value to offer. DS makes the operational problem and conditions for adoption concrete. FDE implements the system so people can use it in practice.
After deployment, DS and FDE share usage results with product, research, and GTM teams. Those findings inform changes to features, evaluation methods, deployment procedures, and target markets. The relationship continues into the next product improvement and deployment, rather than ending with a handoff from sales to engineering.
In the diagram, “GTM hypothesis” means the expected benefit for the customer. “Evaluation/monitoring” means checking expected behavior and watching the running system; “components” are processing steps or screens that other customers can also use; and a “playbook” sets out the deployment steps.
Comparison with consulting and onsite engineering: deliverables, responsibility, and learning
Consulting and onsite engineering vary widely by company, contract, and engagement. A title alone cannot rank one model above another. The useful questions are what the team delivers, how far its implementation and operational responsibilities extend, and where it applies the experience gained in the field.
The table below provides a framework for that comparison.
| Model | Main responsibilities | Typical deliverables | Relationship to implementation and operations | Where field experience is applied |
|---|---|---|---|---|
| Strategy or operations consulting | Problem framing, options, transformation planning, and agreement | Analysis, recommendations, operational design, and execution plans | May hand implementation to another team or continue through execution | The customer’s transformation plans and the firm’s methodology |
| Onsite engineering or development support within the contracted scope | Contracted development, maintenance, operations, and support | Designs, code, configuration, and operational records | Often continues within the customer’s reporting lines and assigned scope | The customer’s systems and the provider’s knowledge |
| FDE operating model | A production system that supports business outcomes and a completed deployment | Usable systems and workflows, code, evaluations, monitoring, and processing steps or screens that other customers can also use | A small team iterates from problem discovery through production and adoption | Customer operations, the provider’s product, evaluation methods, and deployment procedures |
The distinguishing feature of FDE is repeating three activities at short intervals:
- Revisit the problem to solve and the conditions for success
- Build a system that can be used in real operations and measure usage
- Turn experience from the engagement into product improvements or components reusable in other deployments
Combining consulting and engineering duties in one person is not enough. Without the third activity in particular, excellent customer-facing engineering remains difficult to scale as a product business simply by adopting the FDE title.
Conversely, the model can work without continuous onsite presence if the team iterates closely with customers and incorporates that experience into the product.
FDE hiring and changing responsibilities at global AI companies
The August 2026 review found that AI companies beyond Palantir also advertised roles spanning experimentation through production. OpenAI’s Tokyo FDE role covers discovery, technical scope, system design, implementation, and production rollout. It also feeds usage and evaluation results into development plans for products and AI models (the trained systems at the core of AI that make predictions or generate content).[6]
Anthropic also advertises FDE positions in the United States and Europe. In Tokyo, it recruits under titles such as Applied AI Engineer and Applied AI Architect (roles that implement AI or design systems around a customer’s operations).[7]
Palantir’s Forward Deployed AI Engineer (an FDE responsible for generative-AI strategy and implementation) takes responsibility for customers’ generative-AI deployments. The role brings workflows using LLMs (large language models: AI trained on large amounts of text to generate and process language) into production and applies the experience to AIP improvements.[8] These responsibilities suggest that evaluation of AI models, controls for failure, and usability also need consideration alongside data integration and business application development.
AI is also taking on some implementation work. In March 2026, Palantir made its “AI FDE” product capability generally available. It accepts everyday-language instructions to prepare data, edit an Ontology, and create Functions (reusable units of processing such as calculations or data transformations).[9]
A shift in emphasis is one interpretation of these capabilities. If AI can take on routine construction, selecting the right problem and designing test cases and expected outcomes become more important for human FDEs. Permissions, handling unexpected behavior, agreement with users, and decisions about reuse are also relevant. This is an inference from published capabilities, not a measured change in how practitioners allocate working time.
Demand for these roles reflects the gap between trying AI and expanding it across an organization. McKinsey’s 2025 survey found that nearly every respondent organization used AI, while about two-thirds had not begun scaling it across the enterprise.[10] FDE teams help bring deployments into real operations by accounting for existing data, workflows, security, and user behavior.
FDE hiring and services in Japan, and the need for internal capability
The August 30, 2026 review included a Japan Government FDSE role and commercial and government DS roles advertised by Palantir in Tokyo.[11] OpenAI’s Tokyo FDE role requires Japanese and English, along with experience in customer-facing technical deployments, production code, and generative-AI systems.[6]
Japanese companies are also launching services. In July 2026, LTS announced an FDE service combining consultants with AI and software engineers in one team, from strategy through production operations.[12] Hmcomm announced the launch of its FDE business in May 2026.[13]
External expertise alone does not create an internal team capable of managing the work. IPA (Japan’s Information-technology Promotion Agency) reports shortages across every category of AI talent in Japan in DX Trends 2025. At the same time, 40.7% of Japanese respondents said they did not need in-house developers capable of implementing AI-enabled software and systems.[14]
The survey also found that fewer than half of Japanese respondents were actively pursuing generative AI, including trials and consideration, and that adoption within departmental workflows was lower than in the United States and Germany.[14] This presents two challenges when introducing the FDE model.
The first is dependence on external FDEs. Bringing in external specialists while treating internal AI developers as unnecessary does not establish a structure in which the department using the system can take responsibility for deciding how success is measured and for day-to-day operations.
The second is simply renaming existing onsite support. The FDE label does not automatically add product feedback, reusable components, or preparation for the customer to run the system after the engagement ends.
Contracts and deployment plans therefore need to specify what the customer’s business owner and internal engineers will learn, and when they will take over operations.
Five risks for FDE teams and how to address them
Working closely with customers can lead FDE teams to take on too many individual requests or concentrate work in too few people. These issues need attention when the team is designed.
- Growth in bespoke development: Implementing every customer request can create a contract-development business whose revenue depends on adding people and time. Each request needs a decision: incorporate it into the shared product, separate it as a customer-specific feature, or decline it.
- A mismatch between accountability and authority: An FDE may be accountable for outcomes while the customer controls data, workflows, approvals, and user assignments. Both parties need named owners and agreed conditions for stopping the work.
- Balancing sales and deployment speed with production quality: A short bootcamp may show value, but production requires more preparation. Deployment needs to include security review, test cases and expected outcomes, monitoring, incident response, and user training.
- Dependence on individuals (knowledge and decisions concentrated in a particular person): When customer understanding, design, implementation, and communication depend on one person, the reasons for decisions may disappear when that person leaves. FDE and DS should work together and leave records that business, product, and security owners can consult.
- Unclear responsibilities and evaluation criteria: Without agreement on how revenue, deadlines, code output, and adoption are evaluated, priorities between growth and production operations vary by engagement. Responsibilities and evaluation criteria need to be explicit for each role.
Palantir’s adoption guide describes a mature stage in which the customer’s internal team manages daily operations and develops new workflows. Palantir engineers help when needed.[15]
Deployment completion therefore needs to include customer self-sufficiency (the ability to operate and improve the system internally without relying indefinitely on external specialists).
Five criteria for assessing an FDE operating model
The fit of an FDE operating model depends on how responsibilities and authority connect, beyond the job title. The following table draws on the comparisons above to organize the criteria for assessing that fit.
| Criterion | Required answer for an FDE operating model | Sign of a renamed existing role |
|---|---|---|
| Business outcomes | Decision to change, users, baseline measures, and period for assessing impact | Stops at “adopt AI” or “build a demo” |
| Responsibility through production | Owners for prototypes, production deployment, evaluation, monitoring, and incident response | Hands the implementation to another team without explanation |
| Customer authority | Owners who can decide data use, workflow changes, approvals, and user training | External FDE carries outcome accountability alone |
| Product improvements | Owners and meetings for incorporating findings into features, shared components, test cases and expected outcomes, and deployment procedures | Customer-specific code stays within the engagement |
| Conditions for self-sufficiency | Evidence that the internal team can take over operations and improvement, and when | The value of continuing support is measured only by onsite headcount and duration |
Where responsibilities or authority are unclear, clarifying the scope of consulting, contract development, onsite engineering, or customer success (helping customers achieve results with a product) will make expectations easier to align.
The roles of GTM, DS, and FDE need to be considered alongside the customer’s authority to change operations and the product owner’s work on improving features. Adding an FDE title leaves adoption and product improvement dependent on one person if those responsibilities remain disconnected.
However, clearer responsibility within existing roles is more appropriate when field experience cannot inform product improvements, the customer has no owner for change, or bespoke development is the core recurring-revenue model.
The next article examines role-specific skills and the environment that supports development: Developing Palantir-Style AI Talent: An FDE/DS/GTM Playbook.
Summary: assess FDE through production, product improvement, and customer self-sufficiency
The value of an FDE operating model is that one team can keep delivering business outcomes for customers while using that experience to improve the product. Responsibilities and deliverables need to extend to the point where the customer can operate and improve the system internally.
Fit depends on a business structure that can turn field experience into product improvements and on customer authority to change operations. Where those foundations are weak, clarifying existing roles will reduce mismatched expectations.
References
- Palantir, Overview — Architecture Center
- Palantir, Forward Deployed Software Engineer — Japan Government
- Palantir, Deployment Strategist
- Palantir Technologies Inc., 2025 Annual Report, February 2026
- Palantir, Q4 2023 Business Update — AIP Bootcamps, February 2024
- OpenAI, Forward Deployed Engineer — Tokyo
- Anthropic, Jobs
- Palantir, Forward Deployed AI Engineer
- Palantir, March 2026 Announcements — AI FDE is now generally available, March 12, 2026
- McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation, November 5, 2025
- Palantir, Open positions in Tokyo, Japan
- LTS, Full-scale FDE service launch for contact centers and BPO, July 27, 2026
- Hmcomm, Announcement of the next-generation AI implementation business “FDE”, May 15, 2026
- IPA, DX Trends 2025, June 2025
- Palantir, Foundry adoption — Phase 4: Hypergrowth
For the latest releases and updates, check the official website and official documentation.