How to Become a Forward Deployed Engineer: Full Guide

Forward deployed engineers are becoming one of the most important roles in AI adoption because companies do not just need software to be installed. They need AI systems to work inside real business processes.

That is a different problem.

A software rollout asks: does the product run?

An AI agent rollout asks: does this system understand the workflow, use the right data, follow the right permissions, produce useful output, handle edge cases, and improve as people use it?

That is why the forward deployed engineer, or FDE, is moving from a niche title associated with Palantir-style deployments into a broader role across AI companies, cloud platforms, enterprise software vendors, and implementation teams.

Aaron Levie captured the shift in a May 2026 post, arguing that forward deployed engineers, or equivalent roles, are likely to become one of the most in-demand jobs in tech and one of the most important functions for AI rollouts. His reasoning was simple: deploying agents is often more involved than deploying software because the customer expects the system to perform work, not just expose features.

The market is already moving that way. OpenAI describes forward deployed engineers as people who lead complex end-to-end deployments of frontier models in production with strategic customers. Anthropic describes the role as embedding with strategic customers to drive transformational AI adoption. Google Cloud has listed forward deployed engineer roles focused on production-grade AI systems, cloud architecture, RAG-like data pipelines, multi-agent systems, tracing, and cost-per-request optimization.

This guide explains how to become a forward deployed engineer, what the role actually does, which skills matter, what to build in your portfolio, how companies should think about the function, and why AI rollouts increasingly need FDE-style ownership.

Key takeaways

• A forward deployed engineer turns technical capability into working customer outcomes.
• In AI, the role is shifting from software implementation to workflow deployment, eval design, integration, permissions, adoption, and continuous tuning.
• The strongest FDEs combine software engineering, systems design, data integration, AI fluency, customer discovery, and business-process judgment.
• The fastest path into the role is to build production-like projects that prove you can take a messy workflow from discovery to deployed system.
• Companies do not always need the exact FDE title, but they do need FDE-style ownership when deploying AI agents into real work.
• Espressio acts like a forward deployed AI systems team for companies that need AI agents to work in production, not just in demos.

What is a forward deployed engineer?

A forward deployed engineer is a technical builder who works close to customers, users, or internal operators to solve business problems with software. Instead of building only from a product roadmap, the FDE embeds near the actual workflow, understands the customer environment, scopes the technical solution, builds or configures it, ships it, and keeps improving it from real usage.

Traditional software engineers usually work from product requirements. Solutions engineers often help sell, configure, or explain a product. Implementation consultants often manage deployment, onboarding, and change management.

A forward deployed engineer sits between those roles.

They can write code, design systems, talk to customers, debug production issues, translate vague operational pain into technical requirements, and tell the product team what the market is actually asking for.

In AI, that mix matters even more. The deployment is not just a dashboard, API, or workflow automation. It may be an agent that drafts sales follow-ups, routes support tickets, performs account research, summarizes calls, builds reports, or prepares campaign assets. The output is work. That means the FDE has to understand how the work is judged.

Why forward deployed engineers are suddenly in demand

Forward deployed engineering is rising because AI adoption has a last-mile problem.

The models are powerful. The demos are impressive. The APIs are accessible. But most companies still struggle to turn AI into reliable operating systems. Their data is spread across CRMs, docs, Slack channels, spreadsheets, support tools, and analytics platforms. Their approval rules are informal. Their workflows rely on context stored in people’s heads. Their teams know what good output looks like, but they have not written it down in a way a system can use.

That is where FDE-style work becomes valuable.

OpenAI’s FDE job description says the role owns discovery, technical scoping, system design, build, and production rollout. Anthropic’s Applied AI FDE description emphasizes embedding with strategic customers to understand workflows and develop AI applications that solve real business challenges while maintaining safety and reliability. Google Cloud’s FDE listings mention production-grade AI systems, cloud architecture, RAG-like data pipelines, multi-agent frameworks, tracing, tokens per second, and cost per request.

Those are not generic support tasks. They are production AI deployment tasks.

The same pattern appears in enterprise-agent infrastructure. In Espressio’s guide to deploying AI agents on AWS Bedrock, the production stack is not just one agent. It has specialist agents, orchestration, governance, observability, scoped permissions, policy guardrails, and human sign-off. The teams that skip those layers usually stall before scale.

That is the new FDE job: make AI useful under real operating conditions.

What forward deployed engineers actually do

A forward deployed engineer owns the messy middle between a promising capability and a working deployment.

The exact job varies by company, but the loop usually looks like this.

Forward deployed engineering turns workflow discovery, integrations, evals, production rollout, and adoption feedback into one operating loop.

1. Discover the workflow

The FDE starts by understanding how the work happens today. Who owns the process? What triggers it? What inputs are needed? Which tools are involved? What output is considered good? Where do mistakes happen? Which decisions require a human?

This is where many AI projects fail. Teams choose a model before they understand the work. A good FDE reverses that order.

Espressio’s own AI automation guidance starts the same way: identify a high-pain, low-risk process, map the current workflow, then choose the right automation layer. The tool comes after the workflow.

2. Translate business pain into technical scope

Customers often describe symptoms, not requirements.

A sales leader might say, “our reps are slow to follow up.” The FDE has to turn that into a specific workflow: which CRM fields matter, which deal-stage changes should trigger action, which emails need human approval, which tasks should be logged, and what success metric proves the system works.

That translation layer is why FDEs need business judgment, not only coding ability.

3. Build the first usable version

An FDE is expected to ship. That might mean writing full-stack code, building an internal tool, connecting APIs, setting up a workflow in n8n, creating a RAG pipeline, configuring a model, or building an evaluation harness.

The important point is that the first version should solve a real workflow, not just demonstrate a capability.

A good first deployment is narrow. It handles one painful path well. It gives users something they can test against real work.

4. Connect the data and tools

AI systems become useful when they can access the right context and act in the right place.

That may mean connecting to HubSpot, Salesforce, Slack, Google Drive, Notion, Airtable, AWS, internal databases, analytics tools, or support platforms. It also means respecting permissions. A user who cannot see an enterprise pipeline inside the CRM should not magically access it through an AI interface.

In Espressio’s Claude and HubSpot workflow, the useful version is not “Claude writes an email.” The useful version reads deal context, pulls last activity, drafts a follow-up, creates a HubSpot task, and lets the human decide what to send.

That is FDE thinking: the system lives where the work lives.

5. Design evals and review gates

AI systems need different testing from ordinary software. Unit tests still matter, but they are not enough. You also need examples of good and bad outputs, edge cases, quality criteria, human review points, and monitoring for drift.

For an AI sales follow-up workflow, evals might check whether the draft uses accurate CRM context, avoids invented claims, includes one clear next step, and respects tone guidelines. For a content workflow, evals might check source grounding, brand voice, factual accuracy, and approval status.

Review gates matter because many AI systems should not act fully autonomously at first. The agent can draft, summarize, rank, recommend, or prepare. A human approves before the final customer-facing action.

6. Manage rollout and adoption

A technically correct system can still fail if nobody uses it.

FDEs have to think about delivery surface. Should the workflow live in Slack, the CRM, a custom dashboard, a scheduled report, or an existing internal tool? Does the user need training, or should the interface make the next action obvious? Does the output save time immediately, or does it create more review work?

In the Lunar Strategy AI operating system built with Espressio, adoption improved when account managers received tested working tools instead of training decks. The team did not need to chase separate AI tools. They worked from one operating system that encoded client knowledge, service-line workflows, and institutional memory.

That is the standard FDEs should aim for: the system should fit the team, not the other way around.

7. Feed learning back into the product or system

Because FDEs work close to real users, they see what the product team cannot see from a roadmap alone. They notice missing integrations, confusing workflows, weak model performance, permission gaps, recurring edge cases, and usage patterns.

The best FDEs turn that field learning into better product decisions, stronger templates, reusable architecture, and sharper deployment playbooks.

Forward deployed engineer vs software engineer vs solutions engineer

These roles overlap, but they are not the same.

Role	Primary focus	Typical strength	Common gap
Software engineer	Build product or platform features	Code quality, architecture, scalability	May be far from customer workflow
Solutions engineer	Help customers understand and configure a product	Demos, technical sales, customer communication	May not own deep production buildout
Implementation consultant	Manage onboarding and rollout	Process, training, change management	May not write production code
AI engineer	Build AI applications and model-powered systems	LLM apps, RAG, agents, evaluation	May not own customer adoption
Forward deployed engineer	Ship technical solutions inside real workflows	Builder plus operator plus customer partner	Requires comfort with ambiguity and context switching

A forward deployed engineer is not “less technical” than a software engineer. In many AI deployments, the FDE needs to be technical across more surfaces: cloud, APIs, data pipelines, model behavior, evaluation, frontend or internal tooling, security, and observability.

The difference is proximity to the problem. FDEs build with the customer environment in view.

The forward deployed engineer skill stack

The role rewards T-shaped people: deep enough technically to build, broad enough operationally to deploy.

A strong FDE combines engineering, AI systems, data integration, evaluation, customer discovery, and product judgment.

Software engineering fundamentals

You do not need to be a distributed-systems expert for every FDE role, but you do need to build reliable software.

Useful skills:

• Python or TypeScript
• API design and consumption
• Basic full-stack development
• Cloud deployment on AWS, GCP, or Azure
• Authentication and authorization basics
• Databases and data modeling
• Error handling, logging, and monitoring
• Git, CI/CD, and production debugging

For AI-focused FDE roles, Python is especially useful because much of the AI tooling ecosystem lives there. TypeScript is useful for building internal tools, web apps, and workflow interfaces.

AI systems and agents

Modern FDEs need to understand how AI systems behave in production.

Useful skills:

• Prompt design and prompt versioning
• RAG and vector databases
• Tool calling and function calling
• Multi-agent patterns with frameworks like LangGraph, CrewAI, or similar systems
• Model selection and routing
• Context-window management
• Cost, latency, and throughput tradeoffs
• Hallucination and uncertainty handling
• Human-in-the-loop workflow design

You do not need to be an ML researcher. You do need to know how to turn models into reliable workflows.

Data and integration architecture

Most AI rollout problems are actually data and integration problems.

Useful skills:

• Structured and unstructured data pipelines
• CRM, support, analytics, and productivity-tool APIs
• Webhooks and event-driven workflows
• OAuth and scoped permissions
• RAG data preparation
• Data freshness and source tracing
• PII and compliance basics

A model with poor context creates poor output. A model with the wrong permissions creates risk. A model disconnected from the workflow creates a side tool nobody uses.

Evaluation and observability

Evals are one of the most important skills for AI FDEs.

Useful skills:

• Building test sets from real examples
• Defining pass/fail quality criteria
• Error analysis
• Measuring cost, latency, and output quality
• Tracing model and agent decisions
• Monitoring drift and recurring failure modes
• Creating review queues for uncertain outputs

This is the difference between a demo and a deployment. A demo can work once. A deployed AI system needs to keep working when inputs are messy.

Customer discovery and communication

FDEs need to ask better questions than “what should we build?”

Useful questions:

• What work happens before and after this step?
• What does a good output look like?
• Who reviews it today?
• What mistakes are unacceptable?
• What data does the team trust?
• Where does the workflow break under volume?
• Which metric would prove this system is worth keeping?

The best FDEs can explain technical tradeoffs to nontechnical stakeholders without hiding the complexity.

Product and business judgment

An FDE has to know when not to build.

Sometimes the right answer is a prompt template. Sometimes it is a Zapier or n8n workflow. Sometimes it is a custom agent. Sometimes the process is too vague to automate yet.

Espressio’s AI automation framework uses three layers: prompt-based automation, workflow automation, and custom AI agents. Choosing the right layer is part of the job.

How to become a forward deployed engineer

There is no single path into forward deployed engineering. The role is usually easier to enter if you already have one side of the skill stack and deliberately build the other.

Path 1: software engineer to FDE

If you are a software engineer, your advantage is build credibility. You can ship. Your gap is usually customer discovery, business-process mapping, and comfort with ambiguous requirements.

What to do:

• Spend more time with users, customer calls, sales calls, support tickets, or implementation teams.
• Build projects that start from a real workflow, not a toy app.
• Practice turning vague business pain into a scoped technical plan.
• Learn how to present tradeoffs, not just code.
• Build AI projects with evals, logging, and permissions.

Path 2: solutions engineer to FDE

If you are a solutions engineer, your advantage is customer fluency. You know how to explain, demo, and map needs. Your gap may be deeper production engineering.

What to do:

• Learn Python or TypeScript deeply enough to build working systems.
• Move beyond demos into deployed internal tools.
• Build API integrations with real write-back.
• Learn cloud basics, auth, logging, and error handling.
• Create a portfolio that proves you can ship, not just advise.

Path 3: ML or data engineer to FDE

If you are an ML or data engineer, your advantage is data and model fluency. Your gap may be customer-facing delivery and product judgment.

What to do:

• Build applications around workflows, not just models.
• Practice explaining model limits in business language.
• Learn frontend or internal-tool basics so users can actually use what you build.
• Add human review and adoption metrics to your projects.
• Work on projects with messy real-world data.

Path 4: founder or operator to FDE

If you have built a company, run operations, or owned a revenue process, your advantage is business context. Your gap may be formal engineering depth.

What to do:

• Learn enough coding to build API-driven workflows.
• Use your own operational pain as project material.
• Build tools that save measurable time in a real process.
• Learn model APIs, workflow automation, and database basics.
• Document the before and after state clearly.

A 90-day roadmap to become FDE-ready

You do not become a strong FDE by watching tutorials alone. You become one by taking a messy workflow from problem to deployed system.

A practical 90-day path: map a real workflow, build a production-like system, then prove adoption with evals and metrics.

Days 1 to 30: learn the role and build the foundation

Focus on understanding the role and building core technical fluency.

Do this:

• Read FDE job descriptions from OpenAI, Anthropic, Google, Palantir, and similar companies.
• Learn one backend language well enough to build APIs. Python is a good default.
• Learn one workflow automation tool like n8n, Make, or Zapier.
• Learn the basics of LLM APIs, tool calling, RAG, and structured outputs.
• Study one business workflow deeply, such as CRM follow-up, support triage, content briefs, reporting, onboarding, or account research.

Deliverable by day 30:

A written workflow map that shows inputs, steps, decisions, owners, tools, outputs, risks, and success metrics.

Days 31 to 60: build a production-like workflow

Now build something real enough to break.

Pick one workflow and create a working system with:

• A trigger, such as a form submission, deal-stage change, Slack command, or scheduled report.
• A data source, such as a CRM, spreadsheet, document folder, or database.
• An AI step that performs a bounded task.
• A review gate before any external action.
• Logging that shows what happened.
• A simple evaluation set with expected outputs and failure cases.

Deliverable by day 60:

A working demo that solves one workflow end to end, plus a short technical write-up explaining architecture, tradeoffs, and failure modes.

Days 61 to 90: package proof and practice customer scenarios

The final month is about proving that you can think like an FDE, not just build like an engineer.

Do this:

• Test your system against real or realistic examples.
• Add edge cases and document how the system handles them.
• Measure time saved, error reduction, or review quality if possible.
• Create a before-and-after workflow diagram.
• Write a deployment memo: who uses it, what permissions it needs, what can go wrong, what needs human approval, and how to expand it.
• Practice explaining the system to both an engineer and a business stakeholder.

Deliverable by day 90:

A case-study-style portfolio piece with problem, workflow, architecture, evals, rollout plan, metrics, and next steps.

Portfolio projects that prove FDE readiness

You do not need a famous client to prove you can do FDE work. You need projects that look like deployment work, not toy demos.

Here are five strong project types.

1. CRM follow-up agent with human approval

Build a workflow that detects a CRM event, pulls deal and contact context, drafts a follow-up, and creates a task for a human to approve.

What it proves:

• API integration
• Customer workflow understanding
• Permission awareness
• Human review design
• Business metric thinking

This mirrors the logic in Espressio’s Claude and HubSpot follow-up guide: the value is not that AI can write an email. The value is that it can use live deal context, preserve human judgment, and write back into the system where sales work happens.

2. Support triage and escalation workflow

Build a system that reads support tickets, classifies urgency, suggests a response, and escalates uncertain or high-risk cases.

What it proves:

• Classification
• Routing
• Edge-case handling
• Review queues
• Operational reliability

3. Internal knowledge assistant with permissions

Build a knowledge assistant that answers questions from approved documents and shows sources. Add permission boundaries so different users can access different material.

What it proves:

• RAG architecture
• Source grounding
• Access control
• Trust and safety thinking

4. Weekly reporting assistant with source tracing

Build a system that pulls metrics from analytics tools or spreadsheets, creates a weekly summary, flags anomalies, and links every number back to its source.

What it proves:

• Data integration
• Source handling
• Business communication
• Repeatable reporting

5. Marketing brief or content workflow with review gates

Build a workflow that takes campaign inputs, generates a structured brief, posts it into Slack or a doc, and routes it for approval.

What it proves:

• Workflow design
• Team adoption thinking
• Delivery surface judgment
• Structured output

Espressio’s Claude and Slack marketing brief guide uses the same principle: Slack works because it is already where the team operates. The best AI workflow is often the one that reduces context switching.

How FDE interviews usually test you

Forward deployed engineer interviews vary by company, but they tend to test five things.

Decomposition

You may be given a vague customer problem and asked how you would break it down.

Example:

“A bank wants to use AI to summarize relationship-manager calls and create next-step tasks. How would you scope the first deployment?”

A strong answer covers users, data sources, permissions, workflow steps, review gates, integrations, evals, risks, and success metrics.

System design

You may be asked to design an architecture for a workflow under real constraints.

For AI roles, include model choice, RAG or context strategy, tool calling, logging, evaluation, fallback behavior, cost, latency, and security.

Debugging

You may be asked what you would do when a deployment produces poor outputs.

A strong answer does not just say “improve the prompt.” It checks input quality, source freshness, retrieval behavior, examples, evaluation criteria, user feedback, model selection, permissions, and whether the workflow was scoped correctly.

Customer scenario roleplay

You may need to explain tradeoffs to a nontechnical stakeholder.

The interviewer wants to know whether you can build trust, ask clear questions, and avoid overpromising.

Portfolio review

If you have a project, expect questions about why you designed it that way, what failed, what you would change, how you measured quality, and how it would scale.

The failure discussion matters. FDEs operate in ambiguous environments. Companies want people who can learn from messy deployments.

Salary, companies hiring, and role titles to search

Forward deployed engineer compensation varies widely by company, seniority, location, travel expectations, and whether the role sits in product, applied AI, government, enterprise, or post-sales.

Rather than relying on a single generic salary range, check live job postings, Levels.fyi, employer pages, and recruiter conversations. OpenAI, Anthropic, Google Cloud, Palantir, Salesforce, and enterprise AI startups have all used FDE or FDE-adjacent language.

Search for these titles:

• Forward deployed engineer
• Forward deployed software engineer
• Forward deployed AI engineer
• Applied AI engineer
• Customer engineer, AI
• Field engineer, AI
• AI deployment engineer
• Solutions architect, AI
• Technical implementation engineer
• AI systems engineer

If you are a candidate, do not filter only for exact titles. Many companies need FDE-style work before they standardize the title.

If you are a company, do not get stuck on the label. The function matters more than the title: someone needs to own the path from workflow discovery to production adoption.

Is forward deployed engineering the right path for you?

FDE work is rewarding if you like building close to the problem.

It may be a fit if you enjoy:

• Talking to users and customers
• Turning ambiguity into scoped systems
• Shipping fast prototypes and improving them from feedback
• Working across engineering, product, sales, customer success, and operations
• Debugging business processes, not just code
• Traveling or spending time with customers, depending on the company
• Owning outcomes, not just tickets

It may not be a fit if you want:

• Long uninterrupted engineering cycles
• Clean requirements before you start
• Minimal customer interaction
• Work that is only platform or infrastructure focused
• A role with a narrow technical boundary

The role is not a step down from software engineering. It is a different kind of engineering role. The best FDEs are judged by deployed value, not just code output.

How companies should think about FDE-style AI rollout work

Companies deploying AI agents should ask a different question from “which model should we use?”

The better question is: who owns the workflow becoming real?

That owner needs to answer:

• Which workflow should we automate first?
• What data does the system need?
• Which tools should it read from and write to?
• What should require human approval?
• How will we evaluate output quality?
• What happens when the AI is uncertain?
• How will users adopt it inside their current work?
• What metric proves the system is worth keeping?

This is why FDE-style work is so important for AI. The model is only one part of the operating system.

Espressio takes this view in its own work. In the Lunar Strategy AI operating system, Espressio’s role was not simply to add AI tools. It was to help build an operating system across revenue, creators, PR, content, image workflows, and replies, with business logic, client knowledge, service-line workflows, and continuous model updates behind one interface.

That is forward deployed AI systems work: close enough to the business to understand the process, technical enough to build the system, and operational enough to make sure people use it.

FAQ

Do you need a machine learning background to become a forward deployed engineer?

Not always. Many FDE roles care more about software engineering, customer delivery, and AI systems implementation than ML research. You should understand how models behave, how to evaluate outputs, and how to build with LLM APIs, but you usually do not need to train frontier models.

Is a forward deployed engineer a real engineer?

Yes. The role can involve full-stack development, API integration, cloud architecture, data pipelines, evaluation systems, security constraints, and production debugging. The difference is that the work happens closer to customers and business workflows.

Is FDE just sales engineering?

No. Sales engineering usually supports technical evaluation and purchase decisions. FDEs often own post-sale or strategic deployment work from discovery through production. Some roles include pre-sales work, but the core value is building and deploying solutions.

How much travel does a forward deployed engineer do?

It depends on the company and customer segment. Some FDE roles are remote-heavy. Others require significant onsite time with enterprise or government customers. OpenAI’s SF FDE listing, for example, notes travel up to 50%. Always check the specific job description.

What should I build to get an FDE job?

Build a project that automates or assists a real workflow. A CRM follow-up agent, support triage system, internal knowledge assistant, reporting assistant, or Slack-based brief workflow is stronger than a generic chatbot. Include integrations, evals, review gates, logging, and a deployment memo.

What is the difference between an AI engineer and a forward deployed AI engineer?

An AI engineer builds model-powered systems. A forward deployed AI engineer builds those systems in direct contact with customer workflows and owns the path to adoption. The FDE has to care about the business process, user behavior, rollout, and measurable impact.

Can a company use an external partner instead of hiring FDEs?

Yes, especially early. Not every company needs a full internal FDE team on day one. Many need an FDE-style partner who can map workflows, build the first production system, set up evals and review gates, train the team, and help define what the internal owner should maintain after launch.

The bottom line

Forward deployed engineering is becoming more important because AI rollouts are not normal software rollouts.

When an AI agent enters a business process, the question is not just whether the system runs. The question is whether it does useful work with the right context, the right safeguards, the right integrations, and the right feedback loop.

That is the work FDEs are built for.

If you want to become one, build proof that you can take a messy workflow from discovery to production. Learn the technical stack, but do not stop there. Learn how work actually happens inside companies.

If your company is trying to deploy AI agents, treat forward deployed engineering as a function, not just a job title. Someone needs to own workflow mapping, integrations, evals, review gates, adoption, and tuning.

Espressio acts like a forward deployed AI systems team for companies that need AI agents to work in production. We help map the workflow, connect the data and tools, design the evals and review gates, ship the first usable system, and tune it as the team uses it.

If you are ready to move from AI demos to operating systems, get in touch with Espressio.