What a Deployment Engineer Should Own, and Leave Behind

A deployment can pass every check on the day its engineer leaves and stop working a month later, without a line of code changing.

What left was a person. The one who knew that three large accounts must never be credited automatically, who re-ran the import when the warehouse file arrived late, who answered the team's questions in a chat thread nobody else read. The system had been running on that knowledge from the start, and none of it had been written into anything the customer or the product could keep.

That is the central risk of the forward-deployed engineer, or FDE: an engineer from the software vendor who works inside the customer's organization to make the product useful there. AI companies have taken up the role because their deployments need it. It is usually judged by the wrong thing.

An FDE's real job is to turn what they learn inside the customer's work into things that outlast them: configuration the customer can change, tests built from real cases, written reasons for each decision, and, when the same need shows up at several customers, features in the shared product. A deployment should be judged by what still works, and keeps improving, after the engineer has gone.

Why the engineer has to go there

The best explanation of the role predates it by decades. In 1994 the economist Eric von Hippel called information sticky when it is expensive to acquire, transfer and use somewhere else. His finding was that problem solving moves to wherever the sticky information sits.

An AI deployment has two piles of sticky information. The customer holds how the work actually runs: the exceptions, the workarounds, who really decides, and why the official procedure is followed in name only. The vendor holds how the model and the product behave: what the model gets wrong, which settings exist, what the next release will change. Neither side can write its half down cheaply for the other. So the vendor sends a person to where the customer's knowledge lives, carrying the product's knowledge in their head.

Von Hippel also noticed the two ways people escape the cost of moving sticky information. They split the problem into parts that each need only one side's knowledge, or they invest in making the knowledge less sticky. Those are exactly the two halves of a good handover: separate what is particular to this customer from what belongs in the shared product, and turn what the engineer learned into documents, tests and settings someone else can use.

An FDE is what it costs to move sticky information. The handover is the investment that makes the next move cheaper.

Palantir made the role famous, sending engineers to military bases and factories. OpenAI and Anthropic now hire for it, and their job postings are revealing: specific about what should flow back to the vendor (deployment patterns, evaluations that change the product and the model), brief about what should stay with the customer. That imbalance shows where the role's attention tends to drift.

One deployment, five findings, five destinations

Take an illustrative case. A wholesale distributor wants an AI system to handle credit-note requests: customers asking for money back for damaged, missing or wrong goods. About 400 arrive each week, and six people handle them. The written procedure has four steps: receive the request, check the order, approve it if it's under $500 or escalate it, and issue the credit in the accounting system.

The FDE spends the first days sitting with the people who do the work and asking "why?" at every step that differs from the procedure. Five things turn up.

• Damaged in transit. The carrier must be notified within seven days, or the distributor absorbs the loss. Experienced staff file the carrier claim before they issue the credit. The procedure doesn't mention it.
• Key accounts. Three large customers never get automatic credits, whatever the amount, because their credits are part of rebates the sales team negotiates. The list lives in one sales manager's head.
• One warehouse miscounts. Its scanner has been miscounting pallets for months, so requests citing that warehouse need a photo check.
• Old invoices. The accounting system rejects credits against invoices older than 90 days, so one clerk issues a manual adjustment that finance reconciles at month end.
• Who decides. The procedure says a supervisor approves anything above $500. In practice the finance controller sets the threshold, and the sales director can overrule it for key accounts.

Here's the point most deployments miss: these five findings belong in five different places.

The carrier rule becomes a rule in the customer's configuration, with test cases. The key-account list becomes configuration owned by sales operations, with a short note on why it exists. The warehouse problem becomes a temporary rule with an owner and an expiry date, plus a ticket to fix the scanner, because a system that permanently encodes a hardware fault hides the fault. The 90-day limit comes from a widely used accounting system, so other customers probably hit it too: that makes it a candidate for the shared product. And the real decision rights go into the approval logic and into the list of people who must sign off before the system goes live.

A competent FDE without a handover discipline would fix all five in custom code, quickly and correctly. The system would work. And only the FDE would know which parts were rules, which were temporary, which belonged to the product, and whose permission each one rested on.

Three ways a deployment ends up depending on one person

The product turns into a pile of forks. This failure happens across customers. Each special case gets built as custom code in that customer's copy, and over a year the product becomes a set of forks: separate versions drifting further from the shared core. Every individual decision is reasonable. The cost shows up later, and AI products make it visible, because the model underneath keeps changing. An upgrade can change behavior in every prompt, rule and tool description, so every custom component has to be tested again.

Thirty-six engineer-days, several times a year. If the same needs had been met by 6 shared components plus per-customer configuration, the vendor would re-test the 6 components once (3 days) and run a quarter-day check of each customer's settings (another 3), for 6 days in total. The numbers are illustrative; the shape is general. Fork costs grow with customers multiplied by components. A shared core with configuration grows with customers plus components. At twelve customers that's a factor of six, and the gap widens with every customer added.

Scroll sideways to see the whole figure

Heavy custom work has defenders, and they have a point: a young company learns real workflows that way. The product thinker Marty Cagan named the condition: Palantir's model works, in his account, because a platform team turns what field engineers learn into reusable capabilities. Services that feed a shared core are an investment. Services that only add forks are consulting sold at product prices.

The engineer becomes permanent middleware. This one happens inside a single customer. The system works only while the FDE is there, because the FDE quietly does part of the work: re-running the failed import on Monday mornings, rephrasing the instructions when the output drifts, acting as the unofficial approver for anything odd. The dashboard looks healthy because a person is absorbing the exceptions it doesn't show. The customer sees a responsive vendor, the vendor sees a happy account, and the FDE often enjoys being indispensable.

The test is simple. Take the FDE away for a week during the engagement, on purpose and with notice, and watch what breaks. Everything that breaks is work the system wasn't doing.

The reasons leave with the person. The customer can run the system without knowing why the key-account rule exists, or who agreed the warehouse rule could expire. A year later someone tidies the configuration, removes a rule that looked redundant and reopens a solved problem. Research on enterprise software rollouts found that knowledge transfer from consultants to clients depends on the client's capacity to absorb it and on how well the two sides communicate. My reading: transfer can't be scheduled as a final week of documentation. The client's people have to learn, and build, while the work happens.

What has to be left behind

The usual handover is a pile of documents in the last week. A better one consists of things the customer has already used, each tested by someone other than its author. Six carry most of the weight.

• Runbooks. A runbook says what to do when a specific thing fails: the symptom, the check, the fix, who to call. It's tested by having the customer's technical owner follow it in a real or staged incident while the FDE watches without helping.
• Decision records. A decision record is a short note per significant choice: what was decided, what else was considered, why this won, what would make it worth revisiting. Business rules like the key-account exemption and the $500 threshold need them most, because those are what people will later want to change.
• Evaluation cases from real work. An evaluation set is a collection of the customer's own past requests with the right answers agreed by the people who do the work. It's the most valuable thing an FDE leaves: it lets the customer check any change they make, and lets the vendor check a new model against this customer's reality (Build an Evaluation From Your Own Work).
• Permissions, documented. Every identity the system uses, every access it holds, who approved it and when it gets reviewed.
• A named internal owner. One person at the customer, with time allocated, accountable for the system after launch. A steering committee doesn't count.
• A way to change things without the vendor. Settings the customer can edit (rules, thresholds, account lists, instructions), a way to test a change against the evaluation cases before it goes live, and a way to roll it back. If the customer can't change a threshold without opening a ticket, the vendor still owns the process.

These have an order. A customer can't safely change what it can't test, and a runbook nobody has followed is a guess. So each rung of the handover is proven by something the customer did, not by a document existing.

Scroll sideways to see the whole figure

Handover is finished when the customer has changed the system on their own, and the change passed their own tests.

Patterns go to the product, particulars stay with the customer

The other half of the FDE's output flows back into the product. The working rule: patterns become product, particulars stay as configuration. Only this distributor has these three key accounts, so the list is a particular. But the ability to exempt named accounts from automation is a pattern. Most findings split like that: a general capability in the core, customer-specific values in the settings.

The hard cases are habits that look like needs. A customer insists that requests be grouped by region because "that's how we work". That could reflect regional teams with different carriers and laws, or an old screen layout. The test I find most useful: ask what would break, and for whom, if the difference were removed. A legal obligation, a contract or a real difference in the work makes it a need. If people would merely have to get used to something new, it's a habit, and coding it in bends the core to please one customer (A Shared Core Without Flattening the Company).

Timing matters too. Programmers have an old rule of three for duplicated code: tolerate the first copy, refactor on the third. It works for features. The FDE tags a finding as a possible pattern, and the product team promotes it when the same need appears at a third customer in different words. Too early puts one customer's quirks into everyone's product. Too late leaves FDEs maintaining the same workaround in several places.

The people whose work is changing are part of this flow, and the most fragile part. They hold the knowledge the FDE needs, and they notice a wrong output before any metric does (Most of What a Company Knows Isn't Written Down). Workers who help build the evaluation cases, who can reject an output and say why, and whose rejections change the system, keep sharing what they know. Workers who discover they were mapped and then bypassed stop sharing. The goal is to leave them more capable: the clerk who knew about the 90-day limit now owns that rule and is the person others ask.

When dependency is fine

The strongest objection comes from Palantir itself, which has told investors that customers expand partly because its engineers help them find new uses. On that view the FDE never really leaves, and the long relationship is the business. Plenty of customers would rather pay a vendor to run a system than learn to run it.

Both are fair. An FDE who stays for years can be worth it if their time goes to the next problem. A customer who wants a managed service should buy one, named and priced as such, with service levels and an exit clause. What does harm is undeclared dependency: a system sold as a product that works only while one particular person stays.

What to do

If you're buying a deployment, or running one:

Start every handover artifact in week one, so the final weeks test the handover instead of producing it. That includes writing down what sales and the sponsor already promised, and to whom, before the first demo, and a way to pause and fall back to the manual process if the sponsor leaves or a model upgrade misbehaves.

Have the customer's technical owner make a real configuration change by mid-project, and make it pass the evaluation cases. Earlier is better.

Schedule the week without the FDE, near the end, with the FDE reachable only for emergencies. It looks like idle time, which is why it gets cut. It's the cheapest moment to learn what the system can't do alone.

Measure what lasts. Skip use cases launched and hours delivered. Track time to the first output workers accepted on real cases, and above all the share of changes in the 90 days after handover made by the customer's people without vendor help. A share near zero means the handover failed, whatever the documents say. Then compare use and outcomes before and after the FDE stepped back (Measuring AI Impact Without Fooling Yourself).

The engineer will leave. Plan the deployment around that day from the first one (Designing an AI Program That Ships).

Check yourself

Why does a deployment that passes every check on the engineer's last day still fail a month later?

The knowledge it ran on lived in the person, such as the accounts never to credit automatically. None of it had been written into anything the customer or product could keep.

Why does a fork-heavy product get more expensive with every model upgrade?

Each custom component has to be re-tested after the upgrade. Costs grow with customers multiplied by components, while a shared core with configuration grows with customers plus components.

What does the week without the FDE test?

It shows what the system can't do alone. Everything that breaks is work the engineer was quietly doing.