Palantir FDE Handoff: What to Have in Hand Before the Forward Deployed Engineers Leave

Palantir's forward deployed engineers (FDEs) embed with your team, build the first pipelines, ontology, and applications on your data, and then roll off. Before they leave, you need seven things in hand: ownership of the ontology and pipelines held by your own groups, documentation a new engineer can work from, access granted to groups instead of individuals, runbooks for the failures that will recur, cost limits set in Resource Management, a named platform team, and a release process that routes every change through a branch and a review. If any of the seven lives only in an FDE's head or user account, the handoff is unfinished, and the first incident after roll-off will show you which item is missing.

What does the Palantir FDE model leave behind?

Palantir's own filings explain why its engineers sit inside customer teams. Its 10-K for fiscal 2024 says Palantir needs to learn customers' problems firsthand and states, "To do so, we embed with our users." The same filing's risk factors note that proper use of its platforms can require customer training and "the initial or ongoing services of our technical personnel as well as O&M services over the contract term." It also says Palantir introduced AIP bootcamps during 2023, which "allow us to deliver real workflows on actual customer data in days." The Palantir FDE model produces speed: a working use case in weeks, built by engineers who know the platform better than anyone on your payroll.

The cost of that speed arrives later. FDEs write the transforms, design the object types, configure the Workshop applications, and hold the context for why each choice was made. When the services phase of the contract ends, that context leaves with them unless someone wrote it down and transferred it. Read your order form before roll-off and confirm three things: how long ongoing technical services continue, what Palantir's operations and maintenance commitment covers, and who on your side fixes a pipeline that one of Palantir's engineers wrote. Our explainer on what a forward deployed engineer does covers the role itself. This article covers the exit.

The FDE handoff checklist

The table lists each item, what "in hand" means in practice, and where your team can verify it inside Foundry. Run it while the FDEs are still on site, because every gap is cheaper to close while the person who built the resource can answer questions about it.

Who owns the ontology and pipelines after the FDEs leave?

Ownership in Foundry follows Projects. Palantir's documentation calls Projects "the central security boundary in Foundry" and lists four default roles, from most to least powerful: Owner, Editor, Viewer, and Discoverer. Check who holds Owner on each production Project before roll-off. A Project whose only Owner grant sits on an individual FDE account has no owner on your side the day that person moves to another customer.

Palantir recommends "granting group roles at the project level," and the handoff is the right moment to enforce it. Transfer Owner to a group your company controls, such as a platform team group managed in your identity provider, and reduce FDE accounts to Viewer for the transition window before removing them. Group grants survive staff turnover on both sides, and they turn an access review into a reading of group membership in one place. Apply the same discipline to the Palantir ontology. Every object type and action type needs a named steward on your team who approves changes to its properties, links, and the actions that write to it, because an action type is where an application or an agent changes your operational data.

What should the documentation and runbooks cover?

Documentation for a Foundry build answers the questions an engineer asks at 2 a.m. For each pipeline, record the source systems, the schedule, the expected volume, the health checks, and the object types it feeds. For each object type, record the backing datasets, the primary key, and the actions that modify it. For each application, record its users, the decisions it supports, and the actions it exposes. The FDEs know all of this today, so ask them to write it while they still have the context, and have one of your engineers check each page against the running system.

Runbooks cover the failures that recur. Start with five that any production Foundry deployment should expect: a source system that changes its schema, a scheduled build that fails, an object type that stops updating, an access request that needs a decision, and a compute spike. Each runbook names the alert that fires, the person who responds, and the first three checks to make. Foundry's monitoring views can send alerts by email, through Foundry notifications, or to external systems such as PagerDuty and Slack, so route them to the on-call channel your team already uses for its other production systems.

How do you keep compute costs in line after go-live?

Foundry charges for the work the platform does, and a build team working against a deadline rarely tunes for it. Palantir's Resource Management application shows shared compute usage, its cost, and billing, and it accrues each resource's usage to its parent Project. Each Project belongs to a usage account, and administrators can define how Projects consume shared resources and place limits on that consumption. The application also includes budgets, monitors, resource queues, and anomaly detection.

Before roll-off, map every production Project to a usage account owned by a business line, set limits with headroom above the last 60 days of actual usage, and assign one person to review the top Projects by cost every month. Then inspect three settings that a build team chooses for speed: schedules that run hourly when the consumer reads the output once a day, transforms that recompute full history when an incremental build would do, and interactive analyses that recompute every time a user changes a parameter. Each is a configuration change, and each belongs in the first month of the run phase. Our article on what Palantir costs covers the license side of the same budget.

Who belongs on the platform team?

A platform team is the group of named people who run, extend, and govern the build after the FDEs leave. Staff it by role: data engineers who own source connections and pipelines, application developers who own Workshop applications and the logic on ontology objects, an AI engineer if AIP workflows are in production, and an administrator who manages the enrollment, groups, markings, and usage limits. Add a platform owner on the business side who holds the budget and decides which use case comes next.

The BD Emerson planning range for a team running one to three production use cases is three to five people, with at least one person per role able to take an on-call shift. Name those people inside Foundry as well as on the org chart. Palantir's Upgrade Assistant "provides visibility on upcoming platform changes," assigns each affected resource to users and groups, and sends reminders as an upgrade deadline approaches so the assignee can "take the actions required to prevent workflow disruption." If the assignee on a production resource is an FDE who has moved on, that reminder reaches someone who no longer works on your platform.

What does a release process look like in Foundry?

A release process is the rule that nobody edits production directly. Foundry's Global Branching lets a team "develop and test end-to-end workflows" and modify multiple applications on a single branch, with a review "governed by each resource's approval policies" before the change merges into main. A change to a pipeline output and the object type it backs can travel together on one branch, get tested together, and merge together, which closes the gap where an upstream change breaks an application that nobody tested downstream.

Set the approval policies before roll-off. Require a second reviewer from the platform team for ontology changes, require the ontology steward's approval for anything that changes how an action writes data, and keep a short release log so an auditor or a new engineer can see what changed and when. Palantir's documentation describes branching and release management as complementary, so programs that package work for several environments also need a release path for those packages.

How do you know the handoff worked?

Run a 30-day test after the FDEs step back. In that window, your team should ship at least one change through the release process without help, resolve at least one alert from a runbook, complete one access review from group membership, and explain the top three drivers of the month's compute cost from Resource Management. If any of those steps needs a call to someone who has left, add it to the checklist and close it before the transition window ends. A team that passes all four can extend the build on its own schedule.

BD Emerson is an independent Palantir implementation consultancy. We are not Palantir, we sell no Palantir licenses, and our advice carries no license quota. When Palantir's FDEs roll off, our engineers take over operation, extension, and governance of the Foundry or AIP build, run this checklist with the outgoing team, and serve as your platform team or alongside it while your own people take over. Our Palantir managed services page describes how those engagements start.