A demo budget is not a run rate

A pilot is judged on whether the thing works. A rollout is judged on cost per interaction, multiplied by an interaction count nobody in the pilot ever saw. Those are different questions, and enterprises routinely answer the first brilliantly and the second about a year too late.

Pilots are priced at pilot volume

The arithmetic of a demonstration is forgiving. A few hundred interactions a week. A generous retrieval window, because context is cheap when there are two hundred queries. The strongest available model on every call, because the point is to show the ceiling. Nothing about that configuration is wrong for learning. It is simply not the configuration that will ever run.

Then multiply it. Production volume is rarely a small multiple of pilot volume, and cost per interaction does not politely fall to meet it. It rises, because real work is messier than demonstration work: longer documents, more retrieved context, retries on malformed output, a second call to check the first, and agent loops in which one request becomes six model calls before an answer exists. The pilot measured cost per query. The operation pays cost per resolved case.

Cost is an architecture decision, made early and discovered late

By the time run cost is visible on an invoice, the levers that control it have already been pulled. Which tier serves which class of request. How much retrieved context each call carries, and what the marginal chunk actually buys in accuracy. Whether the prompt prefix is stable enough to cache. Whether a small model handles the routine majority and escalates only on low confidence. Whether the workload is interactive at all, or whether half of it could be batched overnight by a system nobody has asked to be fast.

Each of those trades against latency and against quality, and each moves the monthly figure by a multiple rather than a percentage. Deferring them does not save the decision for later; it commits to the most expensive default and postpones finding out. The rollout then becomes a re-engineering exercise wearing the costume of a scaling exercise, which is one of the more reliable routes into pilot purgatory.

The ceiling belongs in the schedule signed before the build

So run cost is a threshold, not a discovery. Cost per unit of work at the volume the case assumes goes into the evaluation schedule beside accuracy and latency, with a number against it and the baseline it is measured against — usually what the operation currently pays a person to do the same work. A system that clears every accuracy threshold at four times its cost ceiling has not passed. It has produced a thoroughly evidenced reason not to proceed, in week eight, for the price of a pilot.

This is why the Pilot gate names a cost, latency, and failure-mode profile as a required artifact: three properties that trade against one another, published together so nobody optimises one in a document that omits the other two. And it is why Full Value documents run-cost economics — a value-realisation figure that has not deducted the annual run cost is a gross number in a net number’s clothes.

None of this makes a system cheaper. It makes the cost knowable while the decision is still cheap to reverse. An organisation that learns its unit economics during rollout has paid for the rollout in order to acquire the information. An organisation that wrote the ceiling into the schedule bought the same information for the price of a paragraph.