Forward Deployed Engineer: What the Role Is and What It Takes

A forward deployed engineer (FDE) is a software engineer who works inside a customer’s organization, ships working software on their real data, and owns whether it works.

Not a demo. Not a slide deck. Working software in production, for one customer, with your name on the result.

This post covers what the role involves, how it differs from a solutions engineer and a consultant, the skills that matter, a composite week, and how to build proof you can do it. I leave pay out on purpose. Other sites cover that. The work is the more useful question.

What a Forward Deployed Engineer Does

Palantir popularized the title. Its own description of the job is plain: a forward deployed software engineer is an engineer who embeds directly with customers to configure the company’s existing platforms to solve their toughest problems. Palantir also puts the split between roles this way: a product engineer’s focus is “one capability, many customers,” while a forward deployed engineer’s is “one customer, many capabilities.”

That one line is the role. You go deep on one customer’s problem and pull in whatever capability it takes.

In AI work, that usually means:

• Finding the real workflow. Sit with the people who do the work. Learn what they do, where it breaks, and what a good result looks like.
• Building on the customer’s data and systems. Connect to their tools, deal with their messy records and permissions, and write code that runs in their environment.
• Shipping something working, fast. A small version in front of real users beats a plan.
• Owning the outcome. If the agent gets it wrong, you find out why and fix it. If it works, you prove it with numbers.
• Feeding learning back. What you see in the field goes to the product team, or to the next project.

The a16z team describes why this matters for AI: agents “require active management, guided learning, and rich context,” and the forward deployed teams are closest to the customer. That fits what I see. A model is not the hard part. Getting it connected to the right data, with the right limits, and trusted by the people who use it, is the hard part.

It also explains the demand. Indeed data reported by Business Insider shows FDE job postings were 5,230% above January 2025 levels by April 2026, roughly 729% year over year. Treat that as a sign the title is hot, not as a measure of how many real jobs there are. Titles get stretched when a role gets popular.

FDE vs Solutions Engineer vs Consultant

These three get mixed up. The cleanest test is what they are measured on and what they leave behind.

Role	Main job	Measured on	Writes production code?	Stays after launch?
Forward deployed engineer	Build and run a working solution at one customer	The system works in production	Yes	Yes
Solutions engineer	Show the product fits and support the sale	Deals won, technical fit	Rarely, mostly demos and proofs of concept	Usually not
Consultant	Advise: analysis, strategy, recommendations	Deliverables accepted	Rarely	Usually not
Product software engineer	Build the core product for all customers	Product quality and roadmap	Yes	Not at one customer

Two notes.

First, the lines blur by company. Pragmatic Engineer’s look at FDE job ads found a mix. OpenAI’s ad says to embed with customers and co-develop solutions, while Ramp’s asks the engineer to work with sales and go-to-market teams to close deals. Same title, different jobs. Read the posting, not just the name.

Second, some “FDE” jobs are really solutions engineering or support under a trendier title. The a16z piece even notes that the role is sometimes rebranded as an implementation or solutions specialist. In the interview, ask: do you write and ship code on the customer’s systems? Do you stay after launch? Who owns the result?

If the answers are no, no, and “the customer,” it is not the role described here.

Skills That Matter

You do not need every skill on day one. You need a base in engineering, plus enough range to work with people.

Engineering core

• Solid software engineering: you can read unfamiliar code, write clean code, test it, and deploy it.
• Data work: SQL, APIs, messy file formats, simple pipelines.
• Enough cloud and security knowledge to work inside someone else’s environment and respect their rules.

AI-specific skills

• Building agents and retrieval systems that connect to real tools. Tool design and architecture basics matter.
• Evaluation: a test set, a pass bar, and a way to catch regressions.
• Judgment about when not to use an agent. Anthropic’s guidance on agents says to start with the simplest solution and add complexity only when needed, because agentic systems usually trade higher latency and cost for better performance. An FDE who reaches for an agent every time is a liability.

Customer skills

• Interviewing users and finding the real workflow.
• Writing a clear one-page plan and a clear weekly update.
• Saying no, kindly, to scope that will sink the project.
• Staying calm when requirements shift.

Ownership

• Defining success in numbers before you build. See success criteria for scale or stop.
• Knowing who owns the agent after you leave. The question of who owns the AI agent comes up on every real project.
• Handling failures: logs, rollbacks, and honest postmortems.

Escalating costs, unclear value, and weak risk controls are common ways agent projects stall. They are exactly what an FDE exists to prevent.

A Week in the Role

This is a composite, not a real person’s calendar. Details change by company and project.

Palantir’s own account of a day mentions designing, writing, and testing workflows, configuring the platform, and time reserved for meetings and stand-ups. Pragmatic Engineer reports that Palantir expects around 25% of FDE time onsite with customers, and Commure up to 50%. The split varies by company and project.

Here is a plausible week on an agent project:

• Monday. Review last week’s agent outputs with the customer’s process owner. Pick the three worst failures. Write the week’s plan.
• Tuesday. Fix the biggest failure: perhaps a tool call that returns the wrong record. Add the case to the test set.
• Wednesday. Sit with the people who use the agent’s output. Watch them work. Note what they correct.
• Thursday. Security and IT review: access, logging, data handling. Unblock the next integration.
• Friday. Ship the update to a small group. Send the weekly note: what changed, the numbers, what is next, what you need from them.

Notice what is missing: long periods of heads-down coding alone. The code is a fraction of the job. A lot of the work is meetings, reading, and building trust.

For how a fast, scoped project runs, see the one-week AI pilot methodology. The glossary has a short definition of forward deployed engineer.

How to Build a Portfolio

Hiring managers want proof that you ship, not proof that you took courses. Build three small things.

1. One agent on messy, real-shaped data. Pick a workflow you can describe, such as triaging support tickets or matching invoices to purchase orders. Use a public or synthetic dataset that is dirty on purpose. Follow the steps in how to build your first AI agent.
2. An evaluation suite for it. Fifty to a hundred cases, a pass bar, and a chart of before and after changes. This is the item most candidates skip.
3. A write-up like a customer would read. One page: the problem, the baseline, what you built, the measured result, what failed, and what you would do next. No jargon.

Then add the unglamorous parts: a README that lets a stranger run it, logging, a clear permission model, and an honest “limits” section.

Two more tips. Show a failure you found and fixed, with the before and after. And if you have domain experience (finance, healthcare, logistics), build in that domain. Knowing the work is a real edge.

Interview Signals

For candidates, expect questions that test judgment more than trivia:

• Walk through a project from first call to production.
• A customer’s data is worse than promised. What do you do?
• The sponsor wants more scope than fits. What do you say?
• How do you decide whether this needs an agent at all?
• Tell me about something you shipped that failed.

Strong answers share a pattern: they start with the user’s problem, name a measurable result, admit trade-offs, and show a specific action taken.

If you are hiring, watch for the opposite. Beware of people who only talk about models, who have never put anything in front of real users, or who cannot explain a failure.

As a candidate, also interview the company:

• Who owns the result at the customer?
• How much time is spent onsite or in customer meetings?
• Do FDEs write production code, or mostly demos?
• Is there a quota or sales target? (Some roles have one.)
• How do field lessons reach the product team?

Is the Role Right for You?

It fits you if you like ambiguity, enjoy talking to the people who do the work, and get a kick from seeing something you built used on Monday.

It may not fit if you want a stable roadmap, prefer working alone with clear specs, or dislike travel and customer pressure. Pragmatic Engineer’s review of job ads shows onsite time can be a quarter of the job or more at some companies, so ask early.

There is a real trade-off. You get range and fast learning. You also get context switching, shifting requirements, and being the person responsible when it breaks.

Bottom Line

A forward deployed engineer embeds with a customer, ships working software on their data, and owns the result. That is different from selling, advising, or building the core product.

Skills: solid engineering, AI building and evaluation, customer sense, and ownership.

Next step: build one small agent on messy data, test it with a real evaluation set, and write the one-page result. That is your portfolio.

FAQ

What does a forward deployed engineer do? They work inside a customer’s organization to build and run a working solution on the customer’s data and systems. That means finding the real workflow, writing and deploying code, measuring results, and fixing problems after launch.

How is it different from a solutions engineer? A solutions engineer mainly supports the sale with demos and technical fit. A forward deployed engineer is measured on whether the system works in production and usually stays after launch. Some companies blur the titles, so read the job description.

What skills matter? Strong software engineering, data skills, AI agent and evaluation skills, customer interviewing, clear writing, and ownership of outcomes. Judgment matters too, especially knowing when a simple workflow beats an agent.

How do I get started? Build one agent on messy, realistic data, add an evaluation set, and write a one-page result with the baseline and what failed. Put the code, the README, and the write-up in public. If you have domain experience, build in that domain.

What is a day like? Mixed. Expect time with users, reviewing agent failures, fixing tool and data problems, security and IT reviews, and a weekly update. Pragmatic Engineer reports onsite time that ranges from about 25% to 50% at some companies.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect