AI is changing more than the software engineers build. It is changing where they work, how closely they work with customers, and what it takes to get a solution into production. That is why the Forward Deployed Engineer, or FDE, is attracting so much attention.
A Forward Deployed Engineer does not simply hand over a product and wait for a customer to configure it. This engineer gets close to the customer’s environment, identifies the real problem, writes code that fits existing systems, and helps make the result reliable enough for daily use. The job combines technical execution with business understanding and product judgment.
The role makes the most sense when I follow a concrete example: a company asks for an AI agent to help investigate incidents. The request sounds straightforward. Making it useful inside that company, with its own data, permissions, workflows, and security rules, is the actual engineering challenge.
Key Takeaways
- A Forward Deployed Engineer implements a product inside a customer’s real environment, not just in a demo.
- The role combines software engineering, business discovery, and product feedback.
- The six-stage workflow runs from discovery through production deployment and reusable product learning.
- Success depends on a measurable customer outcome and a solution people can rely on.
What Is a Forward Deployed Engineer?
A Forward Deployed Engineer is a customer-facing software engineer employed by a product company. Rather than working only on the product in isolation, the engineer helps implement it within a client organization. That can mean working alongside the client’s employees for a defined period, sometimes directly in their office and always close to their technical and organizational realities.
The term is associated with Palantir, which used it for engineers working closely with customers on complex deployments. “Forward deployed” borrows the idea of being stationed near the action. In software, the action is where a product meets real data, existing infrastructure, internal processes, and the people who depend on them.
That distinction matters. A product may perform beautifully with sample data yet fail to answer a customer’s most important question. A Forward Deployed Engineer closes that gap by discovering what the customer needs and making the product work in the environment the customer actually has. The outcome is not merely a convincing prototype. It is a solution that solves a valuable problem and can be operated in production.
Why AI Is Bringing the Role Into Focus
The Forward Deployed Engineer role is not new, but AI has made its value much easier to see. Many companies can now access powerful AI tools. Far fewer can connect those tools to their own systems, design a useful workflow around them, satisfy security requirements, and support the result when people rely on it.
That is why selling an AI platform and telling customers to build everything themselves often leaves a difficult last mile. The customer still has to determine which problem is worth solving, where the required information lives, what the agent may access, and how to measure success. A Forward Deployed Engineer works through those questions with the customer and then builds against the answers.
Major technology companies have been investing in teams that work directly with customers on AI implementation, while companies such as OpenAI, Anthropic, Palantir, and Salesforce have hired for related roles. I also find the demand visible in job searches across locations, including Bengaluru and the San Francisco area. The important signal is not a fashionable title. It is the need for engineers who can turn promising technology into working customer outcomes.
The Three Hats a Forward Deployed Engineer Wears
I think of the job as three responsibilities carried at the same time. If one is missing, the deployment suffers.
Software engineer: I write real code using the customer’s systems and tooling. A demonstration on dummy data can help test an idea, but it does not replace production engineering. Connectors, permissions, error handling, and reliability all become part of the work.
Business consultant: I learn the customer’s domain, map how work happens today, and translate a broad complaint into a technical problem with a measurable result. That prevents me from building an impressive feature that does not address the underlying pain.
Product manager: I bring lessons from the deployment back to my company’s product team. If a difficulty appears across customers, the best response may be a reusable product capability rather than another one-off customization.
A strong Forward Deployed Engineer moves between these hats constantly. A conversation about business priorities may reveal a missing data connection. An integration problem may expose a product limitation. A production failure may change which feature deserves attention next. The role sits at the intersection of engineering, product, customer needs, and business results, so success depends on seeing how those pieces affect one another.
A Six-Stage Forward Deployed Engineer Workflow
To make the responsibilities practical, I use an incident-investigation scenario. A customer wants an AI agent for incidents. The work follows six stages: discovery, embedding, prototyping, integration, productionization, and feedback. Each stage changes the question I need to answer. Skipping ahead might produce a quick demo, but it can also leave the hardest problems untouched.
1. Discover the Problem Before Writing Code
The customer’s opening request is simple: it needs an AI agent for incidents. My first move should not be to open an editor and build a generic agent. I would talk with the site reliability engineers, understand how they investigate incidents today, identify the systems involved, and ask where time is being lost.
Then I would agree on a success measure. In this example, the useful goal is to reduce incident investigation time from 45 minutes to under 10 minutes. That changes the project immediately. Instead of asking, “Can I build an agent?” I can ask, “Can this workflow give an engineer the context needed to investigate substantially faster?”
Discovery is not a delay before the real work. For a Forward Deployed Engineer, it determines what the real work is. The conversations reveal which information matters, who uses it, and how I will know whether the solution helped.
2. Embed in the Customer’s Environment
Now the customer explains the constraints. Logs are in Datadog, incidents are tracked in Jira, ownership information lives elsewhere, and security requires data to remain inside its virtual private cloud, or VPC. These details are not inconvenient footnotes. They define the architecture.
I would not ask the customer to migrate everything to my preferred stack just to make implementation easier. I also would not ignore security for a demo and hope to solve it later. I would work with the customer’s security and platform teams to design an integration that respects the VPC requirement and connects to the systems people already use.
This is where “deployed” becomes meaningful. A Forward Deployed Engineer works inside the customer’s technical and organizational constraints. APIs matter, but so do approvals, ownership, and the people responsible for operating the result. A solution that cannot fit those realities is not ready for this customer.
3. Prototype a Thin, Useful Slice
The customer wants to see something working this week. That creates pressure to build quickly, but speed does not mean building the biggest possible interface. I would choose one narrow workflow: take an incident, assemble relevant context from logs and deployments, and show a likely cause that an engineer can investigate.
That thin slice is more useful than a polished generic dashboard with many features. It tests whether the proposed experience helps with the specific investigation problem. It also reveals integration difficulties while the scope is still small enough to change. Waiting for the core product team to deliver every requested feature would miss the opportunity to learn quickly alongside the customer.
A good Forward Deployed Engineer uses the prototype to answer a focused question: does this approach have a credible path from the customer’s request to a measurable improvement? The prototype is evidence for the next decision, not a substitute for the remaining engineering work.
4. Integrate Real Systems and Permissions
Once the demonstration works, the customer asks the question that separates a prototype from a deployment: can it work with real services and permissions? Mock data proved that the experience was possible. It did not prove that the agent can retrieve the right information safely or handle the customer’s actual workflows.
At this stage, I would implement real connectors, map services and ownership correctly, account for access permissions, and add error handling. The agent’s response is only as useful as the context it can reach. If ownership data is wrong or a connector fails without a clear signal, an apparently helpful answer can send an incident investigation in the wrong direction.
This is the point where the Forward Deployed Engineer’s two kinds of knowledge come together. I need software engineering skill to connect and handle the systems, and customer context to understand what those connections mean. Handing over the prototype and leaving would abandon the most consequential part of the job.
5. Productionize for People Who Depend on It
The next question raises the stakes: can 200 engineers depend on this during a serious incident? My priority would no longer be adding more AI features. I would focus on tests, monitoring, safeguards, fallbacks, access controls, and rollout gates. The solution should be observable and maintainable, not merely functional in a controlled demonstration.
Incident response is a demanding setting because failures matter most when teams are already under pressure. If a connector is unavailable, an engineer needs to know that the context is incomplete. If access is restricted, the system needs to respect that restriction. If the new workflow is not yet dependable, the rollout should not immediately include everyone.
A Forward Deployed Engineer cannot stop at “it works on my laptop.” Productionization means preparing for real users, real failures, and the responsibility that comes with both. That work is what makes the customer comfortable expanding the deployment beyond its initial use case.
6. Feed the Learning Back Into the Product
After deployment, the customer points out that the ownership-context problem is not unique to its organization. It appears across enterprise customers. I would document the pattern, measure the impact of the solution, and bring the finding to the core product engineering team.
That does not mean copying every customer-specific change into the product. It means distinguishing between a local requirement and a reusable capability. The customer’s particular systems may be unique, while the need to assemble trustworthy ownership context during an incident may be broadly shared. Capturing that distinction helps the product improve without becoming a collection of disconnected custom deployments.
This feedback loop makes the Forward Deployed Engineer a two-way bridge. I take product capabilities into the customer’s environment, then take lessons from that environment back into product development. If I move to the next customer without documenting what worked and what was missing, I lose half the value of being close to the problem.
What a Successful Deployment Actually Demonstrates
In the interactive scenario, the completed mission reports that incident investigation dropped from 45 minutes to 8 minutes. It also ends with a score of 100 out of 100 as customer trust, technical fit, and production readiness improve. Those figures are the outcome of the example scenario, not a claim about a real customer deployment. They illustrate what I would want to measure in an actual project.
The score alone would not satisfy me. I would ask whether the improvement holds after rollout, whether engineers trust the information, whether the integration remains healthy, and whether the customer’s team can maintain the workflow. The useful lesson is that a Forward Deployed Engineer owns the path from an initially vague request to a measurable, production-ready result. Writing code is essential, but the code has to survive contact with the customer’s environment.
Here is my interactive Forward Deployed Engineer (FDE) role-play playground.
Forward Deployed Engineer Roadmap: Seven Skills to Build
An FDE needs enough engineering depth to build and debug software, enough curiosity to uncover what the customer actually needs, and enough ownership to stay with the solution until it delivers value. Here is the roadmap I would follow.
What Does a Forward Deployed Engineer Do?
A forward deployed engineer works closely with a customer, often at the customer’s site. The work begins with understanding the problem. From there, the engineer creates a prototype, develops the application or workflow, integrates it with the customer’s product or systems, and deploys it to production.
The important part is what happens after the prototype. A promising demonstration is not the finish line. The solution needs to run reliably, address the customer’s pain point, and satisfy the people who will use it. That may take several rounds of feedback and improvement.
This is why I would not treat FDE as a completely new branch of engineering. It brings familiar skills together in a demanding setting where technical decisions and customer conversations are closely connected.
1. Build Your Engineering Foundations
The first requirement is straightforward: you need to know how to code. Coding assistants can help you move faster, but they do not replace your ability to understand what a system is doing or fix it when something breaks.
I would make sure I am comfortable with APIs, Git, databases, and the basics of cloud platforms such as AWS, Azure, or Google Cloud. These are the building blocks you are likely to encounter when working with an existing product rather than a clean project of your own.
Do not aim only to recognize these terms. Practice using them together. Can you read an API, work with a codebase, store and retrieve data, and understand where an application runs? Those foundations make every later step easier.
2. Learn to Build Real Software
An FDE must be able to turn an idea into a working application. That means understanding both backend and frontend development, even if you are stronger in one area.
The backend handles the logic, data, and connections that make a solution work. The frontend gives people a way to use it. When you can work across both, you can build a prototype quickly and see whether it solves the customer’s problem.
Tools such as Claude Code, Codex, and other coding assistants can speed up this work. I would use them as accelerators, not as a substitute for engineering judgment. You still need to know whether the generated code fits the requirement, connects to the right systems, and can be maintained after the first version.
3. Develop Practical AI Engineering Skills
AI skills matter in many of the current conversations around forward deployed engineering. It is useful to understand how to build an AI agent, define the skills it needs, and give it access to tools so it can carry out a task.
That includes learning about tool calling and the Model Context Protocol, or MCP. These concepts become more valuable when you connect them to a customer problem: what should the agent be able to do, what information does it need, and where should its behavior be limited?
I would focus on building an agentic workflow that serves a clear purpose rather than adding AI because it sounds impressive. A small workflow that addresses a genuine pain point is more useful than a complicated prototype with no path into the customer’s product.
4. Get Good at Integration Engineering
Building something is one skill. Making it work inside a customer’s existing environment is another.
A forward deployed engineer needs to connect new applications and AI workflows to the client’s product and systems. That can involve APIs, data, and the practical constraints of software that is already in use. A solution may work perfectly on its own but still fail to help anyone if it cannot fit into the customer’s workflow.
This is why I would practice integration early, not leave it until the end. When you build a prototype, ask how it would connect to an existing application. Think through the information it needs, what it produces, and how someone would use that output in their daily work.
5. Practice Customer Discovery
Strong technical skills will only take you so far if you solve the wrong problem. An FDE needs to ask good questions, listen carefully, and find the pain point behind the initial request.
A customer may describe a feature they want, but your job is also to understand why they want it. What is not working today? Who is affected? What would a successful outcome look like? The answers help you decide what to build first and how to judge whether it works.
I would treat discovery as an engineering skill, not as a separate sales conversation. It gives direction to the prototype and helps define a practical roadmap. It also makes later feedback more useful because you have a shared goal to return to.
6. Take Production Engineering Seriously
A prototype can show that an idea is possible. Production engineering shows whether the solution is dependable enough to use.
For an FDE, that means thinking about security, observability, reliability, debugging, and appropriate safety guardrails. These are not finishing touches to consider only after the customer likes the demo. They are part of making the application work properly in the customer’s environment.
For example, if something fails, you need a way to understand what happened and fix it. If the application handles customer information, security matters from the start. If an AI agent can call tools, its behavior needs sensible boundaries. Resources such as the AWS Well-Architected Framework provide useful background on the broader principles behind reliable and secure systems.
You do not need every possible safeguard in an early prototype. You do need to know what must change before that prototype becomes a production application.
7. Own the Full Customer Delivery Cycle
The last skill ties the others together: stay accountable for the outcome. My simple model for the FDE workflow is:
- Understand the customer’s problem and define what success means.
- Build a prototype that tests a useful solution.
- Integrate it with the customer’s product or environment.
- Deploy it to production with the necessary reliability and safety measures.
- Iterate on feedback until the customer is satisfied.
That final step matters. Deploying code does not automatically mean the work is done. The application needs to solve the problem it was built for, and the customer needs confidence that it works. Only then has the engineer completed the job.
How I Would Prepare for an FDE Role
I would approach this roadmap in the same order as the work itself. First, strengthen the software engineering basics. Then build complete applications, including their backend and frontend. Add AI agents and tool integrations where they are useful. Finally, practice taking those applications beyond a standalone prototype: connect them to other systems, think through production concerns, and explain the customer problem they solve.
The key is to develop the skills together. A forward deployed engineer is not just the person who can build fastest or talk to customers most confidently. It is the person who can move between both worlds, make sound decisions, and keep going until a working solution is in place.
If you are considering an FDE role, that is how I would work toward: understand the problem, build the right thing, integrate it, ship it, and improve it until it works for the customer.
