The short answer: a forward-deployed engineer (FDE) is an engineer who works inside your company’s systems, next to the people who run the workflow, and is responsible for one result in production. It is not advice and it is not extra hands. The model started at Palantir, AI labs revived it in 2025, and it now gets applied to almost anything. Below is what the work looks like, how it compares with the alternatives, what you need to bring, and when you should not buy it.
Where the model comes from
Palantir created the forward-deployed software engineer role in the early 2010s and called it “Delta”, according to The Pragmatic Engineer (August 2025). Palantir described the difference from its product engineers as “one customer, many capabilities” for a Delta, against one capability for many customers for a regular developer. The same article reports that “up until circa 2016, Palantir had more FDEs than it had ‘normal’ software engineers,” and that Palantir expects around 25% of an FDE’s time to be spent on site with customers. The rest goes to building and to feeding what they learn back into the product.
AI labs picked the model up for a simple reason. A general-purpose model does nothing for a company until someone connects it to that company’s data, tools and workflow. That last mile is where most of the value, and most of the failure, sits.
- OpenAI’s forward-deployed team was proposed at the start of 2025 and began with two engineers. By August 2025 it had more than ten, working from eight cities (The Pragmatic Engineer).
- In June 2025, a16z called the FDE “the hottest job in startups” and counted 22 of OpenAI’s 311 open roles as forward-deployed or solutions engineering positions at the time.
- The Financial Times reported that monthly FDE job listings rose more than 800% between January and September 2025, and that OpenAI, Anthropic and Cohere were expanding their teams (as summarized by PYMNTS, March 2026).
The research on stalled AI projects points the same way. MIT NANDA’s August 2025 GenAI Divide report attributed most failed pilots to a “learning gap” and poor integration into real workflows, not to model quality (Fortune). It also found that buying from specialized vendors and building through partnerships succeeded about 67% of the time, and internal builds far less often. We go through the usual failure points in why AI agent pilots stall.
A word of caution: as the title spreads, it gets stretched. a16z’s own piece describes it as a services role that is sometimes rebranded as a forward-deployed engineer or an implementation specialist. Judge a provider by what the engineer does, not by what they are called.
What it looks like week to week
Engagements differ, but an agent engagement done in this style usually follows a pattern like this.
Week one: discovery. The engineer sits with the people who do the work today. They watch a dozen real cases end to end, map every system and data source involved, and find out where the data is wrong or late. They collect 20 to 50 historical cases with known correct outcomes as the first evaluation set. The week ends with a short written scope: what the agent will do, what it won’t, how success will be measured, and what is blocking.
The build. The engineer works in your repository, your cloud account and your ticketing system, behind your authentication. Each week has a demo to the workflow owner on real cases, not slides. The evaluation set grows with every failure found. Data problems get fixed at the source rather than worked around in the prompt.
First release. The agent goes live for a small group or a slice of cases, with a person reviewing its output. Monitoring is part of the release, not a follow-up: traces, freshness alerts on data, a queue for flagged cases, and cost per completed task.
After launch. Either your team takes over, with documentation and a walkthrough of how to change prompts, tools and evals safely, or the provider keeps operating it under an agreed scope. Both are fine. Leaving it unowned is not.
The week-to-week rhythm is plain: talk to the workflow owner, ship something, measure it against the evals, repeat. The Palantir engineers quoted by The Pragmatic Engineer describe the same mix: in some weeks a couple of days at the customer’s premises, in others mostly writing and reviewing code.
How it differs from the alternatives
| What you get | Who builds | Who owns the result | |
|---|---|---|---|
| Strategy consulting | A diagnosis, a roadmap or a design | Your team, later | You |
| Staff augmentation | Extra engineers, directed by you | Them, to your spec | You |
| Agent platform or SaaS | A product you configure | You, inside its limits | You, with vendor support |
| Agency project | A deliverable to a fixed spec | Them, often in their environment | You, after handover |
| Forward-deployed engineering | A working system in your stack | Them, in your environment | Shared until handover, then you or an ops agreement |
The difference that matters is where the work happens and what the engineer is judged on. An FDE works in your environment against your real data, and is judged on whether the workflow runs in production. That reduces handover risk, because there is nothing to migrate later. It also means you need to give real access early.
None of the other options are wrong. If you want a roadmap, hire a consultant. If your team knows exactly what to build and needs capacity, staff augmentation is the simpler buy. If a product covers 90% of the workflow, buy the product.
What you have to provide
An FDE engagement fails fast without these:
- Access, early. Repositories, a cloud account or sandbox, read access to the data, and test accounts in the systems the agent will touch. Security reviews that take a month should start before the engagement does.
- A workflow owner. One person on your side who knows the work, has the authority to decide what “correct” means, and has a few hours a week for demos and reviews. This is the role most often missing.
- The data, as it really is. Including the messy parts. If key data lives on other websites, plan for how it will be collected and kept fresh. That is often a feed problem before it is an agent problem.
- A definition of done. A pass bar on the evaluation set, a volume or time target, or both.
- A future owner. An engineer or team who will own the system after handover, or a decision to keep the provider on for operations.
How to evaluate a provider
Ask these before you sign:
- Who exactly will be embedded, and do they write the code? Get names. Be wary if senior people sell and junior people build.
- Where does the code live, and who owns it? It should be your repository and your intellectual property from day one.
- How will we know it works? A good answer starts with an evaluation set built from your own historical cases, not a demo.
- What happens to our data? Where it is processed, which model providers see it, and what is retained.
- What does handover look like? Ask for an example of the documentation.
- What do you run yourselves? Teams that operate their own agent systems in production know where they break. Ask to see one.
- When have you told a client not to build an agent? If the answer is never, keep looking.
Red flags: a proprietary platform you must license to keep the system running, a scope written as activities rather than outcomes, no mention of evaluation or monitoring, and “agentic” applied to what is really a chatbot. Gartner estimated in June 2025 that only about 130 of the thousands of vendors selling agentic AI are genuine (Reuters).
When it’s the wrong choice
- A product already does it. Buying is usually faster and cheaper than any custom build, embedded or not.
- You want strategy, not a system. An FDE without something to build is an expensive consultant.
- Your team has the skills and the time. Then hire or upskill. Bringing someone in to do what your engineers could do leaves you with less knowledge in-house.
- Nobody can own the workflow. Without a workflow owner, the engineer ends up guessing what correct means, and the project drifts.
- The data isn’t there yet. If the inputs don’t exist or aren’t reliable, start with the data. For web sources, a managed data feed may be the first step, and the agent the second.
- The task is a one-off. An engagement built around production and monitoring is overkill for a job you need done once.
Where we fit
We started as a managed web-data service, so we come at agents from the data side: get the data right, then put agents on it, in your stack. Our forward-deployed engineering work follows the pattern above, from a one-week discovery to a system running in your environment with monitoring attached. Our proof so far is Nomad Watch, our own agent-maintained 3,000-city dataset, where agent output passes a deterministic gate and a cross-model check before anything ships. If a product, a consultant or your own team is the better fit for your case, we will say so. Tell us about the workflow and we’ll give you a straight answer.