What a forward deployed engineer actually does
Three live job postings, read line by line: what the role is, how it differs from the jobs next to it, and how to build proof for each skill this year, wherever you live.
You keep seeing "forward deployed engineer" on job boards and in AI company announcements. Read a few threads about it and you still can't tell whether it's software engineering, sales engineering with a new name, or consulting. If you want the job, that vagueness is a real problem: you can't build evidence for a role you can't describe.
So I read three current postings closely on 3 October 2026: OpenAI's Forward Deployed Engineer in San Francisco, Palantir's Forward Deployed AI Engineer in New York, and Deloitte's Anthropic Forward Deployed Engineer in its Government and Public Services practice (Deloitte is the employer there; Anthropic's platform is the specialism). Here is what they say, paraphrased, and what it means if you're building towards the role from outside the US.
The role in one paragraph
A forward deployed engineer (FDE) is a software engineer who works with a customer's own teams and takes an AI system from first conversation to production. OpenAI's posting lays out the arc: the FDE owns discovery, technical scoping, system design, build and production rollout, working directly with the customer's engineering and domain teams. Success is measured by production adoption, measurable impact on the workflow, and eval-driven feedback that changes product and model roadmaps.
Palantir compares the responsibilities to those of a hands-on AI startup CTO: small teams, high-stakes projects, building LLM workflows, setting the customer's AI strategy, and putting solutions to work inside the partner's organisation. Deloitte's version adds consulting habits: leading client working sessions, mentoring newer team members, and leaving behind reusable code, prompt libraries, runbooks and reference implementations.
The common thread is simple. You're judged on whether the system works in someone else's organisation, not on whether it works in your demo.
What the postings actually ask for
| OpenAI (San Francisco) | Palantir (New York) | Deloitte GPS (eight US cities) | |
|---|---|---|---|
| Experience | 5+ years of engineering or technical deployment, including customer-facing work | Past experience building solutions with LLMs; strong engineering background | 4+ years in software, data or analytics engineering; 1+ year deploying GenAI in client or production settings; 1+ year hands-on with Anthropic's platform |
| Code | Production-grade frontend and backend code in Python, JavaScript or similar | Python, Java, C++, TypeScript/JavaScript or similar | Production-quality code with testing, CI/CD, logging, versioning and documentation |
| AI depth | Has built or deployed LLM systems and understands how model behaviour shapes the product | ML basics: evaluation, training, problem decomposition | Tool use and human-in-the-loop controls; trade-offs across quality, safety, latency, cost and model risk |
| People | Communicates clearly with engineers, product teams and customer stakeholders | Works across technical and non-technical teams; iterates directly with users | Leads working sessions and workstreams; turns business problems into AI solutions |
| Travel | Up to 50% | Up to 25%, flexible | 50% on average |
| Pay (US$, base) | 185K to 300K, plus equity | 135,000 to 200,000, plus possible stock units | 134,500 to 265,100 |
| Hard limits | Hybrid, three office days a week in San Francisco | New York, hybrid | US work authorisation without sponsorship; able to obtain a US security clearance |
Two things stand out. First, none of the three asks for a research background. Palantir says outright that it values solving real business problems over academic benchmarks. Second, evals turn up in all three: OpenAI measures success partly through eval-driven feedback, Palantir lists evaluation as an ML basic, and Deloitte prefers experience with evaluation frameworks and model monitoring.
The hard limits matter if you live outside the US. The Deloitte role needs US work authorisation and clearance eligibility, so it's closed to most readers here. But the title isn't US-only. OpenAI also advertises FDE roles elsewhere; its Tokyo posting has the same duties and requires fluency in both Japanese and English. Look at roles in your own region and languages before you look at San Francisco.
How it differs from the jobs next door
Four roles get mixed up. The cleanest way to separate them is to ask who you serve and what you're judged on.
| Role | Who you serve | What you ship | Judged on |
|---|---|---|---|
| Software engineer | All of the product's users at once | Features in a shared codebase | Product quality and delivery |
| Solutions engineer | A prospect, around the sale | Demos, proofs of concept, technical answers | An honest technical fit and a closed deal |
| DevRel | A developer community, one to many | Docs, samples, talks, workshops, product feedback | Developers adopting and succeeding |
| FDE | One customer's teams, side by side | A working system in their environment | Production adoption and workflow impact |
Titles vary and the lines blur, so treat the first three rows as the usual pattern, not a rule. A useful test: if the system breaks in the customer's environment next month, whose problem is it? OpenAI's answer for FDEs is clear: they own delivery from first prototype to stable production.
FDE work also flows back into the product. OpenAI asks FDEs to share field feedback with Research and Product, and to turn working patterns into tools and playbooks other people can use. Palantir mentions feeding learnings from the field back into its product suite. That loop is what separates an FDE from a contractor who ships and leaves.
The seven competencies
Put the three postings side by side and the skills fall into seven groups:
- Customer discovery. Finding the real job behind the request, and what the current process costs.
- Production code. Tests, CI/CD, logging, versioning and documentation. Deloitte names all five.
- LLM systems. Tool use, retrieval and prompts, and knowing how model behaviour changes the product.
- Evals. Measuring whether the system works, before and after every change.
- Deployment. Getting a system running in an environment you don't control, and keeping it running.
- Security. Access control, data handling and prompt injection. Deloitte prefers familiarity with security, privacy and compliance, and OpenAI's FDEs work alongside its GRC and Security teams.
- Communication. Explaining trade-offs to engineers, managers and end users, in writing and in a room.
Proof you can build this year
None of these needs a US job, a visa or a paid course. Each needs a real problem and a public record. This table maps each competency to evidence that answers a specific line in the postings above.
| Competency | Proof you can build this year | Where it shows |
|---|---|---|
| Customer discovery | Interview three to five people who run a manual process: a clinic front desk, a cooperative's records, a school's fee tracking. Write a one-page problem statement with the current time cost. | A short written case study |
| Production code | Ship one small system that real people use for at least a month, with tests, CI and logs. | A public repo with history and a runbook |
| LLM systems | Build a tool-using assistant over that organisation's real documents, with their permission, and write down where it fails. | The repo plus a one-page design note |
| Evals | Turn 20 to 50 real failures into test tasks and report pass rates before and after one change. | Eval results committed next to the code |
| Deployment | Run it on a small VPS or free tier with monitoring and a rollback plan. Write a post-incident review the first time it breaks. | The review, published |
| Security | Write a threat model, try prompt injection through the documents themselves, and scope every key to the least it needs. | A security section in the README |
| Communication | Explain the project to a non-technical audience: a meetup talk, a workshop or a plain-language write-up. | A recording or a link |
The 20 to 50 figure comes from Anthropic's engineering guide to agent evals, which calls that many simple tasks, drawn from real failures, a good starting set. You don't need hundreds.
One project can fill every row, and that's deliberate. An FDE's job is one system, end to end, so one end-to-end system with a real user is stronger evidence than seven tutorials.
If you're studying outside the US
Find real users near you. Clinics, cooperatives, schools and small logistics firms have messy processes too. Ask permission before you touch any data, and remove personal details from anything you publish.
Make the evidence portable. A hiring manager in another country can't visit your client, but they can read your repo, your eval results and your incident review. Write them so a stranger can follow them.
Treat your languages as a skill. The Tokyo posting shows FDE teams hire for the language their customers speak. If you work in English plus Yoruba, Hausa, Igbo, Swahili or French, that's a real asset for customers in your region.
I'm on this path myself, aiming for AI engineering first and FDE work after, and this table is the plan I'm working from.
Learn it properly
For the engineering half of this table, Track 1 of the AI Study Group, Agentic AI engineer roadmap, is free and self-paced, and goes from tokens and prompts to a tool-using agent with evals, running around the clock on a small server.
Sources
- Forward Deployed Engineer (FDE), SF (OpenAI careers, read 3 Oct 2026): scope, requirements, travel and pay
- Forward Deployed Engineer, Tokyo (OpenAI careers, read 3 Oct 2026): same duties, bilingual requirement
- Forward Deployed AI Engineer (Palantir, read 3 Oct 2026): responsibilities, requirements, travel and pay
- Anthropic Forward Deployed Engineer, GPS (Deloitte, read 3 Oct 2026): duties, requirements, clearance and pay
- Demystifying evals for AI agents (Anthropic, 2026): starting with 20 to 50 tasks from real failures