Gasoline, Cars, and the Forward Deployed Engineer

The forward-deployed engineer isn’t new. IBM invented the job in 1964.

Ethan Mollick is right that the current generation of models is already sufficient for transformative impact. I would go further. If every frontier lab froze its weights this morning, we could still spend the next decade fixing the existing software estate and roughly doubling the efficiency of the institutions that run on it. Capability is not the constraint. It has not been the constraint for a while.

The tell is not a benchmark. The tell is a job title.

The FDE wave

Every lab and every serious AI vendor is now hiring Forward Deployed Engineers. The role has a simple shape: an engineer from the vendor sits with the customer, learns their environment, and hand-builds the scaffolding that turns a general capability into a working system inside one specific organization. They wire the model to the data, write the guardrails, tune the prompts, build the evals, and stay until it holds.

The industry talks about the FDE as a new go-to-market motion. It is not new. It is the oldest motion in commercial computing, and it appears at exactly one moment in a technology’s life: when the capability has outrun the market’s ability to contain it. The job gets a new name every generation, and the renaming is the important part. A vendor invents a title like this when it has not created a product. It has created a capacity, a capability it cannot fully define a use for, and it needs a person on site to find the use one customer at a time.

IBM invented the job in 1964

The System/360 was capability without understanding: a machine that could do almost anything and a customer who couldn’t get it to do the one thing they needed. An insurance company or a manufacturer could now own a general-purpose computer instead of renting time on someone else’s. Almost nobody who bought one knew how to make it produce a payroll run.

So IBM bundled the answer. The Systems Engineer came with the machine. Software, training, and the SE’s time were folded into the hardware lease, and the SE sat in the customer’s shop doing what an FDE does today: turning a general-purpose machine into the one thing the customer needed, one installation at a time. The customer was not really buying a computer. They were buying a computer plus the person who could tame it.

Here is what the S/360 era figured out that the current FDE wave hasn’t yet. The machine was never the product. The product was the system built around it: the job control that decided what ran and in what order, the access methods that decided how a program was allowed to touch data, the operator procedures that decided who could do what at the console, and the audit trail that said afterward what had actually happened. None of those made the processor faster. All of them lived outside it. And all of them were what made the machine usable by a company that did not have IBM in the building.

That bundle ended in 1969. With the Justice Department’s antitrust suit filed in January of that year, IBM announced in June that it would unbundle software and services from hardware and price them separately. The antitrust story is the footnote. The important part is what unbundling revealed: a large share of the value was in the containment layer the SE had been assembling by hand, and once that layer had a price of its own, the packaged software industry was born to supply it.

The SE bundle was a capability that arrived before its constraints. The FDE wave is the same thing, more than sixty years on.

Gasoline and cars

Here is the frame I keep coming back to. Inference is the gasoline. It is an extraordinary store of energy, cheap and getting cheaper, and it will burn in almost anything you pour it into.

Nobody buys gasoline for its own sake. They buy a car, and the car is the thing that makes gasoline useful, safe, and boring. The engine is the first layer of containment: a chamber that turns uncontrolled combustion into controlled work. Around the engine sits everything else, the tank, the fuel lines, the brakes, the steering, the seatbelts, the speed limit, all on the same chassis, and those contain the vehicle and the driver. The gasoline supplies the energy. It does not get a vote on any of that. The car is almost entirely constraint. That is what makes it a product.

Right now every lab is selling you fuel and calling it a vehicle, and every FDE is being hired to build the car by hand, one customer at a time, without a drawing. The work is real and the customers are happy, but it does not scale, and everyone involved knows it. The FDE is a symptom of a missing product category, not a business model.

What is missing is the car: the governed harness that contains the model’s behavior so that an ordinary organization can run it without a vendor engineer in the room.

Why the harness is the hard part

The instinct in the industry is to put the constraints inside the model. Better alignment, better instruction following, longer context, a system prompt that says “be careful.” All of that is a cleaner-burning fuel. It is still fuel. None of it is an engine, and none of it is a car.

A car is a set of constraints that live outside the thing being constrained. The gasoline does not decide how fast the car goes; the engine converts it, and the pedal, the gearing, and the brakes decide. The driver does not get to override the brakes by asking nicely. The constraint is mechanical, deterministic, and inspectable, and it does not care what the fuel is doing.

The same has to be true of an agent harness. The authority over what the agent may touch, what counts as done, who witnesses the work, and what happens when the agent deviates has to be materialized outside the model and outside the channel that feeds the model its instructions. If the constraint lives in a prompt, the model is reading it, and a thing that reads its own constraints can be talked out of them. If the constraint lives in a runtime the agent controls, the agent is the mechanic and the driver at the same time.

That is the structural problem the FDE is currently solving by hand at every customer site. They are building a one-off car, and it works because the FDE remembers where all the bolts are. The moment the FDE leaves, the customer is holding a machine that only one person knows how to keep on the road.

What the 1969 unbundling predicts

The IBM story gives us a reasonable forecast. The bundle does not last. Either regulators or economics pull the containment layer apart from the capability layer, and when that happens the containment layer becomes its own market.

That market will have the same shape it had in the 1970s: not better gasoline, but better engines, better brakes, better cars. Governance that is priced and shipped separately from the model. Controls that are deterministic rather than persuasive. Evidence that a third party can inspect after the fact. An operating discipline that an ordinary IT department can run without a lab engineer on retainer.

The vendors who understand this will stop selling FDE hours and start selling cars. The ones who do not will keep sending mechanics, and they will keep hearing that the capability is transformative and wondering why the transformation keeps stalling at the pilot.

The short version

We do not need the next model to change the economy. We need the harness that makes the current model safe enough to be boring.

The FDE wave is the market telling us it does not have that harness yet. It is the S/360 Systems Engineer with a laptop. The job title will fade the same way the bundled SE did, once someone builds the product that makes the site visit unnecessary.

Models are the new gasoline. Someone has to build the safe cars.

And a car is only half of it. The automobile did not change a country by itself; it took paved roads, traffic law, and an inspector who did not work for the manufacturer, and none of that was inside the car either. That is the next piece.

The framework behind “authority outside the model” is Governance Fidelity Theory. The illustrated primer is at equilateral.ai/blog/gft-public-primer. The technical working paper is available on request.