Forward-Deployed Engineering

Forward-deployed engineering has no authoritative definition. There is no standard, no specification, and no body of peer-reviewed work describing it. What exists is company job descriptions, a handful of vendor and trade-press articles, and conference talks. The strongest primary sources are recruitment material, which describes what a vendor wants to hire and not what the model achieves. Alongside it sits secondary commentary in which practitioners visibly disagree about whether the approach works.

This page is therefore marked as analysis and carries low confidence. Where it describes a pattern observed across job descriptions and vendor writing, it says so; where it reasons about economics, it is reasoning, not reporting. If you need a citable definition for a document that has to withstand scrutiny, there is not one. Define the term locally, and do not imply an external consensus. That is the honest move.

The role as the sources describe it

The consistent element across job descriptions is embedding. Palantir, which originated the title, describes engineers who work directly with customers to understand their problems and then design and implement solutions, with responsibilities compared to those of a startup CTO: small teams, minimal supervision, end-to-end ownership, and a day spanning architecture discussion, large-scale data work, building a custom web application, and speaking to customer executives (Palantir job description). OpenAI’s postings for the same title describe leading end-to-end deployments of frontier models with strategic customers, owning discovery, scoping, system design, build and rollout. They also explicitly name feeding evaluation-driven field feedback into product and model roadmaps.

Trade coverage adds the origin and the distinction from implementation work. The title comes from military usage where forward-deployed means on the front line; the engineer belongs to the vendor but is allocated to one customer, and builds custom software for that customer instead of installing and configuring a core product (TechTarget). That is the sharpest available line: an implementation team configures, a forward-deployed engineer writes software that did not exist before.

Two caveats. Job descriptions are marketing documents aimed at candidates. And accounts of the role day to day come largely from journalism and alumni recollection (Business Insider, 2025), which is evidence about experience, not about outcomes.

Why AI deployments generate demand for it

The reason this pattern has resurfaced around AI is the distance between a demo and a system. A demo has to work once, on data the demonstrator chose, in front of an audience not trying to break it. A production system has to survive one organisation’s actual data, its permission model, and its edge cases. Each gap is wider for a language model feature than for conventional software, for structural reasons:

The last two are load-bearing. Anthropic’s account of agent evaluation notes that an evaluation suite is what resolves ambiguity when two engineers read the same specification differently (Anthropic, 2026). Writing that suite requires knowing what a correct answer looks like in the customer’s domain, knowledge the vendor does not have and the customer cannot easily hand over as a document. Someone has to sit in the room. That is the engineering argument for embedding, independent of any sales argument.

The gaps above are the substance of the AI Engineering path: retrieval quality, evaluation, security boundaries, agent blast radius. An embedded engineer who cannot do that work is a consultant with a laptop.

The economics

Embedded delivery is the costliest way to serve a customer, and worse than the headline rate suggests. The engineer is allocated to one account, so there is no leverage across customers. Travel and on-site time are unbillable overhead in most structures. Context is non-transferable: an engineer who spent months learning one customer’s data model cannot be swapped without repeating the learning. And the deliverable is often custom software somebody has to maintain, a liability that outlives the engagement.

Against that, revenue from one account is bounded, so the model does not pay back through delivery margin. It pays back, if at all, through one mechanism: the learning has to become product. A pattern discovered inside one customer’s environment, generalised and shipped into the core product, is paid for once and earns across every customer afterwards. That is why the OpenAI postings put field feedback into the roadmap in the job description. It is not treated as a side effect.

The question to ask about such a programme is therefore not whether it is profitable per engagement, because it usually is not. It is:

The exit condition is the term teams most often omit and the one that decides whether this is investment or subsidy. Without it, the programme converts into permanent unpaid support and the vendor discovers it has acquired a services business it did not intend to run.

Practitioners disagree about whether the model works as a durable strategy. One argument holds that it produces fast proof of value and useful reference deployments; another holds that it works as a sales tactic but poorly as a long-term strategy, because it produces customer-specific lock-in and limited general functionality. Both positions come from vendor executives with commercial interests, which is a reason to weigh them as positions, not findings.

How it differs from adjacent models

These roles are routinely conflated, including by the organisations that staff them. The distinction that matters is whether new software gets written, and who owns the outcome.

The practical test is what happens when the product cannot do what the customer needs. A consultant builds around the gap and bills for it. A solutions engineer scopes it out of the deal. An implementation team raises a feature request. A forward-deployed engineer is expected to build it and then argue for it to become product. That expectation is the definition, and it is why the role is hard to staff.

When it is the wrong model

State the negative case as plainly as the positive one, because the failure is expensive and slow to become visible.

• The product already fits. If the customer’s need is configuration, an implementation team is cheaper and better at it. Embedding an engineer to configure software wastes the scarcest people you have.
• There is no route from field to product. Without a real path back, the generalisation rate is zero and the payback argument collapses. This failure is organisational rather than technical.
• The customer is genuinely unique. A regulatory regime, data model or workflow shared with nobody else produces learning that generalises to nobody else. That may be worth doing for revenue, but it is a services engagement and should be priced as one.
• You cannot staff it properly. Filling the role with people who can do only the customer-facing half yields expensive relationship management; filling it with people who can do only the engineering half yields software nobody asked for.
• The customer will not commit counterparts. Embedded work needs someone on the other side who can grant access, decide what correct means, and adopt the result. Without that, the engineer is blocked on the customer at their own expense.
• You are hoping it substitutes for product decisions. Solving the same problem inside five customers instead of once in the product is the anti-pattern. Notice it by counting how often the same integration gets written.

The human line in the same budget

The other pages in AI Economics cost the machinery: per-request cost in inference cost structure, the per-request budget in context window economics, and the hosted-versus-self-hosted crossover in build versus buy. Forward-deployed engineering is the human line in the same budget.

The connection to build versus buy is the sharpest, because that page treats engineering headcount as a term in the break-even calculation, not an afterthought: a self-hosting decision is usually a decision to hire. A vendor offering embedded engineers is offering to absorb part of that headcount cost on the buy side of the same comparison. A buyer should therefore treat it as a priced component. Ask what happens to the deployment when the engineers leave; if the answer is that it degrades, the true cost of buying includes hiring their replacements later. A vendor should recognise that offering it moves cost from the customer’s budget to its own, which is defensible only if the learning comes back.