The FDE Playbook: A 15-Minute Course on Forward-Deployed Engineering

Course 4 · The FDE Playbook

Frontier AI is a commodity. The last mile, between what a model can do and what a business lets it do in production, is where value is won or lost. The forward-deployed engineer is the role built to close it.

A 15-minute course in six modules. This page summarises it. The figures in it are the course’s own, such as a 60 to 100 case gold set.

The Short Answer

Any enterprise can rent the same models its competitors rent. A small set of firms turn that shared commodity into extraordinary economics, while the median enterprise AI project dies between the demo and the P&L.

The difference is the last mile: the distance between what a model can do and what an enterprise’s real work, data and people let it do in production. Models deploy in minutes. Value deploys in months, and only through the work itself. The forward-deployed engineer is the role the era invented to close that distance.

The course compresses its message into one line: embed at the constraint, build what compounds, transfer the keys.

Module 1: Where the Forward-Deployed Engineer Comes From

The role descends from three earlier answers to one question: how does complex technology cross from a vendor into a customer’s operation?

The first answer was the solutions engineer, attached to sales, who ran the proof of concept and left at signature. It closed deals, not gaps. The second was the consulting engagement, a leverage pyramid in which a few partners sell and a large base of juniors does the repeatable work. Its deliverable is analysis, not installation, and its incentives run against transfer, because capability that stays with the client is revenue that does not recur. The AI era breaks the pyramid’s foundation, because the junior layer’s repeatable analysis is exactly the work models automate first.

The third answer came from a data platform company. Its software was general, but each customer’s data and workflow were specific, so it sent engineers to live inside the customer’s problem, building the specific out of the general. Its public listing documents describe three phases: acquire, often at low margin while the field team learns the institution; expand across the customer’s operations; then scale, as the field investment falls away and the relationship converts to high-margin software.

The role went through five vintages under one title. The constant across all five was never a task list. It was accountability for the customer’s outcome. Observers derided it as a consultancy in software clothing. The answer was productisation: the residue of a decade of deployment hardened into product, and the margins followed. The motion was never a compromise on the way to being a software company. It was the manufacturing process.

Exercise: for one AI initiative you know, ask what was delivered. A description of the problem, or a machine that solves it?

Module 2: Why Now, and Why Deployments Stall

The course gives four forces. Commoditisation above: when every enterprise rents the same models, deployment becomes the product. Stall below: enterprises hold enormous AI commitments and a deployment record that lags them badly. Imitation across: the frontier labs, the data platforms and the new services firms now all hire forward-deployed engineers by that name. And the window: what forward-deployed humans do by hand this decade is being encoded into product, so the firm’s accumulating deployment residue chooses who builds next decade’s products.

The same motion now runs from five positions. Frontier labs use it to turn pilots into structural token commitments. Data platforms use it to land consumption. Application companies use it as their manufacturing process. Services firms run it as their whole business. Enterprises run it internally. The advice is to choose your position first and accept its business model.

Deployments stall in a sequence of three. The first stall is data: nearly every AI problem becomes a data problem within weeks, because the cases are scattered, the records ungoverned and the receiving systems have no clean interface. The second is adoption structure: an assistant in front of every employee produces real but bounded value, and the compounding step is reworking a whole process so the leverage accrues to the function, built workflow by workflow.

The third is trust, and it has a clock. The variable that decides it is time-to-magic: the days until real work on the customer’s actual cases visibly succeeds in production. The field’s target is weeks, not quarters. Past the window, pilots enter purgatory. That is why the first weeks of most engagements go into building the minimum data substrate the demo assumed, while logging the larger data findings, rather than trying to fix the whole data estate before proving anything.

These stalls price the motion. An engagement is expensive per week and cheap per outcome, and the pricing evolves with proof: fixed-fee services first, then outcome terms once a test suite can verify results, and finally subscription once the residue is product.

Exercise: for your most important AI project, measure the days from start to first verified win on real cases.

Module 3: What an FDE Is, and Is Not

The role attracts three misreadings, and each quietly destroys the economics. An FDE is not a solutions engineer: the solutions engineer serves the sale and leaves at signature, while the FDE arrives at signature and serves the outcome. The artifact is a production system passing a frozen evaluation suite on the customer’s cases.

An FDE is not a consultant. A consultant who understands a claims process writes it down. An FDE builds the intake system, the test suite from 90 real claims, and the gate the adjusters actually use. The test is what remains when the person leaves: a document that describes, or a system that runs. And an FDE is not staff augmentation. A contractor absorbed into the customer’s backlog produces knowledge that belongs to no one.

The defining feature is a second loyalty: alongside the customer’s outcome runs a duty to the product. So the definition has three clauses: an engineer, embedded at the customer’s constraint, building production machinery from the customer’s real cases, with a duty to turn deployment learning into product. Remove the embed and you have a vendor. Remove the machinery and you have a consultant. Remove the product duty and you have a body shop.

The FDE is a diagonal hire. Engineering depth lets them build alone, without a platform team down the hall. Field temperament lets them get better information from a customer’s floor than the customer’s own managers have. Product sense is the instinct that notices a pattern the second time and files it. A good screening question is: walk me through something you built twice, and what you did about it.

Module 4: The Motion in Five Steps

Step one, the wedge: which problem to solve first. Not the biggest and not the executive’s favourite, but the one that converts fastest into visible, verifiable value. It must pass four gates. Volume: the work recurs often. Specifiability: an expert can say what good looks like. Verifiability: results can be checked against real cases. Pain: someone senior feels it weekly. To protect the clock, add reversibility and data reachable in days. Avoid the moonshot, which burns the trust window; the trivial win nobody feels; and the demo wedge, chosen because the vendor’s demo already solves it. Decide with a scorecard, and give the scorecard to the customer.

Step two, the embedding. Week one is methodology: sit with the people who do the work, not their managers, and record the process as practiced, with its exceptions and workarounds. Week two is substrate: collect a gold set of 60 to 100 real adjudicated cases, including edge cases and remembered mistakes. Presence matters, because the unwritten part of the constraint is only audible on the floor.

Step three, the build. The test comes before the system, frozen early, with the customer’s own expert signing the answers, so no one can say the vendor graded its own homework. The harness is built from the customer’s rules and red lines, and the system graduates in public against a threshold agreed in advance. It runs at agent speed, so arrive with a working version and invite the customer to say what is wrong. A customer who cannot describe what they need can always say what is wrong with what they see.

Step four, the cascade: publish the gauges and let the numbers recruit the next team. By the third system, build the shared substrate once for the whole program, and have the roster of every system’s owner and evidence ready before anyone asks for governance.

Step five, product: ask at every review, what did we build here for the second time? Promote it from playbook to toolkit to product. The pattern is the vendor’s; the customer’s data and cases are theirs. The deepest version of the job is to automate the job.

Exercise: score three candidate wedges on volume, specifiability, verifiability and pain, and pick the one that passes all four.

Module 5: The Contract

An embedded engineer building your machinery is the fastest capability transfer available, and the deepest dependency ever sold. The difference is decided in the contract, not the demo. Buyers worry about four things: lock-in; subsidizing a vendor that wants to compete with them; a third party changing the rules of their machinery; and paying frontier prices for work a smaller, owned model could do. The deepest asset is the decision loop itself: data seen, reasoning applied, action taken, outcome observed.

The clear-title test runs before signature. Who owns the evaluation suite, and can it run on another vendor’s model? Where does the record live? Who holds the encoded standards? Can the system survive a model swap? Who can operate it after handover? A vendor who answers cleanly sells capability. One who deflects sells dependency with an implementation phase.

The honest contract has four parts: an ownership schedule listing every artifact, with an owner and a tested portability requirement; a pricing ladder, with fixed-fee services first, outcome terms once the suite can verify, and subscription once the residue is product; a handover run as an acceptance test, closing when named customer staff demonstrate operation, not when the calendar ends; and a pattern licence, where the customer owns their substance and the vendor keeps the abstracted shape, stated openly. If it is discovered later, it is a lawsuit.

Some enterprises should build the motion in house. The test has four parts: the workflows are strategic, regulation is dense, data cannot leave, and volume repeats across business units. Meet all four, or you are paying vendor margins to build someone else’s residue. The internal version runs the same playbook with four variations: it is funded by the P&L it serves; sponsorship replaces sales, though the wedge discipline survives; all the residue stays home, and the title questions answer themselves; and the shape that works is a central practice deploying into business units, not scattered heroes.

The course also names six failure families that cover most field failures. They include pilot purgatory, hero dependency, the moonshot wedge, and the unharvested motion: twenty profitable deployments and nothing owned. File every failure to a family, and the family names the fix.

Exercise: run the five clear-title questions on one AI contract you hold, and mark each answer yes, no or unknown.

Module 6: The Skill Stack and the Firm

The skill stack has four layers, built bottom up, each with an artifact that proves it. Engineering depth: build a working system for a real task, a 60-case test suite, and run the gauges for a month alone. Domain fluency: one vertical at a time, with a written map of a real process as practiced. Field craft: archaeology on your own firm’s processes, one-page memos for executives, and weekly demos to people who did not build the thing. Commercial literacy: price the ladder and draft an ownership schedule.

The career ladder runs on scope, and each rung has its proof assigned: a system graduated in public, a handover that held after you left, a program that survived your rotation. Salary follows the scope; the career follows the filed residue.

To tell whether a firm is a business or a body shop, the course points to time-to-magic, expansion rate, outcome conversion, productisation rate, gross margin trajectory and title cleanliness, plus a refusal log of the engagements declined. A firm starting the motion should begin after the pattern, not before it: two or three founder-led deployments that proved a repeatable wedge, then a founding pair of a principal engineer and a commercial counterpart. Build the deployment record, the harvest channel and the meters before scaling headcount, then organize pods against accounts and grow people into the role rather than buying them.

The practice runs on four rings: weekly, the gauges and the trust clock; monthly, the residue and the record; quarterly, the meters; and annually, the clean-title audit. The closing question is: which parts of our field work should be software by next year?

The Course’s Exercises

1. Module 1: for one AI initiative you know, ask what was delivered. A description of the problem, or a machine that solves it?
2. Module 2: for your most important AI project, measure the days from start to first verified win on real cases.
3. Module 4: score three candidate wedges on volume, specifiability, verifiability and pain, and pick the one that passes all four.
4. Module 5: run the five clear-title questions on one AI contract you hold, and mark each answer yes, no or unknown.

See It in the News

Anthropic Commits $100M to Train 10,000 Engineers. A news piece on an AI lab’s programme to train engineers for a related deployment role under a similar name.

The Model and the Harness. A two-minute Business Pill on why the system around the model decides what it can do.

AI Evaluation as Acceptance Test. A two-minute Business Pill on the frozen test the course puts before the system.

The AI Audit Problem. A two-minute Business Pill on why checking work has become the bottleneck.