How to become a forward-deployed engineer

A year ago the phrase forward-deployed engineer meant something to people who had worked at or near Palantir and to almost nobody else. Now it is in the subject line of recruiter mail, and the same question keeps arriving from engineers we talk to: what is it, and how do I get there.

The demand is real and it is measurable. Indeed data shared with Business Insider put postings for the role in April 2026 at 5,230% above their January 2025 level, roughly a 729% rise year over year, with advertised pay running from about $170,000 to over $200,000. Read the Business Insider report for the method. On the employer side, Amazon has described a $1 billion forward-deployed engineering unit, and OpenAI has stood up a dedicated deployment company around the same work. TechCrunch, citing a Christian & Timbers study, reported that of roughly 17,000 people in the United States carrying the title, only about 2,000 had the expertise to deliver a meaningful return on an AI program. See the TechCrunch piece for the whole set of figures and their caveats.

That last number is the one to sit with. The market is not short of engineers who can call a model. It is short of engineers who can carry a model into a regulated operation and leave it running under someone else's controls. Everything below follows from that distinction.

Palantir built the role in its first decade and gave it an internal name, Delta. The Pragmatic Engineer records that by 2016 the company had more of these engineers than product engineers. The idea was simple and demanding at the same time: put the engineer at the customer's site, make them responsible for the deployment, and let what they learn flow back into the product.

The AI labs adopted the name and narrowed it. In OpenAI's postings, a forward-deployed engineer owns discovery, technical scoping, build, rollout, adoption, and measurable workflow impact for an enterprise customer, and the healthcare variant adds health-record integrations, protected-data safeguards, auditability, and human review. That is the narrow meaning: a senior AI engineer placed at an external customer and accountable for the whole implementation.

Then the rest of the industry borrowed the title and widened it. Ed Donner's explainer on the role, which prompted many of the questions we have been asked this month, makes the point plainly: the same words are now used for any applied AI engineer solving a commercial problem with models and agents, whether for an outside client or inside their own company. Both meanings are legitimate. Knowing which one a posting intends tells you what to prepare for and what the compensation band is really pricing.

The narrow job is a senior AI engineer placed at a customer and accountable for the whole implementation. The broad job is any engineer who makes AI produce a commercial result.

Donner describes the role as five hats. We read them as layers, because you stack them in order and each one rests on the one below. His framing is the clearest we have seen for a working engineer, so we keep his five and add what each looks like from inside an engagement.

1. 01

   Software engineering. Mandatory, and it never comes off.

   You build, integrate, test, and deploy. Every forward-deployed engineer we know came in as a working software engineer first, and the ones who thrive are fluent with coding agents without shipping what those agents produce unread. You are accountable for every pull request that carries your name.
2. 02

   AI engineering. Choosing the model, wiring the agent, engineering the context.

   Model selection and model APIs, agentic patterns, retrieval, tool use, MCP servers, memory and state, context engineering, and the newer discipline of harness engineering: the scaffolding of tools, permissions, and checkpoints that turns a model into a governed worker.
3. 03

   AI solutions architecture. The layer that makes the title mean something.

   Requirements discovery, evaluation design, data curation, an experimenter's approach to research, scalable and secure deployment, observability for agents, adoption and change management, and responsible AI including safety and security. This is the difference between an AI engineer and a forward-deployed one, and it is the layer the market cannot find.
4. 04

   Business domain knowledge. A head start, learnable on the job.

   Healthcare, financial services, insurance, public sector. Knowing how the money and the risk move in one industry lets you solve a client's problem faster than someone learning both the industry and the system at once. Most people acquire it inside their first deployment and carry it forward.
5. 05

   Solutions consulting. Representing your firm in the room.

   Stakeholder management, executive communication, bridging sales and delivery, spotting the next piece of work, and feeding what you learned back into the product roadmap. This is the original Palantir sense of the job, and the narrow lab definition expects all of it.

The narrow job asks for all five. The broad job, which is where most of the openings are, asks for the first three. Notice where the scarcity lives. Layers one and two can be learned at a desk. Layer three is learned in front of an operator whose queue you are about to change, and there is no shortcut through that exposure.

The sequence is not a rule we invented. It is what shows up in how firms are actually staffing the role. Salesforce, which tripled its forward-deployed team in six months, reports that about 40 to 50 percent of that growth came from internal transfers out of engineering, professional services, and customer success, and that its onboarding runs two weeks of technical training and four weeks on the job. The lab and integrator postings read the same way: a strong engineer who already has production AI work, moved to where the customer is.

Start: software engineer

Ship production code inside a real organization, with coding agents in your workflow and full accountability for what they emit. This layer is table stakes, which is exactly why it cannot be skipped.

Next: AI engineer

Deliver projects with models and agents, even personal ones. Learn the model APIs, retrieval, tool use, evaluation, and the context and harness discipline that keeps an agent inside its lane. Show the work.

The leap: solutions architect

Get a seat in front of a customer. A role that puts you at the client while you still wear the first two layers is the fastest route into the third, because discovery, evaluation, deployment, and adoption are only learnable against a live operation.

Then: domain and consulting

Both accrue from the same exposure. You learn a health plan's prior-auth queue by sitting beside it, and you learn executive communication by carrying findings back to the people who signed the engagement.

Two cautions the postings leave out. LeadDev's reporting on the role notes travel of up to half your time in some positions, and the same piece records the concern that the definition is being diluted as more companies use the label for half-measures. If a posting cannot tell you what you would own after the launch, it is describing the broad job while pricing the narrow one.

While you are waiting for the interview that puts you at a customer, the best preparation is building, and the best thing to build is a solution to a pain you actually have. Something in your own work or life that frustrates you, fixed with models and agents, then shown wherever you show work. The subject matters less than the discipline you bring to it.

The discipline is what separates a demo from evidence. A project that runs on your own broad credentials, reading data you copied into a notebook, proves that the idea works. A project that runs under a least-privilege identity, against data it has to be granted access to, with an evaluation set that says what correct means and a runbook someone else could follow, proves that you understand the third layer. Same idea, different object, and a hiring manager can tell them apart in one conversation.

If you want a rubric, use the one we grade our own people on. The FDE Academy capstone asks for six artifacts from one operating problem: an operating map, an engineered system, an evaluation set, a control boundary, a release record, and a transfer package. A personal project that produces even four of those is a stronger signal than most resumes we read.

We built three surfaces for exactly the engineer this guide is written for. The Academy standard describes how we develop forward-deployed engineers across field discovery, integration, agent systems, governance, production, and transfer. The training platform carries the public curriculum and the published qualification standard behind it. The FDE Benchmark publishes the capability ontology and the evidence states, from a claimed skill through observed, demonstrated, and production proven, that we think a credible record of this work should be built on.

To turn those standards into a learning plan, start with the LockedIn FDE Benchmark learning hub, an educational resource from our benchmark initiative. Its AI skills self-assessment helps you reflect on your starting point and choose what to practice next. Treat the result as a learning prompt, then build the evidence another person can inspect.

If you already ship software, the developer-to-FDE pathway connects that experience to discovery, integration, evaluation, and operational handoff. For the wider sequence, follow the path to becoming a forward-deployed engineer. Choose one project and keep a record of the problem, the decisions you made, the failure cases you tested, and what the next operator would need to run it.

If you can already wear the first two layers, bring your work into the conversation through the talent network. If you are still building them, read the operating definition of the role first, then start the project that annoys you most.