What Leaves With the Engineer: Get a Copy of the Packet

Milos Mandic published a post yesterday that takes the buyer's side of forward deployed engineering further than the buyers themselves have. A procurement guide the day before had told enterprises how to plan the vendor's engineer moving out. Gartner, two weeks earlier, had predicted that 70% of enterprises will abandon agentic AI built through vendor FDEs by 2028. Mandic takes both as read and asks the question underneath them: when the engineer walks out, what actually leaves?

His answer is the most honest thing an FDE has written about the role, because it is a confession. The contract can cover the code, the prompts, the configurations, and the business rules. It cannot cover what the engineer learned about how your process really runs, and that is the part the vendor's business model depends on.

I have written the vendor's side of this handoff for two months, and I agree with almost all of his post. The one place I would rewrite it is the advice to the buyer. He says ask. I say get a copy.

The short version

Milos Mandic's "The Move-Out Clause" (FDE Hub, October 20, 2026) argues that buyers have moved from "deliver the outcome" to "what happens after," and that the thing the contract cannot cover is the operational knowledge that leaves with the engineer: one former head of FDE told him around 70% of FDE output should flow back into product, and his own sixth client got the value of the first five without anyone signing anything that said so. He is right about the flow and I would not frame it as a loss. It is the mechanism the buyer is paying for, the reason next quarter needs fewer vendor hours, and the problem is only that it is invisible. It has a written form already. The handback packet an FDE owes product has four parts, the delta in configuration terms, the customer's eval rows, the reversals, and the count of other customers with the same problem, due at two weeks, go-live, and day 60. The rewrite: the buyer receives the same packet at the same three moments. The count column is the answer to Mandic's question, in writing. Knowledge transfer as a deliverable has no acceptance criteria. The packet has four.

What he says leaves

Start where he does, with the part the contract covers. Ownership of code, prompts, configurations, and business rules is negotiable and, he says, increasingly negotiated. A buyer who insists on owning them is right to. A vendor who resists has told you something.

Then the part it cannot cover. An engineer who spends three months inside your accounts payable process, your dispatch planning, or your underwriting queue leaves knowing how it really runs: the exceptions, the unwritten thresholds, the step that exists because of something that went wrong in 2019. They cannot sell your rules to anyone. They can, and will, apply what they learned about a business like yours the next time they sit down with a business like yours, which is often your competitor.

He is clear that this is the mechanism and not a loophole. Every FDE leader he has interviewed describes the job as learning something at one customer and carrying it back into the product so the next customer gets it faster. One former head of FDE put the right share of FDE output flowing back into product at around 70%. Mandic reads that number from the buyer's chair: a measure of how much of what the engineer learned inside you became something the vendor now sells to everyone.

His own engagements make the point concrete. Parallel work across logistics, wholesale, manufacturing, insurance, and finance, and the value he brought the sixth client was in large part the first five. Nobody signed anything that said so, every client benefited, and every one of them would have been right to ask what he was taking with him when he left.

The questions he started hearing at the end of that period were not about the model. They were about where the learnings go, who else gets them, and how long the company would need him.

Where I would change the advice

Mandic and I agree on the diagnosis. We differ on what the buyer should do with it, and the difference is one verb.

He would have the buyer ask. I would have the buyer receive.

The flow of learning into the product is not what the buyer loses. It is what the buyer is paying for, if the vendor is running the model honestly. A deployment that gets absorbed into the product is the reason the second deployment needs fewer of the vendor's hours than the first. The FDE Scorecard measures it from the vendor's side as generalization rate: the share of handback packets that got a written decision in two weeks, and the share of three-customer patterns that shipped. A vendor with a high generalization rate is a vendor whose engineers leave. That is what Mandic wants too, and he says so: an engineer stuck on one account refining what already works has stopped producing the discovery the team exists for.

So the problem is not that the knowledge flows. The problem is that it flows through the engineer's head and the buyer never sees it. Asking the engineer what they are taking produces an honest paragraph and no record. The buyer needs the record.

The record exists. It is the packet.

The packet, and the buyer's copy

Absorb Pain, Excrete Product: The FDE Handback defines what an FDE owes product, as a one-page packet with four parts and no narrative.

The delta: what the customer runs that the product did not ship, in configuration terms. Which prompts changed, which rules were added, which tools were wired, which thresholds moved. If the configuration boundary is in the right place, this is a diff and the engineer generates it.

The eval rows: the customer's cases that failed on day one and pass now, as rows a product team can run.

The reversals: what the customer turned off, overrode, or quietly stopped using, and the engineer's best guess why.

The count: how many other customers, by name, have the same problem this delta solves. One is a workaround. Three is a feature the company has already paid to discover.

Due at three moments: a landing note at two weeks, the full packet at go-live, and a reversal update at day 60.

Now read that list as the buyer. The delta is the written form of what the engineer learned about your process. The eval rows are your edge cases, the ones Mandic says live in the operators' heads. The reversals are the places your people disagreed with the vendor's assumptions. And the count is the answer to his question. It is the vendor saying, in writing, how many other customers have the problem you just paid to solve, which is exactly how much of your process is about to become roadmap.

The rewrite, then. The buyer gets a copy of the packet, at the same three moments the vendor's product team gets it. Not a knowledge-transfer document written for the exit. The working document the vendor already produces for itself, if it is running the loop at all.

A vendor who cannot produce the packet has told you the same thing Mandic's and Gartner's numbers say from opposite directions: he estimates about three in four self-described FDE teams are dev shops, and Gartner's figure of fewer than one in five engagements feeding product puts it slightly above 80%. A dev shop has no packet because there is no product for it to feed. Ask for the packet at two weeks and you will know which kind you hired before the pilot ends.

Three places become one

Mandic makes a second point that the procurement guide misses, and the packet answers it too.

Knowledge transfer as a deliverable assumes there is a body of knowledge to transfer, a manual the vendor is holding. In his engagements there was no manual on day one. The operational logic was in the operators' heads. After the build it lived in three places: the heads it came from, his head, and the prompts and rule tables he had written. The acceptance criteria for transferring that back are not obvious, because the thing being transferred was never written down anywhere the buyer could read.

A delta that is a diff of the customer layer collapses three places to one. The rules are in the configuration, the configuration is versioned, and the diff against the shipped default runs in one command. That is the condition Kill the Correction Queue puts on same-day changes, and it is also what makes "knowledge transfer" checkable: the diff runs, the rows pass, the reversals are listed, the count has names. Four acceptance criteria where the procurement guide has none.

What buyers actually asked Mandic for was narrower than a manual, and it is the right ask. They wanted to change the key business rules themselves, through something simpler than a codebase. Which regions ship on which days. Who approves above what threshold. What counts as a matching invoice. Open it, see the rule, change it, and the agent behaves differently tomorrow without raising a ticket.

That is the keys line from Month Two: The FDE Leaves, the Workflow Has to Stay: a named person at the customer who can change the customer layer without calling the vendor. Mandic adds the detail that matters about who that person is. The instinct is to staff the internal team from IT, because IT can operate the system. The people who can tell whether a rule is still true are the operators who live inside the process. Hand the pen to anyone else and the rules start ageing the day the engineers go. So the keys line carries an operator's name. A blank keys line at day 60 means the deployment has not landed, and an IT name on it means the rules start ageing the day the engineers leave, which is Mandic's point.

The same test from both sides

Mandic's closing test is one I would put in the contract next to the packet. The buyer's exit clause and the vendor's rotation discipline measure the same gap: how long after the outcome lands does the engineer stay. A short gap means the rules have an owner, the owner is an operator, and the next problem is being scoped. A long gap means somebody is paying discovery rates for maintenance.

The packet gives that gap a date. The day-60 reversal update is the last thing the engineer owes. If the vendor is still billing against the account at day 120 and no new packet has started, the gap is long, and the buyer did not need to ask anyone to know it.

Under AI Product Management the argument is that the build got cheap and the scarce work is knowing which part to build. In an FDE engagement the scarce work is knowing which part of what the engineer learned belongs in the product, and that decision is made from the packet. The vendor's PM reads it to decide what to generalize. The buyer should read the same page to see what is leaving, and whether the vendor is the kind that turns it into product or the kind that bills for it again next quarter.

This is a standalone post alongside The FDE Transition, for the buyers who have started writing the clause and the vendors who should be relieved they did.

This week: if you are buying, add one line to the statement of work: a copy of the handback packet, four parts, at two weeks, go-live, and day 60. If you are the vendor, send it before they ask. The count column is the most honest sentence you will put in front of a customer, and it is also the sentence that proves you are a product company.

Related answer: What leaves with the forward deployed engineer when the engagement ends?

Sources: Milos Mandic, "The Move-Out Clause," FDE Hub, October 20, 2026, read in full. The procurement guide, the Gartner prediction (70% of enterprises abandoning vendor-FDE-built agentic AI by 2028, fewer than one in five engagements feeding product), and the former head of FDE's 70% figure are cited only as Mandic reports them; I did not open the guide or the Gartner note for this post. Falk Gottlob, "Absorb Pain, Excrete Product: The FDE Handback" (September 24, 2026), "Month Two: The FDE Leaves, the Workflow Has to Stay" (October 6, 2026), "The FDE Scorecard: Count What Stayed, Not Who Was Sent" (October 8, 2026), and "Kill the Correction Queue" (October 20, 2026).