Forward Deployed Engineering: The Delivery Model AI Made Necessary

Introduction

Forward deployed engineering is a delivery model where engineers work inside the client's systems, on the client's data, shipping into the systems they already run, instead of building a generic product and hoping it fits. I have spent the last three years watching this model move from a Palantir curiosity to the default way serious AI work gets delivered. The reason is uncomfortable: RAND's study of why AI projects fail puts the failure rate above 80 percent, roughly twice that of non-AI IT projects, and the causes it identifies are organizational rather than technical.

This article is for business and technology buyers deciding how to staff an AI build, and for engineering leaders deciding whether to run this model internally. You will get the working definition, the economics that make it viable, the skills that separate this role from advisory work, and an honest account of when this model is the wrong purchase.

I will also cover the career side directly, because half the people searching this term want the forward deployed job rather than the service.

What Forward Deployed Engineering Actually Means

The model describes engineers embedded with a customer, building bespoke work against that customer's real data and actual infrastructure. FDEs do not hand over a specification. They write the code, deploy it, watch it break, and fix it in the same week.

The term originated at Palantir in the early 2010s, where forward deployed engineers (FDEs), internally called Deltas, went into government and industrial customers to make the platform fit problems the product team had never seen. As Gergely Orosz documents in his breakdown of the role, Palantir employed more FDEs than software engineers until 2016. That heritage explains why most search interest still attaches to Palantir. It also explains a common misreading: people assume this is a Palantir-specific job title rather than a general delivery model.

Forward Deployed Engineering Is Not Consulting

An outside adviser produces recommendations and a deck. A forward deployed engineer produces a running system with a deployment pipeline attached to it. The output is not advice about the technology, it is the technology.

The distinction matters to the business case. A consultant bills for analysis and transfers implementation risk back to you. This model bills for working software and keeps the risk where the engineering happens. When a client asks us which one they are buying, the honest test is simple: at the end of the engagement, does something run that did not run before?

Forward Deployed Engineering Is Not Staff Augmentation

Staff augmentation places a developer into your team to execute your backlog, which is not what FDEs do. The direction of authority runs from you to them. FDEs own the problem definition as well as the solution, which means saying "the ticket you wrote is the wrong ticket" is part of the job.

That authority is the whole point. Most failed AI projects fail because the requirement was written by someone who could not see the data, and nobody in the room had standing to challenge it.

The Boundary With a Solutions Engineer

A solutions engineer works pre-sale, proving a product can do what the sales team claims. A forward deployed engineer works post-sale, making the product actually do it in an environment nobody controlled for. OpenAI draws the same line internally, describing solutions architects as advisory people who rarely write code on customer infrastructure while FDEs do exactly that. Both teams share customer-facing instincts and diverge completely on depth of ownership.

Some organizations blur the two deliberately, which produces FDEs doing the work of a sales engineer with a Git commit history and a lot of confusion about who is accountable when the system misbehaves at month four.

Why AI Made This Model Necessary

Traditional enterprise software could ship as a product because the problem space was stable. Invoicing is invoicing. AI systems are different: their behavior depends on your data distribution, your edge cases, and your users' phrasing, none of which a vendor can anticipate from the outside.

That dependency is why generic AI products underperform in enterprise settings and why the same underlying models produce excellent results when someone sits close enough to the data to tune them. MIT's GenAI Divide study, reported by Fortune, found only about 5 percent of AI pilots delivered measurable profit impact, and traced the gap to tools that fail to learn from workflows rather than to weak models. The underlying models are commodity technology. The fit is not.

The Data Problem Nobody Can Solve Remotely

Every AI build we have run starts with a discovery that contradicts the brief. Fields that were documented as required turn out to be null in forty percent of records. Two departments use the same column for different meanings. The data infrastructure described in the architecture document stopped matching reality two reorganizations ago.

You cannot find these problems from a requirements workshop. You find them by connecting to the production database, which is a permission conversation, not a technical one. On one of our current builds, reaching the client's live PostgreSQL instance requires an IAP tunnel through a bastion host into a Cloud SQL proxy, because the database has no public IP. That access path is documented in the project repository as an operating procedure precisely because it is a daily activity rather than a one-time setup.

Evaluation Replaces Specification

In deterministic software development, you write a test and it passes or fails. With language models you write an evaluation suite and you get a distribution across runs. Our evaluation configs run each case three times, because the live temperature setting is non-deterministic and a single lucky sample proves nothing.

Those evaluations only stay honest if they are generated from the live source. In our own CMS agent repository, each suite's system prompt and tool schemas are rebuilt from production code before every run, so the tests cannot drift away from what actually ships. That discipline is difficult to maintain from outside the client's codebase, which is another structural argument for embedding.

The Feedback Loop Has to Be Short

AI companies that ship well share one operational trait: the distance between a user complaint and a corrected prompt is measured in hours. The MIT researchers named the same thing as the core barrier, describing most systems as unable to retain feedback, adapt to context, or improve over time. Achieve that with a vendor relationship, a ticketing system, and a two-week sprint boundary, and you have already lost.

We keep prompts in a versioned prompt manager rather than hardcoded in the repository, so a prompt correction does not require a deployment. We also expose model selection as a runtime configuration surface, letting an administrator retune which of the available models serves which role, per brand, without an engineering release. Both choices exist to shorten that loop.

How Forward Deployed Engineering Works in Practice

The consulting model most companies expect runs discovery, design, build, handover. This model runs differently, and the sequence matters more than the vocabulary.

Phase One: Get Access, Not Requirements

The first week is spent getting credentials, network paths, and a working local environment against real data. Not sanitized exports. Real records, read-only if that is what the security posture allows.

Teams that skip this and start with workshops lose a month. Delivery teams then defend a plan nobody has tested against data. The requirement document produced without data access is a work of fiction that everyone signs.

Phase Two: Ship Forward, Not Wide

Within two to three weeks, something should run in the client's environment and produce output business users can judge. Not a demo on our laptop. A deployed thing on their side, wired to their identity provider.

Narrowness is the forward deployed instinct here. One of their workflows, one user group, one measurable outcome. Broad first releases hide which part is working.

Phase Three: Instrument Before Expanding

Before adding a second of the client workflows, we wire tracing and product analytics. Our Cloudflare Workers deployments ship with LLM tracing and analytics configured as environment variables on the worker itself, so observability is not a later project. Without this, expansion is guesswork.

Phase Four: Move Forward Along Evidence

Now the role of FDEs shifts from building to reading. Which prompts get retried. Which tool calls fail. Which workflows users abandon. Expansion follows those signals rather than the original roadmap, and this is the phase where continuous improvement stops being a slogan and becomes a weekly artifact.

Phase Five: Hand Forward or Continue

Either the client's product teams take ownership, or the engagement continues as operations. Both are legitimate. What is not legitimate is pretending a handover happened because a document was delivered.

We have found genuine transfer requires the client's engineers to have written code in the repository during phases three and four. Reading a handover document teaches nobody how a tech system behaves under load.

The Skills That Define a Forward Deployed Engineer

The technical skills are necessary and insufficient. No training program we know of covers this combination directly. Two engineers with identical skills lists perform very differently in this seat. Plenty of strong engineers on capable teams fail in this role because it demands a combination the industry rarely trains for.

Technical Depth That Reaches Forward Into Production

Technical depth here means the ability to take a build from prototype to deployed, including the parts engineers usually delegate. Infrastructure as code, deployment pipelines, database migrations, secret management.

In our own work this spans Terraform for cloud provisioning, the Serverless Framework for AWS Lambda services, and Wrangler configurations for Cloudflare Workers. FDEs who can build the model integration but cannot deploy it have completed the interesting half of the job.

Enough Python to Read, Enough TypeScript to Ship

Most AI research and data work arrives in Python. Most systems we build run TypeScript. A forward deployed engineer reads the first fluently and writes the second professionally.

We are Node and TypeScript end to end for services, and use Python where offline model training genuinely fits better. Being monolingual in either direction limits which problems you can take.

Working With Live APIs and Undocumented Systems

The APIs you integrate against in client environments are rarely well documented. Half the job is reading response payloads to infer behavior that no specification describes.

This applies to model providers too. We route most inference through a single gateway for consistency, and drop to a provider's direct SDK when we need a feature the gateway does not expose. Knowing when to make that switch requires having read both sets of documentation carefully.

Reading a Business Outcome From a Conversation

The rarest skill FDEs need is translating a business complaint into a system change. A stakeholder saying "the summaries are wrong" might mean the retrieval is pulling the wrong documents, the prompt lacks a constraint, or their expectation was never achievable.

Diagnosing that takes conversation, not tickets, and no amount of technical training substitutes for it. This is where the specialist whose skills stop at code hits a ceiling, and where a broader specialist earns the premium, and why traditional software engineers moving into this role often find the adjustment harder than the technology.

Saying No With Evidence

Every engagement includes a request that would produce a worse system. The essential skills here include the ability to refuse it while offering a defensible alternative.

The technical expertise only converts into trust when the engineer has been right about a refusal at least once. Agreeableness is not among the skills worth hiring for here, and it is a short-term strategy that damages long-term outcomes.

The Economics: Why This Costs More and Is Often Cheaper

The cost profile of forward deployed engineering looks bad on a rate card and good on a total cost basis. Understanding the difference determines whether you buy this model or regret it.

Why the Forward Deployed Rate Card Looks Wrong

FDEs cost meaningfully more per hour than an offshore development resources pool and often more than a named consultancy's mid-tier rate. That is the honest starting position, and any vendor claiming otherwise is discounting something you will pay for later.

What the rate card omits is rework. Systems built from specifications that were written without data access get rebuilt, and the rebuild is rarely priced into the original comparison.

Where the Savings Actually Come From

The math works because the expensive failure mode in AI projects is not engineering hours. It is a system that works in the demo and gets abandoned in month five because nobody was close enough to fix its behavior on real usage.

The Fixed-Price Trap in Forward Deployed Work

Clients often ask for fixed-price delivery to cap risk. We do sign fixed-price contracts, including one currently running against a publicly co-funded scope where the agreed specification documents are the reference point whenever scope is disputed.

That arrangement works only because the specification was written with enough technical precision to be arbitrable. Fixed price against a vague scope transfers risk to whichever party is less willing to have an uncomfortable conversation, which is usually the client.

When This Model Is the Wrong Buy

Not every organization needs forward deployed engineering. Recommending forward deployed delivery universally would be dishonest, and the misfits are predictable.

Companies do not need this model when the problem is genuinely solved by a product. If a commercial tool covers your requirement at ninety percent, buy the tool and adapt your process for the remaining ten. Custom work built to preserve mildly preferred workflows is the most common form of waste in enterprise technology budgets.

You do not need it when you have no data. Enterprise organizations at the beginning of their digital transformation sometimes want AI systems before they have the operational records those systems would learn from. The correct first project is instrumenting the business, and it is cheaper.

You should be cautious when your internal teams have capacity and domain knowledge but lack only AI experience. In that case, training your own engineers and buying a short advisory engagement builds better long-term technology capabilities than importing an outside adviser who leaves with the understanding. Those capabilities stay with you.

Finally, this model struggles where access cannot be granted. Some regulated environments cannot give an external engineer production visibility within any reasonable timeframe. Without access, forward deployed engineering degrades into ordinary technology outsourcing with a better name.

What We Have Built Forward Deployed

I will be specific, because vague case studies are worth nothing to a buyer trying to assess technical expertise.

We built and operate the CMS and agent layer behind our own blog. It runs a hand-rolled tool-calling loop with hard iteration limits, retrieves context through vector search over our portfolio projects and client reviews, and routes different tasks to different models through a single gateway: an orchestrator model for tool calling, a separate writer model for prose, a reasoning model for SEO analysis. The model assignment per role is editable at runtime by an administrator rather than fixed in code.

For a proptech client, we own the backend and infrastructure of a platform while the client's own mobile developer owns the app. That split is contractual and deliberate. We keep the client's mobile repository checked out beside ours so the API contract stays aligned, a small practice that removes an entire category of integration dispute and the business friction attached to it.

On a collaborative AI workspace, we run six Cloudflare Workers with Durable Objects for stateful streaming, retrieval over pgvector with an HNSW index, and an approval gate so unapproved content cannot enter the retrieval path. The safety monitor can abort a stream mid-generation and retract output already sent to the client. These are the kinds of custom systems that exist only because someone was close enough to the failure modes to design for them.

On another AI product, conversation flow runs as an explicit finite state machine with five transition tables, including a human approval step where a proposed document edit waits for accept or reject. Four evaluation suites cover routing, guidance, examples and verification, with prompts imported from live TypeScript source so the tests track the code. We run those suites manually rather than in continuous integration, which is a limitation I would rather state than dress up.

Our companion articles go deeper on the underlying patterns: the agent architecture and tool-calling loop we reuse across these builds, and the infrastructure choices behind our AI stack including why we skip dedicated vector databases.

Matt Sadowski

CEO of Mobile Reality

Transform Your Business with Custom AI Agent Solutions!

Leverage our expertise in AI agent development to enhance efficiency, scalability, and innovation within your organization.

• Expert development of modular and scalable AI software solutions.
• Integration of Large Language Models (LLMs) for advanced capabilities.
• Customized AI agents tailored to your business needs.
• End-to-end support from design to deployment.
• Enhance decision-making and operational efficiency with AI.

Book a consultationEstimate project

Who Hires FDEs, and What the Job Actually Involves

Buyers ask this for a practical reason: if you are going to depend on forward deployed talent, you should know how deep that pool is and who you are competing with for it.

The Employers Using the Forward Deployed Title

Palantir established the title and still employs the most FDEs. The role has since spread well beyond it: the Pragmatic Engineer survey found OpenAI running more than ten FDEs across eight cities and the fintech company Ramp running roughly fifteen, alongside the ai engineer variants now appearing at smaller AI product companies.

Engineering companies including Mobile Reality operate the same forward deployed model without always using the title as an internal job label. That is why counting employers who use the exact phrase understates how widely the model is practiced across the software industry.

The Job Description Behind Forward Deployed Work

A realistic description of the work is roughly half production software engineering and half customer-facing judgment. The responsibilities include shipping code, owning deployments, sitting in the client's planning meetings, and telling people when their requirement is wrong.

People who thrive here want direct evidence that their work mattered. People who prefer sustained focus on one codebase usually do not, because context switching is constant.

Why It Is a Strong Early-Career Move

As a job in startups and scale-ups, this role compresses experience. You see many production environments in two years rather than one, which teaches pattern recognition that no single-product software job provides at the same speed.

Compensation reflects that scarcity. Levels.fyi data for Palantir puts forward deployed software engineer packages between roughly $171,000 and $295,000, with a median near $211,000. Treat those figures as one employer's band rather than a market rate, since the title is applied inconsistently.

How to Evaluate a Forward Deployed Engineering Partner

Most enterprise procurement processes for this work ask the wrong questions. Companies score vendors on rate and headcount, which measures neither capability nor fit. Here is what separates a real practice from a repackaged staff augmentation vendor.

Ask What They Refused

Request a specific example of a client request the vendor declined, and the business reason behind whatever they proposed instead. A vendor with no refusals has either never had stakeholders push a bad idea, which is impossible, or agrees to everything, which is worse.

Ask to See an Evaluation Suite

For any AI projects, ask how they know the system still works after a prompt change. If the answer is manual spot checking, the system will degrade silently. If they can show you evaluation configurations with assertions describing real regressions, that is a practice.

Ask Who Deploys

The engineering roles in a proposal should include the person who runs the deployment. If the vendor builds and someone else deploys, the ownership boundary is where your systems will fail.

Ask About the Access Timeline

A partner who has done this before will ask about live access in the first conversation and will have opinions about the security path. One who leaves it until after contract signature has not run this model at scale.

Ask What Runs Today

The most useful question for assessing an AI solutions vendor is what of theirs is running right now, who uses it, and what broke last month. The future of a partnership is predicted by whether they can answer the last part without defensiveness.

Conclusion

Forward deployed engineering is the delivery model that AI made necessary, because AI system quality depends on fit to a specific environment rather than on the underlying model, and fit cannot be achieved from outside the customer's systems.

• The core distinction is ownership: FDEs ship and operate working software rather than delivering recommendations or executing someone else's backlog.
• The model works because it collapses the feedback loop between a user problem and a corrected system, which is where most AI innovation stalls in practice.
• The required combination is production software engineering, comfort with live client APIs, and the standing to refuse a bad requirement with evidence.
• The business outcomes justify a higher rate card only when the alternative would have produced rework, which is most of the time in AI builds and rarely the case for well-defined product implementations.
• Forward deployed delivery is the wrong purchase when a commercial product already fits, when there is no data to work with, or when production access cannot realistically be granted.

If you are evaluating this forward deployed model for an AI build, start by asking whether you can grant an external engineer access to the workflows that matter within four weeks. If the answer is no, fix that first, because it determines whether any version of this industry practice will work for you. If the answer is yes, our AI automation practice runs exactly this model, and the fastest way to test fit is one narrow set of workflows rather than a large discovery phase.

Forward Deployed Engineering FAQ

What is a forward deployment engineer?

A forward deployment engineer, more commonly written as a forward deployed engineer or FDE, is a software engineer who works embedded with a customer, building and deploying custom systems against that customer's live data and infrastructure. The role differs from a consultant in that the output is working production software rather than recommendations, and differs from staff augmentation in that the engineer owns problem definition as well as implementation.

What is a Forward Deployed Engineer's salary?

Compensation sits above standard software engineering bands in the same market, because the role combines production engineering with customer-facing responsibility. Public compensation aggregators show a wide spread depending on employer, seniority and location, with the forward deployed AI variants at large platform vendors at the top of the range. Treat published figures with caution, since the title is applied inconsistently across employers.

Is a Forward Deployed Engineer a good job?

The role suits engineers who want direct visibility into whether their work mattered, and forward deployed work suits people energized rather than drained by client contact. It is a poor fit if you prefer deep focus on a single codebase, since context switching and travel are common responsibilities. As a job in startups it can offer unusually fast learning, because you see many production environments in a short time rather than one.

What companies have forward-deployed engineers?

Palantir established the title, still hires FDEs at scale, and remains the most searched employer for it. AI platform vendors including OpenAI and Anthropic have adopted variants of the AI engineer version of the role, and enterprise AI companies such as C3.ai run similar functions. Engineering companies including Mobile Reality operate the same forward deployed model without necessarily using the title as an internal job label, which is why employers using the exact phrase are a poor proxy for how widely the model is practiced.