So You Want to Be a Forward Deployed Engineer (for AI)

Every AI company has discovered the same thing at the same time: the model demo closes the meeting, and then someone has to make the thing actually work inside a customer's messy, legacy-encrusted, politically complicated environment. That someone is the forward deployed engineer, and right now it's one of the most in-demand and least-understood roles in the industry.

I came to this role sideways — years of building voice agents and real-time AI systems that had to survive contact with real customers, real telephony, and real ops teams — and I've watched the job title go from Palantir curiosity to the default way AI companies ship. This is the guide I'd give someone deliberately aiming at it.

What the job actually is

Strip the title down and an FDE is an engineer whose deliverable is a working deployment, not a merged PR. You sit at the intersection of the product and one specific customer, and you own the gap between them: the missing integration, the workflow the product almost supports, the prompt that needs to speak the customer's language, the ops team that needs to trust the thing before they'll route traffic to it.

On any given week that can mean writing a CRM connector, debugging ASR accuracy on terrible call audio, running a workshop for skeptical stakeholders, tuning an escalation policy, and writing the field report that changes what the product team builds next quarter. It is not a support role with a better title, and it's not sales engineering with more code. The demo is the SE's finish line; it's the FDE's starting line.

Why AI made this role explode: traditional software either fits or it doesn't, but AI systems are probabilistic and every customer environment shifts their behavior. Different data, different vocabulary, different workflows, different failure tolerances. Someone technical has to be present where the probability distribution meets the business requirement. That's the job.

The skill stack: three legs, and the stool falls without any of them

Leg one: full-stack shipping ability. Not "full-stack" as in knows React and Node — full-stack as in can carry a problem from idea to running-in-production alone. In the field there is no backend team to hand off to. You'll touch APIs, auth, queues, webhooks, a bit of infrastructure, a bit of frontend for the dashboard the customer suddenly needs. My own daily tools are TypeScript/NestJS and Python on AWS, but the specific stack matters far less than the property: when something is broken at the customer site, you are the person who fixes it, whatever layer it's in.

Leg two: LLM systems literacy. Not model training — systems. Prompting that survives real users. Tool calling and agent loops. RAG and when not to bother. Evals, because "it seems better" is not a deployment argument. Latency engineering, especially if you go anywhere near voice, where the entire product lives inside an 800ms budget. Failure modes: hallucination, injection via tool output, loop thrash, cost blowups. The FDE is the person in the room who knows what the model can be trusted with, and — more valuably — what it can't. I've written up most of what I know here in my production agents field guide.

Leg three: customer skills. The leg engineers most want to skip, and the one that actually differentiates. It decomposes into learnable parts: extracting what a customer needs from what they say (rarely the same thing); explaining a probabilistic system honestly to a non-technical executive without hype or hedging; delivering bad news early with a plan attached; and navigating the org chart — because the champion who bought the product, the ops manager whose team it disrupts, and the IT lead who controls your API access are three different people with three different definitions of success. You need all three on side.

The honest self-assessment: most engineers have one strong leg and one decent one. The third is usually customer skills, and the good news is it responds to deliberate practice faster than either of the others.

Building proof: ship something real, end to end

You can't credential your way into this role, and that's its greatest feature — the proof of ability is available to anyone without permission. The proof is: you shipped an AI system that real people used, and you can talk concretely about what broke.

What that looks like in practice:

Build one serious agent system end to end. Not a weekend LangChain demo — something with users, even a handful. A voice agent is the strongest choice I know, because it forces every hard problem at once: streaming pipelines, latency budgets, interruption handling, graceful failure. When I built a voice-agent mock-interview product — Pipecat and LiveKit for the pipeline and transport, Claude for reasoning, Deepgram in, ElevenLabs out — the model was honestly the easy part. The other ninety percent was exactly the engineering this job consists of.
Deploy it for someone who isn't you. A local business, a nonprofit, a friend's team. The moment a real user depends on it, you start accumulating the war stories that are this role's actual currency — the weird input, the integration that lied, the user who did the thing no one predicted.
Write about what broke. A handful of honest posts about failures and fixes signals field-thinking better than any list of frameworks. (This post is me eating my own cooking.)
Practice the demo. Being able to demo your own system live, narrate what it's doing, and recover smoothly when it misbehaves is a startlingly rare skill and a startlingly good predictor of field performance.

One real deployed system with users beats ten repos of tutorials. Depth is the signal; breadth is noise.

What interviews actually probe

FDE interviews are recognizable once you know what each round is really asking:

The build round. Practical, integration-flavored: wire an API to a model, build a small tool-using agent, debug a broken pipeline. They're watching how fast you get to working, not how elegant your abstractions are.
The war-story round. "Tell me about a deployment that went sideways." They want specifics — the actual failure, what you did at each fork, what you'd do differently. Vague answers end candidacies here. This round is precisely why building real proof matters: you can't fake having been in the field.
The customer simulation. An interviewer plays a frustrated or non-technical stakeholder; sometimes it's "explain why the agent gave a wrong answer, to someone whose job depends on it not doing that." They're probing whether you can be honest, calm, and useful simultaneously — under-promising without underselling.
The judgment round. Scoping and trade-offs: "the customer demands a feature that would fork the core product — what do you do?" (I have strong opinions on that one.) "How would you decide if this use case should be automated at all?" There are no right answers, only well-reasoned ones.

The consistent thread: they are hiring for judgment under ambiguity, with code as the medium. Pure algorithmic brilliance without customer instinct fails these interviews; so does smooth talking without the ability to ship. The bar is the intersection.

Why builders with customer empathy win

The long-term case for this career comes down to positioning. Models keep improving and keep commoditizing — whatever raw capability you're impressed by today will be table stakes in eighteen months. What doesn't commoditize is the last mile: understanding a specific business deeply enough to make probabilistic software genuinely work inside it, and feeding what you learn back into the product. That skill compounds across every deployment you do.

FDEs also accumulate a rare portfolio: real deployments, real stakeholder relationships, real P&L-adjacent outcomes. It's the natural on-ramp to founding a company, to product leadership, or to the most senior IC roles — because you've spent years watching, up close, exactly where software value is created and destroyed.

The engineers who win this era aren't the best pure builders or the best pure communicators — they're the ones who can sit with a customer in the morning and ship the fix in the afternoon. If that sentence sounds like fun rather than a chore, you're the target audience for this role.

Ship something real. The rest follows.

Related reading

The FDE Feedback Loop: Turning Deployment Pain Into Product
Building Production AI Agents in 2026
See what I've built, or get in touch if you're hiring for the field.