Kevin Bai on FDE: Who Delivers the Outcome After the Platform Sale?

Original source: Forward Deployed Engineering 101

Channel: AI Engineer. Event: AI Engineer World's Fair 2026. Speaker: Kevin Bai, a Member of Technical Staff on Anthropic's Applied AI team at the time of the talk. YouTube publication date: 2026-07-28. Duration: 00:17:48.

This article draws on the video's automatic English captions, with names and context checked against the organizer's talk page. Commercial figures and industry judgments remain attributed to the speaker.

An enterprise buys a technical platform, connects its data, and acquires a substantial collection of tools. Its employees still need to work out what to build. The purchase leaves an engineering gap between available capabilities and a useful business outcome.

Kevin Bai uses that gap to explain Forward Deployed Engineering, or FDE. Engineers work closely with customers, learn their business, and build useful applications and workflows on their employer's platform.

Bai previously worked at Palantir and became Rippling's first FDE hire. In the talk, he recalls that team growing to around 25 people in about a year, a trajectory also described in his personal biography. He now works on Anthropic's Applied AI team, although this presentation addresses the general FDE model.

His central argument concerns what happens after the first successful engagement. FDE has a chance to scale when customer delivery rests on a reusable platform. Each additional customer also leaves behind software that someone must keep working.

The engineering work that remains after a purchase

Bai begins with Palantir Foundry: organize data around a business, then enable applications to be built on it.

His warehouse example gives the idea a concrete shape. A company needs a shared understanding of its warehouses and the data associated with them before it can build useful workflows. Palantir's Ontology documentation describes objects, properties, relationships, and actions. That is a common language for business entities and operations, extending beyond a collection of tidier tables.

Yet organizing data does not automatically improve a customer's business.

A consumer packaged goods executive cares about shelf placement and sales throughput. Data organization supports those goals. When a vendor supplies a platform alone, the customer must still train people, learn the tools, and arrange development before realizing much value.

FDE takes responsibility for part of that work. Engineers learn the customer's problem and use the platform to build a solution that connects software capabilities with business results.

Bai's description of customers buying outcomes explains the delivery model. The talk does not specify outcome-based billing terms or guarantee an improvement in a particular business metric.

Can the buyer put the product to work?

In Bai's analysis of buyers and products, technical complexity is only one variable. The other is who must absorb it.

GitHub and Datadog can be sophisticated products, but their technical leaders and engineering users generally have the skills to work with them. Learning technical tools is part of their job.

He places Rippling, Jira, and Slack in a different common buying situation: customers primarily configure existing capabilities. The products may still be complex, but typical users need not develop an application from scratch before getting started. His distinction concerns adoption, without implying that these products lack APIs or extensions.

FDE addresses a mismatch between the two sides: the vendor sells a technical platform requiring further development, while the buyer lacks the capacity to do that development.

Bai contrasts the engineering depth of Google, Meta, and model labs with what an enterprise in oil and gas might have available. A rich platform does not establish that every customer can make effective use of it unaided.

The vendor therefore provides engineers who know the platform and work through the customer's problem. Adopting the software no longer requires the customer to shoulder all the work of recruiting, training, and retaining those engineers itself.

Large contracts also leave a maintenance bill

Bai offers a comparison of contract values to illustrate the commercial scale this delivery model can support.

He explicitly defines ACV here as average contract value and cites these figures:

• Palantir: about four million US dollars.
• ServiceNow: about one point two million US dollars.
• Workday: about six hundred thousand US dollars.

He also says that no other public SaaS company clears five hundred thousand US dollars.

The qualifications belong alongside the figures. His Palantir number refers to the last time he checked, and he expresses uncertainty when recalling Workday's. The talk supplies no statistical date, sample, or comparable methodology. These are figures cited on stage, not a verified current market ranking, annualized revenue figures, or evidence that FDE alone caused the differences.

The operating question is what each contract leaves behind for engineering to maintain.

Bai describes FDE as extending design partnerships to enterprise scale. Early startups often work closely with customers to discover a useful product: the customer contributes business context, and the startup contributes engineering and technology.

That relationship produces detailed customer knowledge. Building a new system from scratch for every engagement, however, also produces different codebases, requirements, and failure modes for the team to support.

His answer is a shared platform. Engineers combine existing capabilities into the applications and workflows a customer needs. Common foundations carry the reusable work, while delivery teams handle the differences between businesses.

Reuse reduces repeated construction; maintenance remains an obligation. Bai emphasizes that even a robust platform leaves substantial ongoing work around customer systems.

Two questions before starting an FDE team

Bai proposes two adoption tests for a company considering the model.

First, does the business actually require selling technically complex software to a nontechnical buyer?

A technically capable audience may be better served by developer relations and developer engagement. An established, configurable SaaS product may fit a conventional sales-led approach. Interest in FDE does not establish that it solves the customer's adoption problem.

Second, does the company have a platform, or is it willing to invest in building one?

An engineering team that directly brings in revenue is appealing. If every engagement begins from scratch, that revenue continually creates new maintenance obligations. Shared foundations give the work a way to accumulate into something reusable.

The platform need not cover every use case before customer work begins. In the later questions, Bai allows a more limited starting point: a small set of capabilities can grow as field work reveals what should be built next.

The commitment is to fund both customer delivery and platform development.

The right building blocks depend on customer differences

An audience member asks how granular the shared capabilities should be. Should they resemble database infrastructure or something close to a finished application?

Bai offers no universal level of abstraction. In some industries, he suggests, an application might be 60% complete before the customer customizes the remaining 40%. Other use cases require much finer tools and configuration.

The 60% and 40% figures illustrate variation. They are not a prescribed platform reuse target.

AWS supplies his example of shared foundations. Engineers can use a database service such as DynamoDB and concentrate on the application above it. Relatively general building blocks make sense when a platform serves a wide range of customer needs.

A narrower business setting may let a platform provide more of the application in advance. The useful boundary depends on the customer base and how much its requirements differ.

Getting field experience back into the product

Asked about the boundary between FDE and platform engineering, Bai gives a direction: a requirement unique to one customer can stay in that customer's solution; a generalizable capability should move into the shared platform over time.

The time horizon matters. A customer request does not automatically justify an immediate addition to the core product. Field work also helps discover which problems deserve repeated investment and which new capabilities could make the platform more useful.

Knowledge sharing within delivery matters too. In the discussion of collaboration, Bai initially understands the question as asking about several FDEs working on the same project. He favors that arrangement because a customer system becomes fragile when only one person knows how it works. A vacation can leave everyone else unable to take over.

The questioner then clarifies that the teams come from different companies. Bai shifts to a contractor or partner model: the parties need to establish their working relationship and who occupies the contractor role. He does not prescribe a complete process for collaboration across companies.

His final hiring criterion is straightforward. An FDE should meet the team's standard for a software engineering hire and also be someone the company trusts in front of a customer.

Engineering ability and the ability to work with customers must be present in the same person.

Easier code generation leaves delivery work to do

In his discussion of AI, Bai presents a personal hypothesis: software is becoming easier to generate and customize, changing how it is sold and delivered.

Agent products are emerging for fields such as insurance and law. More configurable capabilities confront vendors with a familiar practical question: does the customer know how to put them to work inside its business?

Leaving product success entirely to the customer's implementation skills can make it difficult to serve larger accounts or expand into more industries. That is Bai's interpretation of the market, and it does not establish that every AI company needs FDE.

Taken together, his advice locates the continuing work: understand the business problem, build a usable system, make it maintainable by the team, and turn recurring requirements into shared capabilities.

Even when code is generated faster, someone must remain responsible for helping customers use the software successfully over time.