Inside the Palantir Embed: How FDEs Operate on Customer Sites

You don't just build for the customer. You build inside the customer. That is the fundamental distinction between a standard Solutions Architect and a Palantir Forward Deployed Software Engineer (FDSE).

While most enterprise software companies deploy a product and run, Palantir deploys a human. That human—the FDSE—is given a badge, a desk inside a SCIF or a government building, and a mandate: make the platform indispensable within 90 days, or the contract is at risk.

Let's pull back the curtain on the day-to-day reality. This isn't the sanitized recruiting pitch. This is the workflow, the code, and the specific pressure points that define the role.

The Embed Model: Why Palantir Puts Engineers on the Inside

Palantir sells an ontology—a semantic layer that maps the real world (people, planes, supply chains) into digital objects. The problem is that no customer knows what their ontology looks like on day one. If you leave the customer alone with a blank Foundry or Gotham instance, they will fail. The software is too abstract.

The solution is the "embed." An FDSE sits physically next to the analyst or the logistics officer. By sharing the same air, the FDSE absorbs the domain context through osmosis. You learn their acronyms. You understand why a specific Excel spreadsheet is "the source of truth" even though it has 47 tabs and no consistent schema.

This is not a remote-friendly role, historically. For a deeper look at the logistics of this lifestyle, see our breakdown on On-Site vs Remote FDE Work and Travel Realities.

Morning: The Standup That Isn't a Standup

Your day starts at 0800, but you aren't logging into Zoom. You are walking to the "Watch Floor" or the operations center. Your "standup" is a conversation with a Lieutenant Colonel or a Supply Chain Director who has zero interest in Agile ceremonies.

The Scenario: The customer has a high-priority target (in a defense context) or a critical shipment delay (in a commercial context). They need a dashboard that fuses three data sources that have never been joined before.

The Workflow:

1. The Ask: "Show me every vessel that left Port A in the last 48 hours and cross-reference it with our internal denied-party list."
2. The Immediate Triage: You open a Jupyter notebook inside Foundry (a tool called Code Workbook). You don't open VS Code locally. Everything runs on the customer's cloud or on-prem infrastructure.
3. The Skeleton Script: You write a PySpark transform immediately.

# Immediate triage: joining AIS vessel data with an internal watchlist
# This is dirty code written live with a user watching.
from pyspark.sql import functions as F

def join_vessels_watchlist(vessel_df, watchlist_df):
    # The customer tells you the join key is the 'hull_number',
    # but you discover it's called 'hull_id' in the vessel data.
    return vessel_df.join(
        watchlist_df,
        vessel_df.hull_id == watchlist_df.hull_number,
        "inner"
    ).select(
        vessel_df.mmsi,
        vessel_df.lat,
        vessel_df.lon,
        watchlist_df.risk_type
    )

You run the transform in 60 seconds. The data appears as a map layer. The customer says, "That's 80% of what I need. Can you color the dots by risk type?" You do it live. This is the "Delta" feedback loop.

Midday: The "Dirty Hacking" Window

The customer goes to lunch. You don't. The next two hours are your engineering window. You refactor the morning's duct tape into a pipeline that won't break at 2 a.m.

The Deep Work:

• Ontology Mapping: You define the object types in the ontology editor. Vessel, Port, Watchlist Entry. You link them with properties.
• Pipeline Building: You chain transforms. The morning script was a single node. Now you build a proper DAG (Directed Acyclic Graph) that handles incremental updates, not just a full snapshot.
• Error Handling: The vessel data feed is notoriously flaky. You write a try/except that catches the exact AnalysisException thrown when the upstream file is empty and gracefully writes an empty dataset to prevent the dashboard from crashing.

This is where the "Forward Deployed" part of the title bites. You are not just a consultant telling them what to do. You are the engineer writing the production code. Palantir's internal culture divides these responsibilities. For a look at how the company distinguishes between core product engineers and embedded engineers, the internal "Dev versus Delta" dynamic is critical. While we focus on the FDSE execution here, understanding the hand-off to core engineering is essential (see our guide on How FDEs Work with Product and Engineering After the Sale Closes).

Afternoon: The Ontology Mismatch and the Data Refusal

At 1400, you demo the refactored pipeline. The user is happy with the map. But then a senior analyst walks in and says, "This is wrong. A vessel isn't just a vessel. It has a beneficial owner. And the owner is the target, not the steel hull."

This is the critical moment. The customer's mental model ("we track ships") clashes with the data reality ("we track organizations that own ships").

You don't argue. You open the Ontology Manager. You create a new object type: Organization. You create a new property: Vessel.owned_by -> Organization. You re-wire the pipeline to ingest the ownership data from a completely separate, previously ignored CSV file that the analyst just remembered exists.

The Code Reality: You write a transform that parses a poorly formatted CSV where dates are in MM/DD/YYYY format and the owner names have trailing whitespace.

# The real world is messy. The "ignored" CSV has no schema.
raw_df = spark.read.option("header", "true").csv("/mnt/legacy/owners_export.csv")

cleaned_df = raw_df.select(
    F.trim(F.col("Owner Name")).alias("org_name"),
    F.to_date(F.col("Acquisition Date"), "MM/dd/yyyy").alias("acq_date")
)

You link this to the vessels. The map changes. The dots now represent the risk of the owner, not the ship. The analyst nods. You just saved the engagement.

Evening: The "Delta" Hand-off and the Code Freeze

By 1700, the dashboard is live. But your job isn't done. You write a "Standard Operating Procedure" (SOP) document in Confluence (or the customer's wiki) explaining how to refresh the data. You don't write it for yourself; you write it for the junior analyst who will take over when you rotate off the embed.

You commit your code to the customer's repository. You lock the production branch. You fly back on Friday.

The Compensation Reality: This lifestyle commands a premium. Palantir compensates for the travel grind and the security clearance requirements. While exact numbers vary by level, a mid-level FDSE can expect total compensation (base + equity + bonus) that competes aggressively with FAANG, often with a heavier weighting on stock. For those evaluating the financial viability, the salary structure is a frequent topic of discussion (we break down the latest ranges in our Forward Deployed Engineer Course Cost Breakdown).

Compensation and Career Velocity

The "Delta" title (internal Palantir lingo for FDSE) is not just a job; it's a career accelerator. You see the raw, unfiltered guts of the economy or government operations. The exit opportunities are not "Senior SWE at Google." They are "Head of Engineering at a logistics startup" or "CTO of a defense tech company." You leave with a security clearance, a network of government buyers, and a zero-tolerance policy for BS architecture.

The work-life balance is the obvious trade-off. Travel is often 50-75% (Monday to Thursday on-site). You live out of a suitcase. You lose weekends to production incidents. But you also compress a decade of enterprise experience into three years.

FAQ

What is an FDSE at Palantir? A Forward Deployed Software Engineer is an embedded engineer who works physically at the customer's site. They bridge the gap between the customer's operational problems and Palantir's software platforms (Foundry/Gotham) by writing production code, building data pipelines, and configuring ontologies live.

How is the work-life balance at Palantir Technologies? For FDSEs, it is intense. Expect heavy travel (often 4 days a week on-site) and high-pressure environments where the software directly impacts critical missions. The balance improves if you transfer to a "Dev" (core product) role, but the FDSE path is known for high burnout and high reward.

Does Palantir pay well? Yes. Total compensation is competitive with top-tier tech companies, heavily supplemented by equity. The premium reflects the in-person demands, travel requirements, and the frequent need for security clearances.

What is a Delta at Palantir? "Delta" is the internal Palantir title for an FDSE. The term originates from the Greek letter commonly used in math and science to represent change. It signifies that the engineer is deployed to enact change directly on the front lines, as opposed to staying at headquarters.

What skills do I need to survive the embed? You need strong Python/SQL skills, a high tolerance for ambiguity, and the social intelligence to push back on a General when their data request is technically impossible without burning the bridge. You cannot hide behind a Jira ticket.