What a Forward Deployed Engineer Does, and When Your AI Projects Need One

The short answer#

A forward deployed engineer (FDE) is a software engineer who works inside the client's world instead of behind a product backlog. They sit with the people who have the problem, design the solution with them, build it against the client's real systems and data, and stay until it runs in production and people actually use it. One person owns the whole path from "here is our pain" to "this is live".

Why the role exists: the gap between a demo and production#

Most gen AI projects don't fail at the demo. They fail after it.

The demo works on clean sample documents. Then it meets the real organisation:

• The data sits in five systems, with permissions nobody has written down.
• Security wants to know where every prompt and every answer goes.
• The business can't say what "good" looks like, so nobody can prove the assistant is ready.
• Operations won't run something they can't monitor.

Each of those is a handover in a traditional delivery model: business analyst to architect, architect to developers, developers to security, security to operations. Every handover loses context, and gen AI projects have more unknowns than most. What the system should do is often discovered while building it.

The FDE model removes the handovers. Palantir made the role famous. In the gen AI wave, model providers such as OpenAI and Anthropic now hire forward deployed engineers too, for the same reason: a powerful model is not a working solution until someone fits it to one organisation's data, rules and workflows.

What an FDE actually does#

An FDE's week moves between the meeting room and the code editor:

• Runs discovery. Maps the workflow, finds who decides, and surfaces the constraints nobody mentioned in the first call.
• Turns pain into a testable target. "Our analysts lose hours searching policy documents" becomes an opportunity statement with KPIs and acceptance criteria.
• Chooses the smallest pattern that works. Plain automation, retrieval-augmented generation (RAG), a single bounded agent, or a multi-agent system. Not the most impressive one.
• Builds against real systems. Enterprise APIs, relational and document databases, identity and permissions, not a sandbox.
• Proves it works. An evaluation set agreed with the business, so "ready" is a number, not an opinion.
• Makes it safe to run. Guardrails against prompt injection and data leakage, authorisation checks, tracing and cost controls.
• Drives adoption. Demos to stakeholders, a rollout plan, and the training and support that make people use it.

FDE vs solution architect vs consultant vs software engineer#

The roles overlap. The difference is where each one's job ends.

An FDE is not a consultant who codes a little, or a developer who joins a few meetings. They are accountable for the outcome, not for one stage of it.

The skills that make a good FDE#

Two sets, and the role needs both.

Engineering depth

• Retrieval that holds up on messy enterprise documents and permission-aware data.
• Agents with tools, memory, approval checkpoints and a safe way out when they're unsure.
• Orchestration of several agents, for example with LangChain and LangGraph.
• Evaluation, observability, security and cost control built in from the first increment.
• Integration with the APIs, databases and cloud targets the client already runs.

Client craft

• Asking the questions that expose the real problem.
• Writing a one-page solution design a CXO and a security lead can both sign.
• Defending trade-offs in plain language: why RAG and not fine-tuning, why one agent and not five.
• Showing progress as something a stakeholder can see: a demo, an evaluation report, a risk note.

Strong developers usually have the first set. The second is what turns them into FDEs, and it can be taught.

When your organisation needs forward deployed engineers#

You probably need the FDE model if:

• Your gen AI pilots impress in demos but stall before production.
• Business, architecture and engineering keep re-explaining the same problem to each other.
• Security and compliance reviews arrive at the end and send projects back to the start.
• You build AI solutions for clients and need engineers who can face them directly.
• Nobody on the project can say, with evidence, whether the assistant is good enough to launch.

Hire FDEs or grow them?#

Experienced FDEs are scarce, and an outside hire still has to learn your systems, your data and your people. Your own senior engineers and architects already know all three. What they usually lack is the delivery discipline: discovery technique, opportunity framing, evaluation as a contract, and production controls for agents.

That is why many teams grow FDEs from within. Pick engineers who are curious about the business, pair them with a real use case, and give them the method and the hands-on practice to carry it from discovery to go-live.

Questions leaders ask#

Is an FDE just a new name for a solution engineer? No. A solution engineer typically shapes and demos the solution before a deal. An FDE builds and runs it with the client after the deal, all the way into production.

Do FDEs only work for vendors? No. Vendors use them to land their product with customers, but enterprises use the same model internally: an FDE embedded with a business unit delivers its AI use case end to end.

How many FDEs does one project need? Often one or two per use case, supported by the platform, security and data teams. The point is a single owner, not a large team.

What background makes the best FDE? A strong software engineer or architect who enjoys talking to users. Gen AI experience helps, but the engineering foundation and the client instinct matter more.

Can a team learn this in a workshop? A team can learn the method and practise it end to end on a realistic client scenario: discovery, design, a working multi-agent build, evaluation, security and a client-ready deployment pack. Real-world experience then deepens it.