How Forward Deployed Engineering Differs at Palantir, OpenAI, Ramp, and Salesforce

Palantir, OpenAI, Ramp, and Salesforce all employ forward deployed engineers. Ask each what the job involves and the answers diverge.

A forward deployed engineer is a software engineer embedded with a customer's team to deliver a technical outcome. Even if it's a shared title, the job is not.

Forward deployed engineer roles vary by company in four ways. The differences are where the role sits, what engineers deploy, which customers get support, and how field learning feeds the product.

Those choices matter to anyone building or buying this kind of delivery. Palantir's engineers deploy platforms Palantir owns, while Ramp's team of 16, as of August 2025, builds features that ship in its core product.

This article compares how each company structures the role, then looks at what enterprise leaders can take from it.

Key Takeaways

• The title is the same, but the job is not. Four factors explain most of these differences. They are where the team sits, what it deploys, which customers receive the service, and how field learning feeds back into the product.
• Palantir deploys its own platforms. Its Deltas work in teams dedicated to one customer and, in Palantir's description, sit within Business Development.
• OpenAI separates FDEs from solutions architects. FDEs write code on customer infrastructure, while solutions architects mostly advise.
• Ramp runs FDE inside engineering. The team follows each customer from prospect to long-term support and grew from 2 to 16 engineers by August 2025.
• Salesforce built its team around Agentforce. It started in April 2025. Salesforce has said customers will be able to buy FDE services. However, Diginomica reported that Salesforce hadn't announced any timeline as of March 2026.
• Every vendor model feeds field learning back into a product. A services partner has no single product to feed, so what it learns tends to stay with the client.

What Stays the Same and What Changes Between Companies

Forward deployed engineering looks different at each company. The main differences are where the team sits in the organization and what engineers deploy. Two other key differences are who receives the service and how field findings feed back into the product.

What every model shares

Every version places an engineer inside a customer's real problem and holds that engineer accountable for the result. Palantir describes a Delta as part of a team dedicated to one customer. Ramp, by contrast, says its engineers own customer outcomes. Our guide to the forward deployed engineer role covers the basics.

The four variables

Four variables explain most of the differences between forward deployed engineer roles by the company. The same labels appear in each company section below.

• Org home. Which function owns the team: engineering, sales, or a separate group. That determines who sets its priorities and how teams measure its work.
• What is deployed. A platform the company owns, a set of model APIs, or the company's own product.
• Customer selection. Which customers get an embedded engineer, and on what terms.
• Feedback loop. How what engineers learn in the field reaches the people who build the product.

Together, these show whether the team focuses on serving customers, improving the product, or doing both.

Four Companies at a Glance

A comparison across the four companies shows how far one title can stretch. The table maps each company to the four variables above, plus team shape. Each fact comes from the dated source listed beneath it.

Sources: Palantir; The Pragmatic Engineer (August 2025); Ramp (August 2025); Salesforce (November 2025).

The biggest split is whether the team is tied to selling, to building product, or to both. Palantir places its Deltas in business development, while Ramp's FDEs sit in engineering and work closely with sales.

How Does Forward Deployed Engineering Work at Palantir?

Palantir calls its forward deployed engineers Deltas. Deltas work in teams dedicated to one customer. They deploy and customize Palantir's platforms to solve that customer's problems, and their success is measured by customer impact. Most other companies' versions of the role trace back to this one.

Where the role started

Palantir created the forward deployed engineer role in the early 2010s. Early Deltas mostly worked with government agencies. The name itself is a throwback. Palantir's engineering blog says each team in Business Development once took a letter of the NATO alphabet.

The scale is notable. Until 2016, Palantir employed more Deltas than software engineers.

Dev vs Delta

Palantir splits its two largest engineering roles into Devs and Deltas. Devs build the platforms, Palantir Foundry and Palantir Gotham. Deltas take those platforms to customers.

Palantir frames the difference as focus: a Dev works on one capability for many customers, while a Delta works on one customer with many capabilities. In Palantir's description, Deltas sit within Business Development and judge their work by its effect on the customer's goal.

Palantir also says a Delta is not a consultant. That distinction also affects how delivery is provided. For more details, see our comparison of forward deployed engineering and traditional consulting.

What changed after Foundry

Foundry, a data platform built for commercial and civil government customers, launched around 2016. From then on, more FDEs moved back into software engineering, bringing field experience into the core product.

The feedback loop is visible in Palantir's own writing. One Palantir engineer says the Foundry product Archetypes came from guidance Deltas gave the product team. They based this guidance on trends they saw in the field.

Everest Group describes Palantir as a product-first company with embedded field teams. According to their analyst, its services exist to drive product adoption instead of acting as the main revenue stream.

That structure explains why the model travels less easily than the title. Palantir's FDEs deploy a platform the company owns, and what they learn returns to the people who build it. The other three companies in this comparison adapt that arrangement, each in a different direction.

How Is the FDE Role at OpenAI Different from a Solutions Architect?

At OpenAI, solutions architects mostly advise and build proofs of concept, often on anonymized or offline data. Forward deployed engineers write code directly on customer infrastructure and work through more ambiguity. They also feed what they learn back into OpenAI's models and products.

FDE vs Solutions Architect at OpenAI

OpenAI kept its Solutions Architect role when it created a dedicated FDE team. The Pragmatic Engineer interviewed OpenAI's head of FDE, Colin Jarvis, in August 2025. According to that interview, solutions architects rarely write code on customers' infrastructure. FDEs do, using the customer's own tooling.

FDEs also choose their customers differently. They work with customers most likely to build solutions that advance OpenAI's research direction. The group started with two FDEs earlier in 2025 and had more than 10 by August across eight cities.

How a project runs

An OpenAI FDE project moves through three phases, as described by Jarvis in the same interview.

Scoping

A few days on site, mapping users' processes, identifying the most valuable areas, and prototyping with synthetic data.

Validation

The team tests whether the scoped work is the most valuable thing to build, then builds evals with user input and labeling. It ends with a report comparing eval results against agreed objectives. Jarvis says this step is necessary. This is because customers often describe their data and systems differently from how they actually work.

Delivery

FDEs spend a few days a week on site, aiming for the smallest unit that produces an end-to-end solution.

How field work reaches the product

The clearest example is a voice customer building call center automation. FDEs created evals showing the model did not yet perform well enough for the customer to commit. They took that data back to OpenAI's research team, and the work improved the model. The customer became the first to deploy the result, and the Realtime API improved as well.

Deadlines shape the work too. A John Deere project to scale personalized interventions for farmers had to be ready before the next growing season. The team delivered it on time.

What changed in 2026

On May 11, 2026, OpenAI launched the OpenAI Deployment Company. It is a standalone business unit that is majority-owned by OpenAI. The company launched with more than $4 billion in initial investment. OpenAI also agreed to acquire Tomoro, which would bring about 150 FDEs and deployment specialists into the new company.

How Does Ramp Structure Its Forward Deployed Engineers?

At Ramp, forward deployed engineering is part of the engineering organization. The team follows each enterprise customer from sales prospect through implementation to long-term support. It works in pods and builds features that ship in Ramp's core product. It grew from two engineers to 16 in about a year and a half.

Where FDE sits

Ramp's FDE team sits within the engineering organization. Its stated goal is to help the company move upmarket. Director of Engineering Leo Mehr explained this in a 2026 AI Engineer World's Fair talk.

The team began in fall 2023 with two engineers supporting Ramp's largest customers. Ramp's job postings describe an embedding model for FDEs. They work within core product engineering teams and collaborate closely with the sales team.

Ramp says covering the full customer lifecycle lets engineers start scoping early and stay accountable after a deal closes.

Pods and priorities

Ramp organizes FDEs into pods. The team's first priority was serving existing customers well. Next, it improved onboarding and activation. After that, it expanded product capabilities to reach a larger market.

Today, the team builds general-purpose features, platforms, and AI. These help Ramp reach product-market fit in the enterprise market faster. They also help Ramp expand into sectors like healthcare and government.

At the time of the talk, Mehr's organization included about 30 engineers across four areas. That number was not an FDE-only headcount.

Four operating principles

Ramp's post names four principles. Two of them pull against each other.

Always be scoping

FDEs question every requirement before building. In one case, the team found a feature gap that required about three days of engineering work. Instead of building it, they agreed on a workaround during a call with the customer.

Generalize the work

Ramp prefers building features that many customers can use. The company says one-off customizations add complexity and make the product harder to maintain. That conflicts with scoping.

Scoping says ship the smallest thing that solves this customer's problem. Generalizing says invest more for the many. Ramp says deciding between them is where an FDE's taste and skill matter.

The same trade-off appears in any embedded engagement. Teams build custom solutions quickly, but they still need to decide whether those solutions should become reusable. Scoping before building is also the premise of structured solution discovery.

Do more

Speed and ownership, tied to one of Ramp's company values.

Win when customers win

Team metrics link to customer and business outcomes.

Ramp hires for drive, engineering fundamentals, customer empathy, and communication, and 7 of its 16 FDEs were previously founders.

How Does Salesforce Run Forward Deployed Engineering Around Agentforce?

Salesforce runs forward deployed engineering as a dedicated team built around its Agentforce platform. FDEs work alone or in small pods, help customers deploy agents, and pass field findings back to product teams. As of early 2026, access was by invitation, with a paid option discussed but not scheduled.

Scope and scale

Salesforce launched its FDE team in April 2025 and says it has committed to building a team of 1,000 FDEs. In March 2026, Diginomica reported that Salesforce did not disclose exact headcount figures.

Salesforce says FDEs and its implementation partners play different roles. Partners still handle much of the detailed implementation work. FDEs contribute Salesforce product knowledge that partners may not have. Jennifer Cramer, who leads the function, places the team between product and services.

Team shape

Many FDEs work individually with a customer. Some work in pods of one deployment strategist and two FDEs. The strategist identifies the best use case and shapes the AI strategy, and the FDEs design, build, and deploy the agent.

A pod focuses full-time on one client for about three months. If needed, it stays longer until it deploys an agent for one or two use cases. Cramer says the aim is for customers to finish with the skills to take the work forward themselves.

For what these deployments involve, see our agentic AI enterprise implementation guide.

Feedback to product

Early FDE customers asked for more ways to measure their agents' performance. FDEs passed that request to product and engineering, and Salesforce developed Agentforce Observability. Customers also wanted to know how agents reached their answers, which led to session-data tracing.

Cramer says the team can reuse work created for one customer. It gives the core build back to the product team without the customer's proprietary data or code. The product team can then incorporate it into the product.

Commercial model

Salesforce's latest announcement said an account executive must nominate customers to join the Momentum program. The program was free for selected customers. Salesforce described it as an investment in those customers. It added that customers would be able to buy FDE services sometime in the following year.

Salesforce is also extending the model through partners. Around 80 firms are already Salesforce FDE partners.

For buyers, the practical point is that Salesforce's FDEs exist to make Agentforce deployments succeed. Their scope follows the platform.

What the 2026 Wave of Deployment Arms Adds

Between May and July 2026, four AI vendors each announced a dedicated forward deployed engineering organization. Delivery capacity is becoming something vendors fund and sell directly, not only something their integration partners provide.

• Anthropic, May 4, 2026: A new AI services company formed with Blackstone, Hellman & Friedman, and Goldman Sachs. Anthropic Applied AI engineers work alongside the firm's own engineers, and it targets mid-sized companies.
• OpenAI, May 11, 2026: The OpenAI Deployment Company launched with more than $4 billion in initial investment.
• AWS, June 30, 2026: An initial $1 billion commitment, with pods of five to six engineers placed with customers for 45-day periods.
• Microsoft, July 2, 2026: The Microsoft Frontier Company launched with a $2.5 billion budget. It started with about 6,000 engineers and salespeople, according to Directions on Microsoft.

The structures differ. Microsoft's unit has its own leadership and financial accountability but is not a separate legal entity. Anthropic says its team extends the capacity of its systems integrator partners. This is especially useful for mid-sized companies that lack the in-house resources to run deployments.

For buyers, the choice now includes vendor-run FDE teams alongside partner-delivered ones.

What Enterprise Buyers Can Take from These Models

The following are key takeaways for enterprise buyers considering FDE-style delivery for their AI or integration program.

Vendor-run FDEs and partner-run FDEs

The four companies above are vendors. Their FDEs deploy the vendor's own platform, and what they learn returns to the vendor's product. A services partner has no single product to feed. It often works across the systems a buyer already runs, so the learning tends to stay with the buyer.

Neither model is better by default. A vendor team fits when the goal is adopting that vendor's platform. A partner fits when the program spans several systems.

Questions to ask before an FDE-style engagement

Four questions bring most of the differences above into focus:

1. Where does the team sit? Engineering, sales, or services determines whose priorities it serves.
2. Who owns the custom work? Ramp builds general features into its core product. Salesforce says it can send reusable builds back to its product team. Ask what happens to what is built for you.
3. Who owns the IP developed during the engagement?
4. How do findings return to whoever builds the platform?

Where critics see risk

A July 2026 Forbes analysis interviewed two executives whose companies compete with Palantir in enterprise software. Anaplan CEO Charlie Gottdiener says FDEs work well for fast proofs of concept. However, customers may end up paying them indefinitely to modify and operate the system. He expects the approach to run its course.

Manik Sharma, a former Palantir executive now at Kinaxis, sees the weak point as engineers who lack domain knowledge. Kinaxis, which offers its own version of FDE, says it staffs teams with domain, industry, and technical expertise. Both have a commercial interest in the argument.

The two critiques point to the same tests. Ask what happens after the first deployment, and who understands the business well enough to run the solution the team built.

Where Dynamisch Fits

Dynamisch's practice sits closer to the partner-run model described above. Its forward deployed engineers work inside a client's existing systems and production environment. We measure success by what reaches production and what users adopt.

Engagements begin with discovery inside the client's environment, followed by embedded development and incremental production deployment. Current work includes agentic AI implementation, code modernization, MCP tooling, and large-scale data migrations. Dynamisch's VP of Technology, Pritish Zade, and Technical Lead, Arpit Singh, lead this FDE practice.

To see how these models compare in more depth, explore our forward deployed engineering insights.