Forward deployed engineers are the fastest route to a production agent and the fastest route to a dependency you never chose. The contract decides which one you get.
FDEs are now the standard for AI platform implementation. Frontier labs bundle them into every large deal, and hyperscalers fund thousands of them. The pitch holds: an engineer who knows the model, embedded with a team that knows the business, shipping in weeks.
The FDE is not an alien species. It is the next step in a familiar line: the Salesforce architect, the CI/CD consultant, the test automation para trooper, The Azure Consultant, the embedded platform engineer adapted to a world where the underlying technology changes every quarter and the expertise hasn't had time to spread. That lineage is good news: we already know what makes these engagements compound, and what makes them fade.
One example of this form the 2010s were embedded consultants building infra, test automation CI/CD. The pipelines shipped and the quality improved. At roughly half the companies (anecdotal evidence), the test frameworks rotted within six months. Failing tests were deleted instead of fixed. Quality gates were bypassed instead of maintained. No one decided to let it decay; the discipline left with the consultants. The other half kept compounding and still does. The difference was rarely the consultant. It was whether the buyer had planned for ownership. That is a solvable contract problem, which is what this guide is for.
The FDE model has the same failure mode, with one difference that raises the stakes. A rotted test suite fails loudly and gets deleted. A rotted set of agent instructions keeps running and gets trusted. The prompt describes a business that no longer exists, and nothing errors.
The standard FDE contract covers scope, timeline, and a handoff document. It omits five terms that cost little to negotiate up front and plenty to discover at week twelve.
Table of Contents
- You Are Buying Tech Debt. Schedule the Payoff.
- The Eval Set Is the Deliverable. The Agent Is a Byproduct.
- Handoff Is Tested, Not Delivered.
- Define the Path from Custom Work to Product.
- Keep the Differentiating Twenty Percent Out of Scope.
1. You Are Buying Tech Debt. Schedule the Payoff.
Speed has a price, and the price is shortcuts. An FDE will hard-code a business rule into a prompt because the proper abstraction would take a week. They will tune instructions to the quirks of the current model rather than build for the next one. They will skip the eval for the edge case that only happens on Fridays. This is not bad engineering. That is the right trade for a working system in six weeks. Expect it.
Do not accept deferring all tech debt resolution to the end. Models change every quarter, upstream systems change without notice, and the business changes under both. A two-week cleanup sprint at close competes with the next model release and loses.
Negotiate a Tech Debt budget: twenty to thirty percent of every sprint goes to hardening what already shipped, against a debt list both sides can see. Pay the debt before the FDEs leave. A great FDE engagement is designed to end. The best vendors say this themselves: their engineer's job is to make your team fast, then graduate. If the engagement keeps extending, treat it as a signal worth discussing — usually it means the platform needs to get easier, not that anyone failed.
2. The Eval Set Is the Deliverable. The Agent Is a Byproduct.
Every FDE contract describes the workflows. Almost none describe the tests that prove it works. That is backwards. The agent is configuration that will be rewritten within a year. The eval set is the durable asset: a hundred or more real cases with expected outputs and a rubric, in a plain data format you own, runnable with one command against whatever is deployed.
Without it, your team cannot safely change a prompt, upgrade a model, or detect rot. With it, each becomes a routine operation with a score. Ask for the baseline score at handoff and the threshold that signals a problem. The good news: strong vendors increasingly lead with evals themselves, and this question is a quick way to find them.
3. Handoff Is Tested, Not Delivered.
A handoff document is a promise that knowledge transferred. A handoff test is proof. Before sign-off, one of your engineers should ship a meaningful change to the system, with the FDE reviewing rather than driving. Change a business rule and re-validate. Swap the model and rerun the evals. Fix something in the exception log.
This requires that your engineer exists, and that they were paired with the FDE for the last half of the engagement rather than the last week. Name that person before the FDE arrives. They will own evals, model migrations, cost, and instruction hygiene after the vendor leaves. If no name comes to mind, that is genuinely useful information: a managed service may fit better right now, and it is a fine choice — just a different purchase at a different price.
4. Define the Path from Custom Work to Product.
The original FDE model, the one Palantir built, has a loop at its center: the FDE solves a problem by hand, core engineering turns the solution into a product feature, and the custom code is deleted. Your maintenance burden shrinks over time. Many current FDE engagements do not have this loop, and the burden compounds instead.
Ask which parts of the build the vendor expects to absorb into the platform, and when. Put the answer in the contract, even loosely. A vendor with a real product roadmap will have a crisp answer, and will usually be glad you asked — absorbed features are their business case too.
5. Keep the Differentiating Twenty Percent Out of Scope.
FDEs carry what they learn back to the platform. This is the business model, and mostly it works in your favor: what they learn at every other client shows up in the platform you are paying for. Intake, document handling, routing, and reconciliation are commodity problems; every competitor will have them automated within a year, and the platform version will be better than a bespoke one.
Where the logic is yours, build it yourself on the foundation the FDE leaves. Let them build the eighty percent everyone needs. Let your orchestrator, trained by the engagement, build the twenty percent that makes you different. That is the strongest case for the in-house role: it is the only way to take the FDE's speed without handing over the blueprint.
Before Renewal, Run the Exit Test
Point the eval set at a second model. One week tells you the true switching cost, the only number that matters when the vendor proposes a larger license floor. Buyers who run it almost never switch — they renew, on better terms and with more confidence in the partnership.
That is the contract. How the engagement begins — what FDEs ask for in their first weeks, and what to have decided before they arrive — is covered in the companion piece: Fail First: The High Value of Two Weeks Without an FDE.