Forward Deployed Engineering Practices

Forward deployed engineering (FDE) is a practice where engineers embed directly inside a customer’s organization to implement and customize AI solutions. It was pioneered by Palantir many years ago, and today companies like OpenAI, Anthropic, and Google DeepMind build massive FDE teams. The term comes from the military, meaning you take your best people and build in the most critical environments.

For AI development, FDE matters because AI isn’t just software you hand over—it changes how a company operates. The role of a forward deployed engineer is to go into a company, understand its workflows, and re-engineer those processes around AI. This requires balancing technical skill with human communication: you need top-tier technical ability but also high emotional intelligence (EQ) to help people adopt new tools. For instance, if a client uses an 11-step workflow and you replace it with one step, adoption may fail because it’s too jarring.

Modern FDE is expanding. Engineers now handle DevOps (deployment and operations), custom solutioning, and data integration all at once. With coding agents making code cheap to produce, FDEs can move beyond prototyping to building complete end-to-end solutions. The work varies by company size and industry—for example, adapting an AI customer service agent to a specific enterprise requires training it much like you’d train a human employee. Every FDE is ultimately accountable to the customer, translating their needs back into the product.

Forward deployed engineering is a product strategy, not a support role. Start by asking if you truly need it—if you're evaluating options or watching kitten videos, this isn't for you. The job involves co-building software directly with a customer in their critical environment, treating it as an extension of product development, not go-to-market.

Step one: prove value fast. When a customer asks for XYZ, they're often right, but you should think about how to solve their problem in a way that scales to other customers. At Decagon, forward deployment is identical to product engineering—same bar, same reporting structure. So instead of writing custom code for one client, build a self-serve way where the customer or an agent-building team can do it themselves.

Step two: bring every problem back into the product. During enterprise conversations, issues that come up should feed directly into your core offering, not stay locked in a one-off implementation. This is how you scale the work beyond a single deployment.

Step three: wear multiple hats. The role combines staff engineering plus DevOps (managing deployment) and more. When code becomes cheap, your value shifts to configuring outcomes on behalf of customers, so you're pricing results, not hours. The dirty secret is that forward deployed engineering is many things at once—product, infra, and delivery—converging into one role.

Real-world example: at Palantir, forward deployed engineers built software in the most critical environments for people who needed it most, like a rotation program that transformed regular engineers into forward deployed ones. At Kepler and Sierra, the same pattern applies: go deep with clients, solve bespoke problems, then generalize those solutions. The goal isn't to stay embedded—it's to make the work repeatable and productized.

Forward deployed engineering (FDE) is building custom software directly with customers, often on their site or infrastructure. The single biggest mistake is treating work as temporary. As engineers warn, "the most dangerous words... are this is just temporary." Any hack that solves a problem will live forever, so ship every solution as if it will become permanent product code.

The core practice is turning customer problems into reusable product features. Always ask: "How do I solve this customer problem in a way that extends to other customers?" At Decagon, forward deployment engineering is identical to product engineering—same standards, same reporting structure, no ego. Every issue from customer conversations must be brought back into the product for the whole user base.

FDE is a product strategy, not a sales function. Being an FD is an extension of product, not go-to-market. Everyone in the company is go-to-market because the mission is shipping solutions, not closing deals. The role stacks many skills: DevOps, data integration, custom solutioning, and enablement—all unified by direct accountability to the customer.

The "dirty secret" is the role is many things at once, and the blurred lines are growing. Product engineering is becoming more client-facing, and good FDEs must think about product and customer together. Use your customer proximity to translate their signal into product stability and better data flows. In practice, ask first if you even need an FDE team, then embed engineers with your most critical customers in their most demanding environments.