Forward deployed engineer job description: what to write

You have decided you need a forward deployed engineer, or someone has told you that is the title to use. Now you have to write the job description. Most of the ones you can copy were written by AI vendors hiring people to install their own product at customer sites, so they describe a different job from the one you have. Here is one written from the buyer's side: the responsibilities, the skills, what to leave out, and whether the role should be a hire at all.

If you want the role explained first, the longer version is on the what a forward deployed engineer is page.

Why most FDE job descriptions do not fit your company

The title comes from Palantir. Gergely Orosz's deep dive on forward deployed engineers in The Pragmatic Engineer explains that Palantir called these engineers "Deltas," and that until around 2016 it had more of them than regular software engineers. Palantir's own description, quoted there, draws the line well: a product developer works on "one capability, many customers," and a Delta on "one customer, many capabilities."

The title has since spread to AI companies. The Wikipedia entry for the role notes that Anthropic, OpenAI, Amazon Web Services, Microsoft, and Google Cloud all announced forward deployed divisions in 2026. Those engineers work for the vendor. Their job is to make the vendor's product succeed inside a customer, so their postings mention sales, travel to customer sites, and fixes that go back into the vendor's platform. One Salesforce senior FDE posting that Orosz quotes lists ten expectations, including driving adoption of its own agent product.

Your situation is the reverse. You are the customer. You need one experienced person who will come into your systems and ship an AI feature your team keeps. So delete the parts about sales, quotas, and someone else's product roadmap, and write the rest around your own workflow.

Start the job description with the workflow

Before any list of duties, write one sentence that names the work. Something like: "Our support team retypes refund reasons from email into the billing tool, and the errors show up in month-end reports." Name the process, the person who does it today, the system it lives in, and what goes wrong when it fails.

That sentence does more filtering than any list of frameworks. It attracts people who want to ship into a real operation and puts off people who want to pick a model and build a demo. If you cannot write it yet, you are not ready to hire a builder.

Forward deployed engineer responsibilities

Write responsibilities as changes in your systems, not as activities. A version that fits most small and mid-size companies:

• Sit with the people who run the workflow and write down how it actually works, including the exceptions.
• Build one AI agent or LLM feature into the product or operation you already run, in your repository, behind your existing auth.
• Set clear limits: what the system may do on its own, what it may only draft, and what a person still checks.
• Build a small set of test cases from your real records, so "it works" means it works on your data.
• Ship in small releases to the environment your team already uses, and review each one against a real case with the person who owns the process.
• Leave the code, the accounts, and short handover notes in a state your team can run and change without the engineer.

The last line matters most, and it is the one vendor postings leave out. A vendor's FDE can leave behind a dependency on the vendor. Yours should leave behind a system your team owns.

Forward deployed engineer skills to ask for

Software engineering comes first. Orosz notes that almost every FDE posting asks for a solid engineering background and real-world experience shipping. Applied AI is still software. The model is one dependency. The rest is permissions, data, deploys, and edge cases.

The skills worth listing:

• Production experience. Has shipped and maintained systems other people depend on, not only prototypes.
• Full stack range. Comfortable across an API, a database, a user interface, and a deploy pipeline, because the AI feature touches all of them.
• Hands-on LLM work. Prompts, retrieval over your own records, tool calls, and evaluating output against real cases.
• Working with operators. Can sit with a dispatcher or a finance clerk, ask good questions, and explain a tradeoff without jargon.
• Judgment about scope. Will say what should not be automated, and why.
• Clear writing. Pull requests, notes, and a handover your team can read after the engagement.

What to leave off: a long list of model names and frameworks, a research degree requirement, and "10x" language. Those describe a different job and attract the wrong candidates.

Forward deployed engineer vs solutions engineer

These two roles get mixed up in job postings, and the difference changes who you should hire. Orosz describes how OpenAI separates them. Its solutions architects are closer to an advisory role. They rarely write code on customer infrastructure, and they usually build proofs of concept with anonymized or offline data. Its forward deployed engineers write code directly on customer infrastructure, using the customer's own tools.

If what you need is a proof of concept to decide whether an idea is worth pursuing, a solutions engineer, or a short advisory engagement, is the smaller and cheaper job. If your pilot already worked in a demo and never shipped, you need the forward deployed version: someone who will put it into production on your real data.

A sample job description you can adapt

Replace the bracketed parts, and leave out anything that is not true for your company.

Forward Deployed Engineer (Applied AI)

We want the workflow, in one sentence. Today the team or person does this by hand in the system, and when it goes wrong, the cost.

You will work inside our team to put an AI feature into that workflow. You will sit with the operator to learn how the work really happens, build the feature in our codebase and environment, set limits on what it may do on its own, and test it against real cases before each release. When you are done, our team should be able to run and change the system without you.

You have shipped production software that other people depend on, across the API, the database, and the interface. You have built features on top of language models with real data and real permissions. You can explain a tradeoff to someone who does not write code, and you will tell us when a step should stay manual.

Employment type, location, and reporting line.

The last line is where you decide whether this is a full-time seat or a bounded engagement, which is the next question.

When a full-time hire is the wrong choice

A full-time forward deployed engineer makes sense when you can see a year or more of AI work, a sequence of workflows that will keep a senior engineer busy, and you can wait out a senior search.

It is the wrong choice when you can only name one to three workflows and the need drops after that. A salary continues through the quiet months. It is also the wrong choice when the work cannot wait for a search, which is often the real problem. You need a senior AI engineer now, and you cannot justify, or wait for, a permanent seat. In that case the same job description works as the brief for a fractional engagement, a few months or a fixed sprint, ending in a handover. The engagement shapes (a monthly retainer, a fixed-scope sprint, or advisory hours) are on the pricing page.

And if you cannot write the workflow sentence at the top of this post, do not hire anyone to build yet. Start with a short advisory block that forces the choice, then write the job description.

Next step

Write the workflow sentence and the responsibilities list. If you want a second opinion on whether the result is a full-time seat, a sprint, or not a build at all, request an intro call on the contact page and bring the draft.