Hire Developers
Forward deployed engineers: what they do and how to hire one
A forward deployed engineer (FDE) is a software engineer who works inside one customer's environment to make a product or AI system work there. They write production code against the customer's real data, integrations and permissions. Their job is the gap between a demo that works and a deployment that works. Palantir made the role famous.
Schedule Technical DiscoveryYour first conversation will be with a senior technical partner, not a salesperson.
What a forward deployed engineer does all week
- Connects the system to the customer's reality. Data sources, ERP and CRM exports, internal APIs, single sign-on.
- Makes AI output trustworthy on real data. Builds the retrieval, guardrails and evaluation that a demo skipped.
- Handles permissions and audit. Who can see what, who can trigger what, and how it is logged.
- Fixes what only shows up in production. Latency, cost per request, edge cases in the customer's own data.
- Feeds the product. What breaks at one customer goes back to the core team as a product change, not a one-off patch.
FDE vs solutions engineer vs implementation consultant
These three roles get confused in job titles and in vendor pitches. The difference is who they answer to and whether they ship code.
| Forward deployed engineer | Solutions engineer | Implementation consultant | Staff-augmented developer | |
|---|---|---|---|---|
| When they work | After the deal, inside the deployment | Before the deal, in the sales cycle | After the deal, on setup | Any time, inside your team |
| Writes production code | Yes, daily | Demos and prototypes | Rarely. Configures supported options | Yes, on your backlog |
| Measured on | The system working for that customer | Deals won | Go-live on schedule | Tickets delivered |
| Their work ends when | The deployment hits its production goal | The contract is signed | The handover | The contract ends |
Is an FDE the right hire? Five questions
Answer yes or no.
- Does the system already work somewhere? A demo, a pilot or another customer. If nothing works yet, you need product engineering first.
- Is the blocker inside the customer's environment? Data, integrations, permissions or users, rather than the model or the core product.
- Can the customer side give access and decisions within days? An FDE waiting three weeks for credentials is an expensive spectator.
- Is there a production goal you can measure? A workflow running, a number moving. "Make it better" is not a goal.
- Will what the FDE learns change the product? If not, you are buying custom work. Call it that and buy it as a project.
Hire an FDE, or buy forward deployed engineering?
| You want | Choose |
|---|---|
| One engineer embedded in your team or at your customer, working under your direction | Hire an FDE (this page) |
| AMT to run the deployment end to end, with its own lead, methodology and delivery gates | Forward deployed engineering service |
Skills to screen for, and how to test them
| Skill | Why it matters | How to test it in an interview |
|---|---|---|
| Production engineering in your stack | FDEs ship code that stays running after they leave | Ask them to walk through a deployment they owned and what broke in week two |
| Data integration | Real customer data is never shaped like the demo data | Give them two messy exports and ask how they would reconcile them |
| Identity and permissions | Most enterprise deployments stall on access, not features | Ask how they would scope an AI agent's permissions in a customer's SSO |
| LLM application engineering | RAG, tool calling, MCP servers and evaluation are the daily work on AI deployments | Ask how they would prove a RAG answer is right on the customer's data |
| Cost and latency in production | A pilot that costs ten times more at volume gets cancelled | Ask what they would measure in the first week of production |
| Writing for non-engineers | FDEs explain trade-offs to the customer's operations team | Ask for a one-paragraph status update on a blocked deployment |
| Saying no to scope | One customer's wish list can swallow the product | Ask about a request they refused and how |
AMT's forward deployed engineers
- AMT formalised its Forward Deployment Engineering methodology in 2024. The rule that runs through it: no blind AI-generated code, and human accountability at every gate.
- AMT has built AI systems since 2013, starting with IBM Watson.
- AMT engineers build the pieces FDEs deploy: AI agents, RAG pipelines, MCP servers, conversational and voice AI.
Terms are the same as every AMT hire. See the table on /hire.
When an FDE is the wrong hire
FAQ
What is a forward deployed engineer?
A software engineer who works inside one customer's environment to make a product or AI system work there, writing production code against that customer's real data and systems.
What does a forward deployed engineer do?
They integrate the system with the customer's data and tools, handle permissions, make AI output reliable on real data, fix production issues, and feed what they learn back into the product.
What does FDE stand for?
Forward deployed engineer. "Forward deployed" means the engineer works at the customer's front line rather than inside the product team's office.
What is forward deployed engineering?
The delivery model built around FDEs: engineers embedded with the customer until the system works in production. AMT's version is described on /services/forward-deployed-engineering.
How is a forward deployed engineer different from a solutions engineer?
A solutions engineer helps win the deal with demos and prototypes. A forward deployed engineer arrives after the deal and ships production code until the deployment works.
Do I need an FDE for my AI project?
You need one when the AI works in a demo but stalls inside a real environment. If the AI does not work anywhere yet, start with AI development instead.
Tell us what works in the demo and what breaks in production.
Read AMT's forward deployed engineering approach →