Forward Deployed Engineer: What the Job Actually Is

An account manager on one of our client pods kept her real workflow in three places: a spreadsheet of deliverables, a WhatsApp thread where the deadlines actually moved, and her own memory of which client hated which phrasing. No specification written in a meeting room would have captured the third one. That gap, between the workflow a document describes and the workflow a person performs, is the entire reason the forward deployed engineer role exists.

#Where the title comes from

Palantir invented the label and still says so on its careers page, which is headed "The Original Forward Deployed Software Engineer" and describes embedding engineers directly with customers. The more interesting source is not the job ad, it is the first annual report. Palantir put the role in a legally filed 10-K:

Our forward deployed engineers (“FDEs”) have travelled to bases in Afghanistan and factories in the industrial Midwest to deploy our platforms. Time in the field adds to the continuous improvement of our platforms. As FDEs help customers make the most of our software, they observe users’ challenges firsthand.

Palantir Technologies Inc., Form 10-K for FY2020 (SEC EDGAR)

The same filing lists the ability of forward deployed engineers to help customers identify new use cases as a risk factor governing revenue expansion. That is the part people miss. Palantir told its investors that growth depends on engineers who are physically close enough to a workflow to notice the next problem. It is a structural claim about how software gets adopted, not a recruiting slogan.

The current postings say the same thing in operational language. OpenAI's San Francisco listing gives the FDE ownership of "discovery, technical scoping, system design, build, and production rollout" and says success is measured through "production adoption, measurable workflow impact, and eval-driven feedback that changes product and model roadmaps." Anthropic's listing asks the FDE to "Work within customer systems to build production applications with Claude models" and to ship artifacts like MCP servers, sub-agents and agent skills that end up in real workflows. Both make the same commitment: the measure of the job is whether people use the thing, not whether it was delivered.

#Why the role exists at all

The failure numbers are the argument. They have been stubbornly bad across several independent measurements, and they all point at the same cause.

Treat those with the care they deserve. RAND presents the 80% as an estimate it cites rather than one it measured, and the MIT NANDA figure is contested and comes to us through Fortune because the report itself is no longer publicly downloadable. The 451 Research number is the most defensible of the four, and it cuts against the doom framing: abandonment before production fell from 31% to 24% in a single year, across 704 IT decision-makers in the US, UK and India. Gartner has now made the same prediction twice in two forecast cycles, at least 30% of generative AI projects abandoned after proof of concept by the end of 2025, then over 40% of agentic projects canceled by the end of 2027.

RAND's own research is where the argument gets sharp. Its number one root cause of AI project failure is that stakeholders misunderstand or miscommunicate what problem needs to be solved, so models get shipped that were "optimized for the wrong metrics or do not fit into the overall business workflow and context." RAND's first recommendation is to make sure technical staff understand the project purpose and domain context. Its second is to commit a product team to one specific problem for at least a year. A neutral institution with no product to sell arrived at a description of the forward deployed model, from failure data.

#The difference from a product engineer, and from a consultant

A product engineer usually receives a problem that has already been through a filter: research, a PRD, a design review, a prioritization call. That filter is useful at scale, and it is also where domain context gets lost. By the time the ticket reaches the engineer, the client who hated the phrasing has become a checkbox called "tone preference."

A consultant sits closer to the domain but stops at the boundary of the codebase. The deliverable is a recommendation, a process map, sometimes a prototype, and then the engagement ends. First Round Review draws exactly this line: unlike a solutions consultant or a sales engineer, the FDE is still an engineer who writes and debugs production code. Being in the room is table stakes. Merging to main is the difference.

What that means day to day:

• The requirement is an observation, not a document. I watch someone do the task, then write the migration.
• The unit of shipping is days, not sprints. A wrong guess costs three days, so guessing is cheap and asking is cheaper.
• I own it afterwards. The person who complained about the feature sits two desks away and will find me.
• The roadmap is a byproduct. Half of what we built in the last year came from watching a workaround, not from a planning cycle.

#What the work actually looks like

Two examples from Opaeron, the internal operations platform I build for Trilliant Digital, a digital marketing agency. Both are decisions that came out of sitting with the teams rather than from a design doc.

The first is authorization. The agency has two overlapping org shapes: client pods (Beacons, Dyota, Elites, Nexus) that own accounts end to end, and practice pods (Maverick for social, Ajna for paid, Alpha for SEO) that cut across every account. Nobody could give me a rule for who sees what, because the rule changed with each new account. So the matrix became data, editable live by a super admin and stored in tdx_app_settings, and every query runs through one module. We self-host PostgreSQL 16 with no Row Level Security, so this function is the only gate that exists:

from fastapi import HTTPException

def visible_account_ids(user, matrix):
    """Resolve which tdx_accounts rows this user may read.

    There is no RLS on our self-hosted Postgres, so this is the only
    authorization gate. Returning None means "no filter" (super admin).
    """
    if user.role == "super_admin" and not user.view_as:
        return None

    effective = user.view_as or user          # View-As mode, fully audited
    ids = set()

    if effective.client_pod:                  # Beacons | Dyota | Elites | Nexus
        ids |= matrix.accounts_for_client_pod(effective.client_pod)
    for practice in effective.practice_pods:  # Maverick | Ajna | Alpha
        ids |= matrix.accounts_for_practice(practice)

    return ids


def scoped(table: str, user, matrix):
    """Every account-scoped read starts here, never with db.table() directly."""
    q = db.table(table).select("*")
    ids = visible_account_ids(user, matrix)
    if ids is None:
        return q
    if not ids:
        raise HTTPException(status_code=403, detail="No account access")
    return q.in_("account_id", sorted(ids))

A product engineer given "build permissions" would reasonably have shipped roles and a static mapping. What the workflow actually needed was a matrix that operations could edit at 6pm on a Friday when an account moved pods, plus a View-As mode so a lead could see the app exactly as her team sees it, plus an audit log because the first question after any permission change is who changed it.

The second example is smaller and came from a single sentence in a review meeting: "this does not sound like us." Opaeron generates briefs, ad copy, meeting summaries and client updates through OpenRouter, mostlygoogle/gemini-2.5-flash for chat and briefs, google/gemini-2.5-flash-lite for cheap classification, and anthropic/claude-haiku-4.5 for pulling tasks out of meeting transcripts. Every model has a house style, and none of them is the agency's. Rather than fight it prompt by prompt across 20 agents, I put one module at the exit:

import re

# Model tics we rewrite rather than re-prompt for, across all 20 agents.
_CLICHES = [
    (re.compile(r"\bleverag(e|es|ed|ing)\b", re.I), "use"),
    (re.compile(r"\bseamless(ly)?\b", re.I), ""),
    (re.compile(r"\bcutting[- ]edge\b", re.I), "current"),
    (re.compile(r"\bin the ever[- ]evolving landscape of\b", re.I), "in"),
]

# Long dashes are the loudest tell that a human did not write the line.
_DASHES = re.compile(r"\s*[\u2014\u2013]\s*")


def clean(text: str) -> str:
    for pattern, repl in _CLICHES:
        text = pattern.sub(repl, text)
    text = _DASHES.sub(", ", text)
    return re.sub(r"\s{2,}", " ", text).strip()


async def generate(model: str, messages: list[dict]) -> str:
    resp = await openrouter.chat(model=model, messages=messages)
    return clean(resp.choices[0].message.content)   # single exit point

Thirty lines, one afternoon, and it fixed the single most common complaint about the AI features. It would never have survived a prioritization meeting. It survived because I heard the sentence.

#What a year of this produces

These are counts I ran against the Opaeron repository today, not estimates. About a year of forward deployed work, one engineer, one agency: 226,000 lines of code, 121,931 of them Python across 541 files and 104,083 frontend across 465 files. 711 API route handlers registered across 89 routers. 77 Postgres tables, all prefixed tdx_. 274 React page files, 52 shared components, 158 test files, 32 backend feature modules. 112 agent module files across 11 marketing disciplines (seo, smm, abm, email, cro, paidads, content, brand, analytics, ops, website), which surface as roughly 20 user-facing AI agents.

The stack is deliberately boring where it can be: FastAPI and Uvicorn on Python 3.11 with Pydantic v2, React 19 with Vite 7 and Tailwind CSS v4, Celery and Redis for the scheduled work (deadline reminders every 15 minutes, nightly recurrence regeneration, a nightly Postgres to Google Sheets backup, daily ads sync, weekly telemetry pruning), a multi-stage Dockerfile that builds the React bundle and hands it to FastAPI to serve, shipped by GitHub Actions on push to main. Transactional email goes through the Resend HTTPS API because the droplet blocks outbound SMTP, which is the kind of constraint you find on day two and design around forever.

The choices that look strange from outside are the forward deployed ones. We migrated off Supabase to self-hosted PostgreSQL 16 on 2026-07-02, and rather than adopt an ORM I wrote a Supabase-style query builder shim over psycopg3 with a connection pool, so several hundred existing route handlers did not need rewriting. Purity would have cost weeks of migration that produced nothing a user could see. Separately, the client-facing portal at clients.opaeron.com is a deliberately different system from the internal app: opaque SHA-256 session tokens instead of JWTs, HttpOnly cookies with no Domain attribute, fail-closed on every endpoint, and the account id read only from the server-side session row, never from a URL parameter. Internal staff and external clients have different threat models, so they got different auth.

#The market for the role

The title stopped being Palantir-specific during 2025. Monthly job listings for the role grew 800% between January and September 2025, per Financial Times data cited by First Round Review. I counted the current postings myself against both companies' public job board APIs on 16 August 2026: 74 of Palantir's 308 open postings, 24% of everything they are hiring for, carry "Forward Deployed" in the title, now including AI, infrastructure, reliability and security variants across 21 locations, led by Washington D.C., New York and London. OpenAI lists 21 of 746 open roles, spread across ten cities on four continents with vertical specialisations for healthcare, life sciences and government. This is being built as a global function, not a US pilot.

The spread is worth reading carefully. Palantir will take someone one year out of college, which tells you they believe the skill is trainable in the field. Anthropic posts the narrowest and highest band and describes these as founding FDEs shaping the motion, which tells you the shape of the job is still being decided. Everyone expects you on a plane or in a client office, though all three cap it rather than mandate it: Palantir asks for the ability to travel up to 25% and calls it flexible, Anthropic estimates around 25% depending on location, and OpenAI requires up to 50%.

#Practical takeaway

If you are considering the role, the honest test is whether you are comfortable being wrong in public and fixing it the same week. The failure data says the binding constraint on enterprise software is almost never model quality or framework choice, it is whether anyone understood the workflow well enough to build the right thing. RAND says commit a team to one problem for at least a year. That is roughly what Opaeron cost, and it is why it is 226,000 lines instead of a pilot.

Four things that carried over from Samsung R&D and CrewAI pipelines into this job:

• Watch the workaround. Every spreadsheet someone maintains by hand is a feature specification written in frustration.
• Ship in days and be wrong cheaply. Correcting a three-day build is a conversation; correcting a three-month build is a project.
• Put policy in data, not in code. The permission matrix lives in a table because the org chart moves faster than deploys.
• Keep one exit point for anything you will want to change globally. The text guard exists because 20 agents times one prompt fix is not a fix.

The job is not glamorous. It is a lot of sitting next to someone while she does her actual work, noticing the thing she has stopped complaining about because she assumed it could not be fixed, and then fixing it before she has time to file a ticket.