The role
What a Forward Deployed Engineer actually does
"Forward deployed" is a military phrase: operating at the point of action rather than from the base. Palantir borrowed it in the mid-2000s for engineers it sent to sit inside client organisations, because the data environments it worked with could not be understood, let alone changed, from a distance. Those engineers, "Deltas" in Palantir's vocabulary and at one point more numerous than its conventional developers, wrote production code on the client's systems, attended the client's stand-ups and stayed until the software held. The distinction that matters: a product engineer works on one capability for many customers; a forward deployed engineer works on one customer across many capabilities.
The title stayed rare for two decades, then became a hiring category in 2025 and 2026 when OpenAI, Anthropic, AWS and a run of AI companies hit the problem Palantir hit: the gap between what the product can do and what the customer's operation needs is not closed by documentation or a sales engineer; someone has to go in and build. a16z's Joe Schmidt gave the economics in "Trading Margin for Moat" (June 2025): whoever does the integration work owns the data layer and becomes the customer's system of work, as Salesforce, ServiceNow and Workday did a platform shift earlier, and what the forward deployed team leaves behind, reusable libraries, integration patterns and frontline product feedback, is the moat. AWS then put US$1 billion behind it in June 2026, embedding thousands of engineers with customers and consulting partners to co-develop agentic AI systems under the customer's real constraints from day one, built for self-sufficiency rather than dependency, with time to production measured in weeks. Their phrasing, "from counsel to outcomes" and "the production bar does not change regardless of the mode", is the same yardstick as OpenAI's, and it is why the title is now turning up in Australian job ads.
The work, in practice
Underneath the title, the job is an arc that runs from discovery to hand-over:
- Discover. Sit with the people who run the system. Catalogue what is actually there before anyone maps a column. The documentation is usually out of date; the data and the person who knows the system are not.
- Decide. Scope in writing. Migrate, archive or ignore, with named owners, so "not migrated" never looks like "forgotten" at go-live.
- Build. One workflow end to end before the rest is designed. Rough but safe ships first and hardens after. Publish a contract other teams can build against.
- Integrate. CRM, ERP, identity, vendor APIs. When a shared vendor environment blocks testing, build the simulator and contract-test against it.
- Ship. Deterministic, re-runnable, tested. Recovery from a failed run is a re-run, not a repair. Then the production cutover, rehearsed until it is boring.
- Hand over. Tools the business keeps using after you leave, and documentation that both humans and agents can navigate. Done means live, and owned.
OpenAI's own description of the role in Sydney says the engineer owns "discovery, technical scoping, system design, build, and production rollout", embedded with the customer's engineering and domain teams, and is measured on production adoption and measurable workflow impact rather than on decks delivered. That is the right yardstick. If it is not in production and nobody is using it, the work is not finished.
What makes someone good at it
Everyone who writes about the role lists roughly the same traits, and they match what I have seen. Curiosity about unfamiliar operations, and the patience to learn one deeply in weeks. Comfort with ambiguity, because the specification usually does not exist yet. A bias to prototype, and the engineering discipline to harden what works. Urgency measured in days, not quarters. Enough seniority to be trusted with the customer's production systems, and enough humility to let the customer's people own the outcome.
Illinois Tech's 2026 guide to the role sums up why it is suddenly in demand in five words: AI is easy to demo and hard to deploy. Its list of what the job takes is the same one from both sides of the desk. On the technical side, software engineering fundamentals and full-stack experience, applied AI (fine-tuning, retrieval, evaluations), data engineering, cloud infrastructure and security, and rapid prototyping. On the human side, writing and communication, listening, systems thinking with comfort in ambiguity, and business acumen tied to measurable outcomes.
One I would add, from doing this under other names for a long time: a working knowledge of the business the software serves. The work I am proudest of, in property settlement, superannuation, healthcare accreditation and retail lease management, came from understanding what the people on the other side of the desk were actually trying to get done that day.
Why I use the title
Because it is the most honest description of the work I have been doing since 2025, and of much of what came before it. At AGPAL and QIP I work inside the business alongside its stakeholders and vendors, on a transformation that spans CRM, financial ERP and an accreditation platform. The simulator of the vendor's platform and the portal that lets the business see its own migration data both came out of that: each was the fastest way to unblock the work in front of us. Before that, the pattern was the same: embed, understand, build, ship, hand over. Agentic AI has changed how much one engineer can carry, not what the job is.
Greenfield, scale-up or legacy, if there is a business behind it that needs the software to work, that is usually where I start. Get in touch.
Further reading: Wikipedia on the role and its history; The Pragmatic Engineer on why FDEs are in demand; Kinetic IT's definition and traits; OpenAI's Forward Deployed Engineer role, Sydney; AWS, Forward Deployed Engineering for Partners (June 2026); Amazon on the US$1 billion Forward Deployed Engineering organisation; Illinois Tech, What Is a Forward Deployed Engineer? (July 2026); a16z, Trading Margin for Moat (June 2025).