Ask three vendors for a forward deployed engineer and you will get three different people. One sends a consultant with a new title. One sends a contractor who waits for a specification. One sends a presales architect who will not be the person implementing it.
The short definition
A forward deployed engineer is a senior engineer who works inside your systems and owns a production outcome.
Two halves matter equally. Inside your systems: your repositories, your data, your review queue, your standups. Owns the outcome: accountable for something running and used, not for a document describing what should be built.
Where the role came from
Palantir developed the role in its early years. Its forward deployed software engineers became known internally as Deltas, and they deployed and customized the company's platforms against customer problems. The gap they filled was specific: a platform that could do a great deal, and customers who could not get from it to a working result on their own data.
The title and the hiring demand behind it accelerated sharply in 2025, when AI companies hit the same wall: a capable model behind an API, and customers unable to turn it into an operating system of their own. By 2026 OpenAI, Anthropic, AWS and Salesforce had all built forward deployed teams. In June 2025 an a16z article called it the hottest job in startups.
What the job actually looks like
The work splits across three disciplines that rarely coexist in one engineer.
- Engineering. Production code, integrations, data pipelines, tests and releases.
- Operations understanding. Sitting with the people who do the work today, learning the exceptions that never made it into documentation, watching where the process breaks.
- Judgment about scope. Deciding what to build, what to leave, and what is not a software problem at all.
The split changes by week and by engagement. Some weeks are dominated by code, others by scoping and time with the people who will use the system.
The output of a good week is not a status report. It is a pull request in your queue, behind your existing controls, that moves a number someone cares about.
One more feature separates the role from contract delivery: what the engineer learns in the field goes back into the product, the tooling and the patterns the next engagement starts from.
Four roles it gets confused with
| Role | Typical mandate | Hands-on build | Primary accountability |
|---|---|---|---|
| Consultant | Diagnose, recommend, or lead a defined transformation | Varies by engagement | Contracted deliverables and any outcomes named in the statement of work |
| Staff-augmentation contractor | Add capacity inside your team | Usually | Assigned scope, implementation quality, delivery |
| Solutions architect | Shape technical strategy, architecture and adoption | Often prototypes; implementation varies | Technical fit, risk, and the path to production |
| In-house engineer | Build and operate the company's systems over time | Yes | Long-term product and system health |
| Forward deployed engineer | Discover, build, deploy, and return field learning to the product | Usually | Technical delivery through production and an agreed handoff |
These are operating patterns, not protected titles. A consultant may write production code, a solutions architect may prototype, and a forward deployed engineer may work through a vendor-managed platform rather than your repository.
A solutions architect typically owns technical strategy and the path to adoption. A forward deployed engineer typically owns hands-on delivery through production and handoff. Both may write code, so the engagement has to state who implements, deploys and supports the system.
Why the role is hard to fill
Strong engineering fundamentals are the entry requirement. Beyond them, the engineer has to turn an ambiguous operational problem into a bounded build, revise the plan as new constraints appear, and work out which part of the workflow is worth changing at all.
At 3ALICA one named lead owns the engagement, supported by a pod of two to four senior engineers. We start with a read-only assessment of one repository rather than a proposal.
How to tell a real one from a renamed consultant
Four questions, and the answers come quickly.
- Show us one redacted production change the proposed lead took from discovery through release. What did they build, what did the customer review, and what changed after deployment? A yes to "will you write code" costs nothing; an artifact does not.
- Who is the named lead, what share of their week is committed, which decisions do they own, and can we speak to them before signing? A lead with no committed hours is a name on a slide.
- From the first working change, where do the code, tests, infrastructure configuration, deployment history and runbooks live, and who can merge and release them? A shared repository alone proves nothing about who holds authority.
- What must our team be able to operate without you before this closes, how will we test that handoff, and who owns incidents after release? That progression, from observing to co-building to operating independently, is how AWS describes its own engagements.
When you do not need one
- The problem is a decision, not a build. If nobody can say which number should move, an embedded engineer will surface that in week one, expensively.
- The scope is a well-specified project. If the requirements are stable and complete, a traditional agency may be a better fit.
- You already have the pattern in-house. If your team has shipped this class of system before, they need capacity, not an embedded specialist.
- Nobody on your side can own adoption. The system will be built and then ignored, whoever built it.
Why this became the default way to buy AI work
A model behind an API is not yet a production system a business can run. Deployment needs access to real data, integration with systems that predate the AI conversation, workflow changes, and explicit operational ownership.
A recommendation does not complete that work. The role exists to carry it through inside the customer's operating environment.
If you are weighing this against hiring, see how a pod runs inside your team and what you own when it ends.