The Intelligence Stack
AI Engineering

FDE - A new paradigm in software engineering

A new way which is appearing in the world of data and AI

Subhasis Mukherjee 2 min read Comments

What the role is:

A Forward Deployed Engineer (FDE) is a software engineer who works directly with a customer, often on-site or embedded in their teams, to make a product solve that customer’s real problem. A regular product engineer builds features for many customers from inside the company. An FDE starts from one customer’s messy situation and builds whatever is needed to make the product deliver value there.

Palantir made the role well known in the 2010s. Its software was powerful but needed heavy adaptation to each client’s data and workflows, so it sent engineers into government agencies and enterprises to do that work. The role has since spread widely, especially among AI companies such as OpenAI, Anthropic and many startups. Their models are general-purpose, and value only appears once someone connects them to a company’s data, systems and processes.

What an FDE actually does:

  • Understands the business problem. Sits with users, learns how work really gets done, and finds where the product can make a measurable difference.
  • Writes production code. Builds data pipelines, integrations, custom workflows, agents and evaluation setups on top of the core platform. This is real engineering, not configuration or demos.
  • Deals with the client’s environment. Works within their security rules, legacy systems, data quality issues and approval processes.
  • Feeds learning back to the product team. When the same workaround is built for three customers, the FDE pushes for it to become a product feature. This loop is a large part of the role’s value to the vendor.

Skills the role needs:

  1. Strong engineering: Python or similar, APIs, data engineering, cloud platforms, and now LLM application patterns (retrieval, agents, evaluation).
  2. Problem framing: turning a vague ask (“use AI in claims processing”) into a specific, buildable use case with a success metric.
  3. Client communication: explaining trade-offs to both engineers and executives, and handling pushback.
  4. Comfort with ambiguity: requirements change, access gets delayed, data is worse than expected.
  5. Judgment about what to generalize: knowing when a custom fix should stay custom and when it should go back to the product.
#fde

Written by

Subhasis Mukherjee

Data & AI Engineering

I design and build data platforms and AI systems. This blog is where I write down the architectures, trade-offs and lessons learned along the way.

Comments

Questions, corrections and war stories welcome. New comments appear after a quick review.

    Loading comments…

    Leave a comment

    Your name and comment are published once approved. Your email is only used if I need to reply to you privately.

    View all
    AI Engineering 3 min read

    Anatomy of a Production RAG System

    Retrieval-augmented generation is easy to demo and hard to run. A walkthrough of the offline indexing path, the online query path and the evaluation loop that ties them together.