Forward deployed engineering is a way of delivering software in which engineers work embedded with a customer, on the customer's own systems and data, and are responsible for getting a working solution into production. The engineers are called forward deployed engineers, or FDEs. The term has become common in AI, where the hard part is rarely the model and usually everything around it.
This explainer covers where the term comes from, what the work looks like day to day, how it compares with other ways of buying technical help, and how to tell whether it fits your situation.
What is forward deployed engineering?
Three properties define it:
- Where the work happens. The engineers work inside the customer's environment: its systems, its data, and its teams' actual processes. They are not building a generic product at headquarters and shipping it outward.
- What they are accountable for. An outcome in production, such as a process that now runs on the new system, rather than a report, a specification, or a set of tickets.
- How they handle change. Because they see real data and real users early, they are expected to adjust the plan when reality disagrees with it, and to write the code that gets the result.
"Forward deployed" is borrowed from military language: positioned near the front, not back at base. In software it simply means close to where the problem is.
Where the term comes from
The title is most closely associated with Palantir, which uses it for engineers who work directly with customers on their data and problems (see, for example, Palantir's own post, A Day in the Life of a Palantir Forward Deployed Software Engineer). The reasoning was that for complex, data-heavy software, value is created during deployment, at the customer, as much as in the product itself.
AI model companies have since adopted the role. OpenAI, for example, describes its FDEs as leading "complex end-to-end deployments of frontier models in production alongside our most strategic customers", owning technical delivery "from first prototype to stable production", and measures success by "production adoption, measurable workflow impact" (OpenAI careers). The reason is the same: capable models are of little use to a business until they are connected to its systems, its permissions, and its people's work.
What a forward deployed engineer does day to day
The role combines work that is often split across several jobs:
- Discovery. Sitting with the people who run a process, observing how work actually flows, and finding where time and errors go. The documented process and the real one are rarely the same.
- Scoping. Choosing what to build first, sequencing the work, and removing blockers early: access, security review, data quality, sign-off.
- Integration. Connecting AI to the systems where the business state lives (ERP, CRM, document stores, internal tools) with scoped permissions and approval steps.
- Building. Writing the agents, workflows, and connectors, then handling the edge cases that only appear in real data.
- Rollout. Working with the users until they trust the system enough to change how they work, which includes training.
- Feedback. Turning what they learn into reusable patterns, and, at product companies, feeding it back into the product.
The typical skill set follows from that list: solid software engineering, comfort with messy data and legacy systems, and the ability to talk to a controller or an operations lead in their language. Seniority matters more than in most engineering roles, because FDEs make scoping decisions that would elsewhere go to a manager.
Two kinds of forward deployed engineering
It helps to distinguish who employs the FDE:
- Vendor-side FDEs work for a product or model company and deploy that company's product at customers. They know the product deeply, and their work also serves the vendor's roadmap and adoption goals.
- Independent FDE firms work for the customer and are not tied to one product. They can choose tools and models per use case, and the result belongs to the customer.
Neither is better in general. If you have already chosen a platform and want it working, the vendor's own FDEs may be the fastest route. If the question is still open, or the work spans many systems and vendors, independence matters more.
How it compares with other models
Each model is the right choice for something. The differences are in the deliverable and in who carries the risk of getting it into production.
| Model | Main deliverable | Best when | Watch out for |
|---|---|---|---|
| Forward deployed engineering | A working system in production, plus the team to run it | The problem is specific to your systems and data, and you need it working | Needs systems access and engaged process owners; less suited to open-ended strategy |
| Management or strategy consulting | Analysis, recommendations, operating model | The question is strategic and open (market entry, M&A, organisation design) | Implementation usually needs a separate team afterwards |
| Solutions or sales engineering | A configured product and a proof of concept | You are evaluating or adopting a specific product | Scope is naturally limited to that product |
| Staff augmentation | Engineers who work under your direction | You have clear technical leadership and need capacity | You carry the scoping and delivery risk |
| Systems integrator or development shop | Software built to a specification | Requirements are well understood and stable | Changing requirements become change requests |
AI projects often sit awkwardly in the last row. You discover what works through contact with real data and real users: the process you planned to automate turns out to be three processes, or the most valuable use case is one nobody wrote down. Forward deployed engineering is designed for that uncertainty; a fixed specification is not.
When forward deployed engineering fits, and when it does not
It tends to fit when:
- the value depends on connecting AI to your own systems and data;
- the process is specific to your company, so an off-the-shelf tool only goes part of the way;
- you want the capability to stay in-house afterwards;
- someone can grant systems access and a process owner can give the work real time.
It tends not to fit when:
- you need long-term capacity under your own technical lead (staff augmentation is cheaper);
- the question is still strategic rather than operational;
- no one can provide access to the relevant systems, because nothing can ship without it;
- a standard product already covers the need well enough.
How to evaluate a forward deployed engineering partner
Whether you are talking to a vendor's FDE team or an independent firm, these questions separate real delivery from rebranded consulting:
- What have you put into production, and who runs it now? Ask for examples you can verify, and ask who maintains them today.
- Who will actually be on site? The people in the sales meeting should be the people doing the work, or you should meet those who will.
- What do we own at the end? Code, connectors, documentation, credentials, and the knowledge to extend them. Ask what happens if you stop working with them.
- How do you handle access, security, and approvals? A credible answer covers scoped permissions, human approval for actions that change records, and an audit trail.
- What is the first production milestone, and when? A good partner commits to one real process rather than a broad programme.
- When would you tell us not to do this? A partner who never says no is selling time, not outcomes.
How we work
Specialty Tokens is an independent forward deployed AI engineering firm based in Vienna, working across DACH, Europe, the UK, and the US. Our engagements follow the pattern above: we embed with your team, connect your systems to the AI tools you have approved, ship one load-bearing process into production, and hand everything over, with no per-seat fees and no dependency on us. The details are on how we work and AI agency Vienna, and examples are in our case studies.
If you have a process in mind and want to know whether a forward deployed engagement is the right shape for it, talk to us. If it is not, we will say so.